What Is Know Your Agent (KYA) and Why Should You Care?

June 26, 2026 ·Gustav Poola ·

know-your-agentkyaai-agent-identityauthenticationnon-human-identitynhimcpa2a-protocolw3c-dideu-ai-acteidas

Know Your Agent (KYA) is the emerging identity-verification paradigm for AI agents — analogous to Know Your Customer (KYC) for humans. The components are agent authentication, decentralised identifiers, verifiable credentials, and an agent capability and permission record. NIST launched its AI Agent Standards Initiative in February 2026; industry standards (Anthropic MCP, Google A2A, W3C DIDs) are converging through 2026-2027.

What Is Know Your Agent (KYA) and Why Should You Care?

In our work building identity primitives that scale from human workforces to non-human agent populations, the KYA question has moved from speculative to operational in the last twelve months. A Frankfurt-based payments-middleware customer of ours asked us last quarter how to attest agent identity for their internal Anthropic Claude deployment without rebuilding their entire IAM stack. A Helsinki-based fintech we work with is rolling out agentic workflows where one of their agents pays invoices on behalf of corporate customers, and their compliance team needs an audit trail that says which agent took which action under what delegated authority. These questions don't have a one-line answer in 2026, but they do have a name. This post is what we tell customers when they ask what KYA actually is — and why it matters before the AI Act conformity assessment lands. The AI Act Annex III high-risk framing this post leans on is covered from a different angle in our education-sector AI Act post on remote proctoring.

What does Know Your Agent actually mean in 2026?

The verifiable answer to four operational questions about every AI agent in your environment: who is it, what can it do, what is it authorised to do, and what did it actually do.

KYA is the paradigm parallel to KYC (Know Your Customer) — the framework retail banks built decades ago to verify the identity, source-of-funds, and risk profile of every customer before opening an account. KYA does the same thing for autonomous and semi-autonomous AI agents: it binds an identity to each agent, attests to its capabilities, records the permissions it has been granted, and produces an audit log of its actions. The category has been taking shape through 2025-2026 around three standards stacks landing in parallel — W3C Verifiable Credentials Data Model 2.0 for the credential layer, the Anthropic Model Context Protocol plus Google's Agent-to-Agent (A2A) Protocol for the agent-protocol layer, and NIST's AI Agent Identity Initiative for the regulatory framing — and the convergence on agent-identity-as-a-distinct-discipline is faster than most identity-paradigm shifts.

The thing the AI-agent vendor marketing doesn't say is that KYA is not a single product or single standard. It is a category assembled from several existing identity-and-access primitives — W3C decentralised identifiers (DIDs), verifiable credentials, OAuth-style delegated authorisation, audit logging, and policy enforcement — applied to a population of entities that didn't exist as a regulatory subject five years ago. The category is real and the urgency is real; the implementation is genuinely under construction, and the standards landscape is moving week by week.

For a 2026 deployment of any non-trivial AI-agent workload — a customer-service agent that calls APIs, a procurement agent that authorises payments, an internal-tools agent that touches CRM data — KYA is the framework the next round of compliance audits will read against. The conversation has shifted from "should we deploy agents" to "can we attest what our agents did and who they were when they did it".

Why should you care if you're deploying AI agents in your business?

Three converging pressures, each landing in 2026-2027.

Regulatory. The EU AI Act (Regulation (EU) 2024/1689) requires risk management, transparency, and human oversight for high-risk AI systems, with Annex III high-risk obligations applying from 2 August 2026 — see our earlier coverage of Annex III in the proctoring post. The Article 14 human-oversight requirement and the Article 12 logging obligation both presume a verifiable agent identity for every system that takes action — which means that "we used Claude" is not, by itself, a defensible answer when the audit asks which Claude instance, with what permissions, when, and under whose delegation. KYA is what makes that question answerable.

