Animoca's Moca Chain puts an AI agent's permissions on a credential merchants can check

A person tells a shopping agent to find and book a flight under $400 ^[1]. That instruction should not give the agent free rein over the person's saved cards or let it buy whatever else it likes ^[1]. The limit exists only in the prompt. Most of the web's identity systems were built for people who log in and grant permissions one platform at a time ^[2], and a single agent might hop between a dozen services for the same person, each of which needs to know where its authority ends ^[3].

The working part of Moca's system is small enough to test. A bank, telco, retailer or ticketing service verifies a user's data and issues a tamper-proof credential that the user holds ^[5]. An app checking whether someone passed KYC gets a certified confirmation and never receives the documents ^[6]. If the issuer revokes or updates the credential, every connected app sees the change without the user resubmitting anything ^[7]. For agents, AIR, the integration layer built on the chain ^[8], lets the user set permission rules. A merchant can then confirm the agent, its owner and the scope it was cleared for before offering a price or a deal ^[10].

Moca Network CEO Kenneth Shek said AI agents need scalable data sharing to act for people, and that "the trust framework for delegation and authority is lacking" ^[11]. According to The Next Web, he also said platforms have often traded away user privacy to make agent automation work ^[12].

Here's what users actually do, by the same account: they repeat the same verification over and over and leave copies of their data scattered across services ^[2]. Here's what teams tell themselves users will do on this system: hold their own credentials and write authorization rules for each agent ^[5][10]. That second habit depends on a settings screen the agent team builds and the user fills in. I'd expect most users to accept whatever default scope the app proposes.

On the business side, AIR runs in both directions. A company can turn checks it already performs into credentials, or accept credentials from trusted partners to speed up sign-ups and store less personal data ^[9]. According to The Next Web, AIR continues to add enterprise, infrastructure and data partners ^[13]; the report does not name them or say how many merchants verify agent credentials today.

For a team shipping a shopping or booking agent, I think support is justified where a merchant you depend on will check the credential, and premature everywhere else. The tradeoff is dependency. Your users' permissions and revocations would sit on one network ^[4][7], and a credential that nobody on the other side verifies does nothing for the user.

Two axes sort the decision. The first is whether the task already requires a check a business runs, such as KYC, a membership or a purchase limit ^[6][10]. The second is whether the merchants your agent visits verify AIR credentials before offering access or pricing ^[10]. Both true: integrate, and measure how many repeat verification steps drop out of a completed purchase. A task that needs a check at merchants that do not verify calls for a pilot with one merchant. Where merchants verify but the task needs no check, the existing login is enough. With neither, the trigger is the first merchant that asks your agent to prove its scope before quoting a price.