Know Your Agent: Why AI Agents Need Identity Verification

AI agents are no longer just drafting emails. They are starting to buy things, book things, and move money on behalf of the people who deploy them. Major payment networks announced agentic payment initiatives in 2025, signaling that the infrastructure for agent-initiated commerce is being built in earnest. What hasn't been built is the identity layer underneath it: a way for the other side of a transaction to know who an agent is, who it acts for, and what it is allowed to do.

A note before we start: parts of this post describe infrastructure that exists today, and parts describe where we think things are heading. We'll flag which is which.

The trust gap

When a human checks out on an e-commerce site, the merchant has a stack of signals: a logged-in account, a card with 3-D Secure, device fingerprints, behavioral history. When an autonomous agent shows up at the same checkout (or at an API, or in a negotiation) most of those signals are missing or meaningless.

The merchant is left with three questions it currently cannot answer reliably:

• Is this agent authorized at all? Or is it a scraper, a fraud bot, or a hijacked process?
• Whom is it acting for? A real, identifiable person or business, or nobody?
• Within what mandate? Authorized to spend up to a limit, in a category, for a time window, or claiming authority it was never given?

Today's answers are improvised: API keys, allowlists, terms-of-service clauses, and hope. None of those bind the agent to a verified principal, and none travel across services. That gap is what "know your agent" (KYA) names. (The acronym collides with an older compliance usage, "know your applicant"; we unpack the family tree in KYC vs KYB vs KYA.)

Bot detection is the wrong frame

The reflexive response to automated traffic has always been to block it: CAPTCHAs, rate limits, bot-management products. That made sense when nearly all bots were adversarial. It stops making sense when your best customers start sending agents to do their shopping.

The goal is not to keep automation out. It is authenticated delegation: letting automation in when, and only when, it can prove it acts for an accountable principal within a defined scope. A merchant doesn't actually care whether a request came from a human's fingers or an agent's API call. It cares whether someone accountable stands behind the transaction. Framing the problem as bot detection optimizes for the wrong outcome: it punishes legitimate delegation while sophisticated bad actors route around the defenses anyway.

This reframing matters commercially, too. Sites that can verify agents can serve them confidently, and a verified agent with a real budget is a customer, not a threat.

Delegation chains: human, credential, agent

So what does authenticated delegation look like structurally? As a chain with three links:

1. A verified principal. A human (or business) completes identity verification once and holds the result as a credential. This is exactly the reusable KYC model that exists today.
2. A delegation credential. The principal issues, or authorizes the issuance of, a credential to the agent, cryptographically derived from or linked to the principal's verified identity.
3. A scoped mandate. That credential encodes what the agent may do: spending caps, merchant categories, expiry times, revocation conditions.

When the agent transacts, the counterparty verifies the agent's credential, checks that the chain resolves to a verified principal, and checks the action against the mandate. No call back to the issuer, no guessing: signature verification all the way up.

The deep precedent here is that delegation chains are not new. Power of attorney, corporate signing authority, and OAuth scopes all express "this entity acts for that one, within these limits." What's new is needing it machine-verifiable, portable across the open internet, and anchored in verified real-world identity.

How verifiable credentials map to agents

This is where the speculative part begins, so let's be explicit: standards bodies and industry groups are actively working on agent identity and delegated authorization, but no dominant scheme has won, and what follows is our view of the likely shape, not a description of deployed infrastructure.

The W3C Verifiable Credentials model fits the problem unusually well because it never assumed the holder was human. Its three roles (issuer, holder, verifier) apply cleanly:

• The agent is a holder with its own key pair and identifier.
• Its credential is issued under the authority of its principal's verified identity: the human's KYC credential becomes the root of the agent's legitimacy.
• Permissions live in the credential as claims: scope, limits, validity period.
• Selective disclosure lets the agent prove "I act for a verified adult in Germany with a €500 monthly mandate" without revealing who that person is.
• Revocation gives the principal a kill switch: rotate or revoke the credential, and the agent's authority dies with it, everywhere at once.

We cover the underlying standard in detail in W3C Verifiable Credentials Explained.

What an agent-readable identity layer looks like

If KYA infrastructure emerges along these lines, it needs three properties to actually work at internet scale:

• Machine-verifiable. Verification must be a cryptographic check an API can perform in milliseconds, with no document uploads and no human review loops in the transaction path.
• Standards-based. Agents built by one vendor must be verifiable by services built by another. Proprietary agent-identity silos would just recreate today's fragmented KYC, one walled garden per platform. Open standards like Verifiable Credentials and OpenID4VC are the plausible substrate.
• Privacy-preserving. Delegation must not turn every agent transaction into surveillance of its principal. Proving "authorized, within mandate, accountable if it goes wrong" should not require broadcasting the principal's identity to every counterparty.

There's also a regulatory shoe yet to drop. AML rules were written for humans and legal entities; when agents initiate payments at scale, regulators will ask who performed customer due diligence on the principal behind the agent. Entities that can already trace agents to verified, credentialed principals will find that question easy. That is speculation about timing, not about direction. The direction follows from how every previous wave of financial automation was regulated.

Where OpenKYC fits

OpenKYC is building a reusable KYC marketplace on open standards (W3C Verifiable Credentials, OpenID4VC): verify once, hold the credential in your own wallet, reuse it everywhere, and earn every time it's used. A verified human credential is the natural root for agent delegation, and that's the foundation we're laying. Join the waitlist at openkyc.org.