Operational. Agents fail differently from humans. When a human employee processes an invoice incorrectly, the audit trail goes back to that named human, their account, their training records, and the chain of authorisation that put them in that role. When an agent processes the invoice, the audit trail in 2026 typically stops at "the agent did it" — without a persistent agent identifier, the audit cannot distinguish between the agent acting within its remit, the agent acting outside its remit, and a different agent (or an attacker impersonating the agent) acting through the same channel. KYA collapses the ambiguity.

Cross-organisational. Agentic workflows in 2026 are increasingly multi-vendor — an agent on your stack calls an agent on a partner's stack, which calls a payment processor's agent, which calls a regulator's agent. Without KYA, every hop loses identity context; every audit becomes a forensic reconstruction. The convergence around Anthropic's Model Context Protocol (MCP) and Google's Agent-to-Agent (A2A) protocol — both shipping through 2025-2026 — is the industry-side answer to this, and they both presume a KYA-shaped identity layer beneath them.

If you sit with the NIST AI Agent Identity RFI text from March 2026 carefully, the part the AI-agent vendor marketing doesn't say is that NIST is treating agent identity as a Zero Trust extension question, layered on NIST SP 800-207 Zero Trust Architecture and the identity-proofing guidance in NIST SP 800-63-4. The pieces already exist for humans. KYA is what you get when you apply them to a population of entities that don't have passports.

What does a KYA framework actually cover?

Four layers, in roughly the order an audit will trace them.

Agent identity. A persistent, cryptographic identifier for each agent — typically a W3C Decentralized Identifier (DID) under DID Core v1.1 (Candidate Recommendation, 5 March 2026), often did:web or a custom method like the emerging did:agent. The DID resolves to a DID Document containing the agent's public key, service endpoints, and (increasingly) capability attestations. A verifier presented with an agent's claimed identity can check the cryptographic chain back to the DID document and confirm the claim against the issuing authority — typically the agent's deploying organisation.

Capabilities and credentials. What the agent is capable of doing — model version, tool access, knowledge domains — attested as W3C Verifiable Credentials (VC Data Model 2.0) signed by the deploying organisation or the model provider. This is where the emerging agent-attestation specs sit on top of the W3C VC layer. The verifier can confirm not just that the agent is who it claims to be, but that it has the capabilities its identity claims.

Permissions and delegated authority. What the agent is authorised to do — read this CRM record, charge that payment method up to this limit, sign this category of document on whose behalf — typically expressed as OAuth-style delegated tokens or as on-chain capability tokens. The emerging OAuth-for-Agents extension and the SPIFFE/SPIRE workload identity patterns (SPIFFE specification) are the standards-side answers. The permission record is the answer to "should this agent be doing this", separate from "can it do this".

Audit and accountability. What the agent actually did — every action signed with its identity, retained as an audit log, queryable by the deploying organisation and (where required) the regulator. The AI Act Article 12 logging requirement is the regulatory floor; the operational floor is whatever the compliance team needs to reconstruct an incident at month fourteen.

These four layers are conceptually separate. In production they are bound together through cryptographic chains — the identity signs the capability attestation, the capability scopes the permission grant, the permission constrains the audit record. Pulling any one of them out without the others gives you what we see in most 2026 agent deployments: an agent that can be identified but whose actions can't be authoritatively reconstructed, or an agent with audited actions but no verifiable identity. The four together are what the term KYA framework actually means.

Where are the standards landing in 2026?

Three converging tracks, each at a different stage of stabilisation.

The W3C track is the most mature. DID Core v1.1 is at Candidate Recommendation since 5 March 2026; Verifiable Credentials Data Model 2.0 has been a Recommendation since 15 May 2025; the Verifiable Credentials API and the holder-presentation specs are stable enough that production integrations work today. For an agent identity grounded in W3C primitives, the building blocks exist.

The protocol track — Anthropic MCP and Google A2A — is moving faster than W3C and slightly less coordinated. Model Context Protocol defines how an agent advertises and uses tools, including identity-bearing tool calls; A2A defines how agents discover and authenticate to each other. Both presume but do not specify the underlying identity primitive. The bridge layer being assembled in 2026 brings W3C-style identity into the protocol layer through MCP identity extensions and A2A agent-card credential references.

