AI
AI Agent Identity in Finance: Why IAM Answers Fall Short
October 22, 2026
8 mins read
AI agent identity ties a software agent to its operator and the limits it acts under. In finance, login-level IAM leaves the liability question open.
AI agent identity is the set of facts that ties a software agent to a responsible operator and to the limits it acts under. In finance it has to answer three questions that enterprise identity and access management (IAM) was not built for: who is liable when the agent acts, what the agent was allowed to do, and what record shows it. Payment networks now call this layer Know Your Agent (KYA), and in September 2026 Ant International, Mastercard and Visa announced they would start work on a shared framework for it.
This guide explains what AI agent identity means for payment firms, fintechs and institutional DeFi teams, where today's answers stop, and what identity alone leaves unproven.
AI agent identity has three parts: operator, permissions and record
Most of the first answers to "what is agent identity" come from security teams, so they start with credentials. For a finance team the credential is the least interesting part. What matters is the chain behind it.
The first part is the operator: the person, cardholder or business that stands behind the agent and answers for what it does. The second is permissions: what the agent may buy, sign or move, up to what amount, and for whom. The third is the record: evidence that can be checked later, showing the agent acted inside those permissions.
In a16z crypto's AI in 2026: 3 Trends (January 2026), Sean Neville, cofounder of Circle and CEO of Catena Labs, noted that "non-human identities now outnumber human employees 96-to-1", yet these agents still have no access to banking. His proposed missing layer is KYA: cryptographically signed credentials that link an agent to its principal, its constraints and its liability. Until that exists, he argued, merchants keep blocking agents.
Each of the three parts maps to a question a risk or compliance lead already asks about human customers. KYA is the attempt to ask the same questions of software.
Identity frameworks cover who the agent is; the data behind its decisions still needs its own proof.Enterprise IAM answers access, not liability
IAM tools are good at what they were designed for. They decide whether a service account can call an API, rotate its keys, and log the session. Inside one company, where every service belongs to the same legal entity, that is enough: the company owns the outcome of whatever its services do.
Agent payments break that assumption. A shopping agent built by one company, acting for a cardholder at another, buying from a merchant on a third network, crosses several organizations in one transaction. The merchant needs to know more than "this request carried a valid token". It needs to know which operator is accountable if the purchase was wrong, whether this purchase was inside what the cardholder allowed, and how a dispute would be settled.
Those are liability and mandate questions. IAM covers the access layer under them, and finance needs the layers on top. That is why many top search results for "AI agent identity" come from enterprise security vendors, while the questions a payments team asks look so different.
Know Your Agent applies the KYC idea to software
KYC works because a regulated party checks a customer once, and others in the system can rely on that check. KYA tries to do the same for agents, and the payment networks are now treating it as shared infrastructure.
On 9 September 2026, Ant International, Mastercard and Visa announced a collaboration on a KYA interoperability framework. Each company already runs its own agent protocol: Visa Trusted Agent Protocol, Mastercard Verifiable Intent and Ant International's Agentic Mobile Protocol. The goal is shared principles so an agent checked on one network does not repeat every identity check on the next. The companies say the framework will focus on three areas:
- Cross-network operator traceability: "Each agent is linked to a validated operator, cardholder, or business / organization."
- Shared certification requirements: "Each agent is assessed against security and behavioral requirements."
- Continuous transaction monitoring: each agent is monitored using a mix of identity and transaction signals.
The work will run through BuildFin.ai, an industry platform convened by the Monetary Authority of Singapore (MAS), and builds on Safeguards for Agentic Finance at Runtime (SAFR), a white paper MAS published in July 2026 that proposes safeguards for AI agents in finance. That puts a regulator directly into the agent identity work.
It is worth reading the announcement for what it is. It is a statement of intent to collaborate. No shared technical specification or timeline was published with it, so teams should treat KYA as a direction that is forming, not a standard they can integrate today.
On-chain agent identity: what ERC-8004 provides
The crypto side has its own answer. ERC-8004, "Trustless Agents", is a draft Ethereum standard for finding and trusting agents across organizational boundaries without trust set up in advance. It adds three light on-chain registries:
- An identity registry, where each agent is an ERC-721 token pointing to a registration file that lists its name, services and supported trust models.
- A reputation registry, where clients leave signed feedback.
- A validation registry, where an agent can ask an independent validator to check its work.
The standard is open about its limits. Its security section says the registration file "cannot cryptographically guarantee that advertised capabilities are functional and non-malicious", and it leaves stronger guarantees to pluggable trust models such as re-execution, TEE attestation and zkML proofs.
The first large measurement study of ERC-8004, an arXiv preprint by Xiong, Wang and coauthors (June 2026, revised July 2026), shows why that matters. Across Ethereum, BNB Smart Chain and Base, about 173,000 agents were registered by mid-May 2026. On Ethereum, only 3% of them had a valid registration file that declares a service. Most registrations are placeholders, and the authors' answer to their own title question, "Can trustless agents be trusted?", is "Our measurements suggest NOT."
The study does not say the standard failed. It says ERC-8004 does what it explicitly provides, public identities and public feedback, and that this alone does not create trust. Its first recommendation is to separate a reserved identity from a live agent.
How the three approaches compare
| Enterprise IAM | Know Your Agent (payment networks) | ERC-8004 registry | |
|---|---|---|---|
| What it establishes | A service may access a system | An agent is tied to a validated operator and certified | An agent has a public identity, feedback and optional validations |
| Who checks it | The company's own security team | Card and wallet networks, with shared principles | Anyone reading the chain |
| Scope | One organization | Across payment networks | Across chains and organizations |
| What stays open | Liability across organizations | A shared spec and timeline; how decisions are recorded | Whether the agent is live and whether feedback reflects real work |
Each approach covers a real layer. Read together, they answer "who is this agent and who stands behind it" more fully. None of them yet answers what the agent actually saw when it acted.
Identity proves who acted, not what the agent acted on
Suppose a payments agent with a verified operator, a clean certification and a strong on-chain record makes a purchase that the cardholder disputes. The identity layer tells the merchant who to call. It does not show what price feed, inventory data, account balance or instruction the agent read at the moment it decided.
The KYA announcement speaks of accountability and of checking "that actions reflect the user's intent", but it does not describe how an agent's inputs are recorded for later review. ERC-8004's validation registry stores a hash on-chain while the inputs and outputs themselves live off-chain. In both cases, the integrity of the off-chain data behind an agent decision is the open design question.
This is the layer Orochi Network works on. zkDatabase, a verifiable database powered by Zero-Knowledge Proofs, generates a proof for every operation, so each data change can be checked as stored and processed as claimed. For agent workflows, zkDatabase is designed to keep the data an agent reads and writes off-chain while giving counterparties a proof they can check, without exposing the data itself.
Our next piece looks at that record directly: what an AI agent audit trail has to prove, and why access logs fall short of it. For the wider picture of how agents are changing institutional finance, see what agentic finance is and why institutional agentic finance needs a verifiable data layer. For the authorization side, see verifiable intent vs traditional authorization, and for the human parallel, ZK KYC and decentralized identity for financial institutions.
Sources
- a16z crypto, AI in 2026: 3 Trends (January 2026)
- Ant International, Mastercard and Visa, Know-Your-Agent interoperability announcement, Business Wire (9 September 2026)
- Ethereum Improvement Proposals, ERC-8004: Trustless Agents (Draft): https://eips.ethereum.org/EIPS/eip-8004
- Xiong, Wang et al., Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem, arXiv:2606.26028 (June 2026, revised July 2026): https://arxiv.org/abs/2606.26028
Explore zkDatabase
See how zkDatabase is designed to give agent workflows a verifiable data layer that counterparties can check without seeing the data.
Related toAI
