If you're shipping anything agentic in 2026 — an AI shopping agent, an autonomous procurement bot, a customer-service agent that can issue refunds — you're going to keep hearing the same three letters in compliance reviews: KYA. Know Your Agent.
It's framed as a new acronym, but the pattern is forty years old. Banking invented Know Your Customer to comply with anti-money-laundering law. Then the same pattern was bolted onto businesses (KYB), and now — because software agents can move money, place orders, and bind their operators to contracts — onto agents themselves.
Here's the framing we keep coming back to when developers ask us how all this stuff fits together:
KYC, KYB, and KYA aren't a comparison. They're a lineage. Each one applies the same risk-management primitive — verify identity, assess risk, apply controls, keep evidence — to a new class of actor as that actor becomes powerful enough to matter.
Agents are the new class. This post walks the lineage, explains what KYA actually proposes, and shows where it sits relative to UCP — because the two get conflated constantly and they're doing genuinely different jobs.
The lineage, in one diagram
┌──────────────────────────────────────────────┐
│ │
│ KYA ← Know Your Agent │
│ (a software actor with its own │
│ identity, reputation, audit trail) │
│ │
├──────────────────────────────────────────────┤
│ │
│ KYB ← Know Your Business │
│ (a corporate entity — │
│ UBOs, sanctions, controllers, │
│ source of funds) │
│ │
├──────────────────────────────────────────────┤
│ │
│ KYC ← Know Your Customer │
│ (a verified human — │
│ government ID, address, │
│ source of funds, sanctions) │
│ │
└──────────────────────────────────────────────┘
Read it bottom-up. KYC verifies humans, KYB verifies the companies they hide behind, and KYA verifies the software agents now transacting on behalf of both. (There's also KYE — Know Your Employee — the internal-HR variant for humans inside regulated companies; it's the same primitive applied to another actor class, but it's a stitched-together HR/IAM/GRC discipline rather than a discrete vendor category, so we'll mostly leave it aside here.)
That's the whole shape. Now the detail.
KYC — Know Your Customer
The original. Born out of US anti-money-laundering legislation (the Bank Secrecy Act, expanded by the USA PATRIOT Act) and replicated globally through FATF guidance.
KYC answers: is this person who they claim to be, and are they allowed to transact? Verification means government-issued ID, proof of address, source of funds for larger transactions, and ongoing screening against sanctions and politically-exposed-persons lists.
It's mandatory for regulated financial services and most account-opening flows. Failure to do it properly costs banks billions in fines every year. The KYC vendor market — Onfido, Persona, Jumio, Trulioo, Veriff and others — exists because KYC is law, not best practice.
KYB — Know Your Business
The corporate extension. When a bank onboards a business account, or one regulated entity onboards another (a payment processor onboarding a merchant, a fintech onboarding a SaaS company), KYC isn't enough. You need to verify the entity itself.
KYB answers: does this company actually exist, who controls it, what does it do, is it sanctioned? Verification means company registry lookup, beneficial owner identification (UBOs — the humans behind the legal entity), industry classification, sanctions screening of both the entity and its controllers.
KYB is where things get expensive and fragmented — beneficial-owner data quality varies wildly by jurisdiction, and ultimate ownership often runs through three or four shell layers before you hit a human. Most KYB vendors layer KYC on top: verify the entity, then verify the humans who control it.
KYA — Know Your Agent
The new entry. The term consolidated around 2024–2025 as AI agents started showing up in transactional flows — placing orders, authorizing payments, filing tickets, binding their operators to commitments. Some vendors brand it KYAI; some just say "agent identity." KYA has won as the shorthand.
The crucial conceptual move, and the one that breaks everything that came before: agents need their own identity, not borrowed user credentials. An agent acting on behalf of a user isn't the user. It's a separate actor with its own developer, its own version, its own behavioural history, and — once it's been in production for a while — its own reputation.
Eric Broda's framing in the Agentic Mesh writeups puts it cleanly: KYA applies the same primitive as KYC and KYB — verify identity, assess risk, apply controls, keep evidence — to software agents that can take real actions inside business workflows. The Trulioo + PayOS reference model ("Digital Agent Passport") proposes five concrete steps:
- Verify the agent developer. A real business behind it, KYB-style.
- Lock the agent code. Only approved code can run under that identity.
- Capture user permission. Proof of consent from whichever human is being represented.
- Issue a passport. A tamper-proof credential the agent can present at runtime.
- Continuous lookup. Revocation and behaviour monitoring in real time.
Vouched's variant (via Model Context Protocol – Identity, or MCP-I) adds reputation tracking and decentralised identifiers. Skyfire's version is a JWT-style agent credential — and their recent partnership with F5 makes the immediate commercial wedge clear: bot-management systems need a way to distinguish legitimate, revenue-generating agent traffic from malicious automation. "Don't block my AI shopping agent the way you'd block a scraper" is becoming the fastest commercial argument for KYA in the field.
Why agents broke the existing identity stack
The natural objection: can't an agent just use the human's OAuth token? We already have identity for the user — pass it down.
Three reasons that doesn't work, and they're the same three reasons KYA exists as a category at all.
1. Reputation belongs to the agent, not the user. If an agent built by Vendor X starts misbehaving across the ecosystem — abandoning carts, creating chargebacks, abusing returns — that signal needs to attach to the agent, not to every consumer who happens to use it. You could track reputation on (user_id, agent_id) pairs riding on borrowed user credentials, but it conflates two distinct accountability surfaces and misaligns liability. Agent-native identity keeps the two layers clean.
2. Revocation is per-agent, not per-user. When a vulnerability is found in a specific agent version, the response is "stop trusting this agent version everywhere, immediately" — not "log every user out." That needs a credential the issuer can revoke without nuking the user.
3. Audit trails need to attribute correctly. Regulators (and any sensible internal compliance function) will want to know which agent took which action. Did the user click the buy button, or did the agent autonomously decide to? OAuth alone collapses that distinction; KYA preserves it.
This is the philosophical wedge between KYA and "just bolt OAuth onto an agent." OAuth gives an agent the user's permission. KYA gives the agent its own accountable identity.
And there's a fourth reason that's about to matter more than the other three: regulators are arriving. KYC and KYB didn't become standard practice because banks volunteered them — they became standard because the Bank Secrecy Act, the USA PATRIOT Act, FATF guidance and successive AML directives across the EU made them mandatory. KYA is on the same trajectory. The EU AI Act already imposes obligations on operators of "high-risk" AI systems, including identification, logging and human-oversight requirements that map cleanly onto KYA primitives. Successive US executive orders on AI have pushed in the same direction, and FATF's emerging work on AI-driven financial flows is the next shoe to drop. The pattern with regulated identity has always been the same: voluntary best practice → industry standard → mandatory for regulated entities. KYA is mid-step-two right now, and the agents-touching-money use case is precisely where regulators tend to start.
The KYA landscape today
The vendor map is still being drawn — most of the work is happening in 2025 and 2026, and the category boundary keeps shifting. Here's a neutral roundup of the players and what each is actually shipping.
- Trulioo + PayOS are pushing the Digital Agent Passport reference model — the five-step framework that's becoming the most-cited architectural definition of what a KYA system needs to do.
- Skyfire is shipping the KYA token — a JWT-style agent credential — and pursuing the immediate commercial wedge through partnerships with bot-management vendors (notably F5). The story: let legitimate agent traffic through, block the rest.
- Vouched is shipping MCP-I (Model Context Protocol – Identity), extending MCP with identity primitives and adding reputation tracking and decentralised identifiers on top.
- Prove has positioned Verified Agent and KYAPay as the payment-flavoured framing — explicitly listing it alongside ACP, AP2, and UCP as a peer trust layer in their AI-native commerce framework.
- Persona is bringing its established dynamic-IDV stack into the agent context, leaning on the same orchestration engine that powers their human-verification flows.
A few adjacent acronyms are circling the same conceptual space — Prove's KYAPay, Vouched's MCP-I, Skyfire's KYA token. These are largely vendor brandings on the same underlying problem: how does a merchant decide whether to trust the software agent on the other end of the connection?
And it's worth flagging the competitive frontier honestly. Visa's Intelligent Commerce protocol bakes KYA-style identity directly into the Visa network; Mastercard's Agent Pay does the same for its rails. Some vendors are pitching their identity layer as the layer — not a layer on top of UCP, MCP, or AP2. So you'll hear both composition rhetoric ("we work with UCP") and substitution rhetoric ("our identity protocol replaces what UCP gestures at") in the same vendor decks. Worth knowing which one you're hearing.
How KYA sits relative to UCP
This is where developers building on UCP get tripped up, so it's worth spelling out carefully. UCP already does some of what KYA does — and explicitly punts on the rest.
What UCP already encodes. Every UCP request carries a UCP-Agent header pointing to a /.well-known/ucp profile. That profile publishes signing keys, so RFC 9421 HTTP Message Signatures can authenticate the platform cryptographically. The same profile serves as both capability declaration and key resolution — and verifiers must ensure the authenticated identity is consistent with the UCP-Agent header. So at the transport layer, UCP gives you "this request demonstrably came from the entity that controls profile X."
That's the cryptographic half of agent identity. Necessary, but not sufficient.
UCP also defines an Identity Linking capability via OAuth 2.0 — but that's user-to-merchant account linking (loyalty, wishlists, authenticated checkout), not agent attestation. And AP2 Mandates provide cryptographic proof of user consent specifically for the payment moment.
Where KYA layers in. UCP says nothing authoritative about:
- Who operates the entity behind a profile (the KYB-on-the-agent-owner question).
- Whether the agent's code is what its operator claims it is.
- The agent's behavioural reputation across merchants.
- The verified-human-behind-the-session question, beyond an OAuth grant.
- Revocation and continuous risk scoring.
So the clean composition story is this:
UCP is the protocol. KYA is the trust overlay. UCP gets the bytes from agent to merchant with provable origin. KYA tells the merchant whether to trust that origin — who's behind it, whether the user is real, whether this agent has misbehaved elsewhere.
The two are complementary, and the leading KYA vendors are largely pitching that way. The substitution rhetoric — "forget UCP, just use our identity protocol" — exists, but it tends to come from vendors whose protocols don't yet have the capability vocabulary UCP does. Compose the two; you get both halves.
Common questions
These are the exact questions we see most often when developers and compliance teams start mapping their agent-identity work.
What is the difference between KYC and KYA?
KYC verifies a human customer. KYA verifies a software agent. They operate at different layers and you increasingly need both.
KYC is the mandatory regulatory floor for onboarding a human into a financial relationship — government ID, address, sanctions screening. KYA is the equivalent pattern applied to the software agent acting on that human's behalf — verifying the developer, locking the code, capturing user consent, issuing an agent credential, monitoring behaviour over time. If your AI shopping agent represents a verified KYC'd user, you've covered the human; KYA covers the agent representing the human. Same regulatory logic, one abstraction level up.
What is the difference between KYB and KYA?
KYB verifies the company; KYA verifies the software the company built. KYA actually depends on KYB.
When a KYA framework "verifies the agent developer," it's running KYB on that developer's company — checking registration, controllers, sanctions. So KYB is the foundation: you can't trust an agent's passport unless you trust the entity that issued it. KYA then adds the agent-specific layer on top: which code is running, which user authorised it, what's the agent's behavioural track record.
Is AP2 a form of KYA?
AP2 is a narrow KYA primitive, not a KYA solution.
AP2 Mandates provide cryptographic proof that a specific user consented to a specific payment by a specific agent. That's one of the five things a full KYA framework does — the capture user permission step. AP2 doesn't verify the agent developer, doesn't lock the code, doesn't track reputation, doesn't handle revocation. A merchant integrating AP2 has solved consent-for-payment; they haven't solved Know Your Agent. Most production stacks will end up running AP2 inside a broader KYA framework, not instead of one.
Does UCP include KYA?
Partially. UCP provides cryptographic agent-identity proof at the transport layer — but not the operator verification, code attestation, or reputation tracking that complete KYA requires.
UCP's combination of /.well-known/ucp profiles, published signing keys, and RFC 9421 HTTP Message Signatures gives you cryptographic confirmation that a request came from the entity controlling a given profile. That's necessary infrastructure for KYA but it's not the whole stack — you still need to verify who that entity is (KYB), what code it's running (attestation), and whether you should trust its agent's behavioural history (reputation). UCP and KYA are designed to compose, not to substitute for each other.
Which should you actually adopt
Depends on what you're building.
If you're an agent or tooling developer, sign your requests properly — implement RFC 9421 Message Signatures, publish keys via your UCP profile, and start integrating with one of the KYA vendors (Trulioo, Skyfire, Vouched, Prove, Persona) so your agent can present a verifiable passport when merchants ask for one. The merchants that ask first will be the high-AOV ones.
If you're a merchant or platform, your first move is a clean UCP profile that establishes cryptographic agent identity at the transport layer — that's what a free check validates. Once that's in place, start tracking which KYA credentials the agents hitting your endpoint are presenting. You don't have to enforce KYA today, but you want visibility into what's coming through so you can move from passive logging to active policy when the standards mature.
If you're in risk or compliance, KYA is the bridge between your existing KYC/KYB programs and the new actor class your business is starting to transact with. Map your current KYC vendor's roadmap against KYA capabilities — Onfido, Trulioo, Persona, Jumio are all heading there, with very different positioning. Pick the vendor whose framing matches your buyer expectation: regulated-financial-services vendors will buy compliance-first language; commerce platforms will buy bot-management-first language.
If you're a payments company, AP2 is your immediate technical lane and KYA is your strategic envelope. AP2 Mandates fit inside a broader KYA story, and the payment networks (Visa Intelligent Commerce, Mastercard Agent Pay) are already pulling KYA-style identity into their rails. The question is whether to follow their identity layer, build your own, or partner with one of the dedicated KYA vendors.
The one-line summary
KYC verifies humans, KYB verifies the companies they hide behind, and KYA verifies the software agents now acting on behalf of both. The lineage is the same risk-management primitive — verify, assess, control, evidence — applied to each new class of actor as it becomes powerful enough to matter. KYA is mid-trajectory toward mandatory for regulated entities; cryptographic agent identity at the transport layer is shippable today.
UCP gives you cryptographic agent identity at the transport layer; the KYA category sits on top of it, adding operator verification, code attestation, consent capture, credential issuance, and behavioural monitoring. Together they're the trust stack for agentic commerce. Apart, each one only solves half the problem.
If you're getting started, the foundation is the same as every other piece of agent-readiness work: a valid, machine-readable UCP profile with proper signing keys.
- Check your manifest: ucpchecker.com/check
- Browse verified stores: ucpchecker.com/directory
- Developer guide to /.well-known/ucp: ucpchecker.com/well-known-ucp
- Related reading: MCP vs UCP vs AP2: What is the Difference?
- Related reading: The UCP Technical Council Just Shipped Attribution into Core
Top comments (0)