The regulatory track — NIST and the EU AI Act — is the slowest moving but the most binding. NIST's AI Agent Standards Initiative, launched February 2026, is the US position; the EU AI Act's Article 12 + 14 requirements are the EU position. The NIST RFI comment window closed in April 2026 and the substantive output is expected through 2026-2027. The EU AI Act timeline runs through August 2027 for the bulk of high-risk obligations.

The honest engineering reading is that 2026 is the year the foundations stabilise and 2027 is the year they get audited. Customers who ship agent deployments now against a KYA-shaped architecture — DID-anchored identity, VC-attested capabilities, delegated permissions, signed audit log — are in a fundamentally different position from customers who ship against a "just deploy Claude" architecture and figure out the identity layer later.

What we tell customers when they ask about KYA in 2026 is to start where the audit will start: the identity layer. Adopt a persistent identifier for every agent before the agent ships into a production workflow. Attest capabilities cryptographically. Wire permissions through delegated authority rather than ambient credentials. Log everything against the identity. The pieces all exist as standards in 2026; what's missing is the deployment discipline to actually use them.

Why agent identity has to be tied to a verified human delegator

This is the part of the KYA conversation that the industry discussion mostly skips — and where our view at IdentiGate differs from the standard framing.

The standard KYA framework names the agent as the entity whose identity, capabilities, permissions, and actions need verifying. That is necessary, but it is not sufficient. Every action an autonomous agent takes is ultimately under delegated authority — a human, or a legal entity through one of its authorised representatives, granted the agent the authority to take that action. When the regulator's audit reconstructs an incident at month fourteen and asks who authorised this agent to charge this customer's card, the answer cannot terminate at "the agent's deployment configuration". The answer that survives audit ends at a verified human whose delegation can be cryptographically traced to the specific agent and the specific action.

What we think KYA actually requires, beyond the four layers the industry discussion lists, is a second identity binding on the same chain — the delegating human (or legal-entity representative). We ship identity verification for both, with the same primitives. The human delegator is verified through the foundation-layer chip-anchored proofing primitive we ship as the Identity Verification product — biometric passport NFC for the 179 ICAO 9303 countries, document authenticity plus biometric face match (FaceTec liveness) for every remaining country, output as an Advanced Electronic Signature (AdES) record under eIDAS Article 26. The agent's identity sits at the Identity of Things product — a DID-anchored identifier with capability attestations and the delegated permissions the human granted.

The chain that binds them is what makes the audit defensible. The delegating human signs an AdES delegation statement naming the specific agent, the specific scope of authority, and the specific duration. The agent's actions are signed with its own DID-anchored identity, and reference the delegation statement at every action. The audit reconstruction at month fourteen traces: this signed action → references this delegation statement → signed by this verified human → identity-proofed at this admission moment with this chip-anchored AdES record. Pull the human delegator out of the chain and the audit terminates at the agent; reinsert the human and the chain has a regulatory subject who can be held accountable.

We are not a KYA platform provider — we do not ship the agent-side attestation or the credential-issuance layer that KYA orchestrators build on top of us. We sit at the foundation-layer identity primitives that KYA implementations consume — identity verification for the delegating human, identity of things for the agent, and an AdES delegation chain between them that survives the audit. The integrations we see landing in 2026 are the customers who realised the agent-only view of KYA leaves the chain dangling and asked us how to attach the chain to a verified human at the other end.

The IdentiGate angle here also sits in the Authentication product for the agent-to-service authentication that follows once the delegation chain is in place. The full stack — verified human, signed delegation, agent identity, action audit — is what we mean when we talk about KYA in our customer conversations.

Sources

Primary — KYA framework and standards

Primary — adjacent EU regulatory framework

Regulation (EU) 2024/1689 — EU AI Act — EUR-Lex

About the author

Gustav Poola is co-founder of IdentiGate. He focuses on the technical architecture of passport-chip identity verification, advanced electronic signature production under eIDAS, and the engineering of identity flows that survive regulator and auditor walk-back.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.