Know Your Agent (KYA): identity verification for AI agents

A human will not be the one opening the next account on your platform.

Marketing copy is what that sounds like. It is not. The entity submitting a form, calling your API, or attempting a payment is, in 2026, more and more an autonomous AI agent acting under a person's instructions. Visa launched Agentic Ready as a payment framework for AI-driven commerce. Agent Pay came from Mastercard next. Agent runtimes shipping from OpenAI, Anthropic, and Google already bake in tool use, browser control, and payment authority. Tool invocation by agents became a standard once the Model Context Protocol arrived.

One question is what your KYC stack was built to answer: is the human on the other side who they claim to be? That question does not even parse once the actor is a piece of software. A different one is required: which agent is this, who authorized it, and what is it allowed to do? KYA — Know Your Agent — is that question. Treat it as a footnote to KYC and you leave a gap that fraudsters and auditors will both walk through.

What KYA actually is

Non-human actors get a verification layer, and that layer is KYA. Three things get validated. None of them is optional:

Identity. A cryptographic identity on the agent resolves to its owner, its operator, and its execution context — not a username, not an API key sitting in someone's pocket. W3C Decentralized Identifiers (DIDs) and Verifiable Credentials were standardized for exactly this, applied here to software actors instead of humans.

Authority. Proof that the agent is acting inside a mandate the principal granted: this user authorized this agent to spend up to this amount on this category of merchant during this window. Capability-style authorization, not "trust the bearer token." A key being present is not the same as consent being present.

Provenance. The model and tool stack the agent runs on can be attested — known weights, known guardrails, known supply chain. Agent builders form a growing ecosystem, and the rise of autonomous AI agents in compliance only works if the verifier downstream can tell a sanctioned model from a jailbroken one.

"A human verified once" is what a KYC check tells you. "This agent, with this mandate, on this model, is acting right now" is what a KYA check tells you. They are not interchangeable. One does not subsume the other.

Why this is urgent in 2026, not 2030

The timeline collapsed under three forces.

Agentic payments left the lab. Production rails now carry real card-not-present authorizations from autonomous agents: Visa's Agentic Ready, Mastercard's Agent Pay, and Stripe's agent toolkits. The infrastructure exists. The verification layer for the agents is mostly improvised. Viewed from the financial-institution side, that is the same gap we map in Know Your Human: KYC's agentic payment gap.

Tool-use is the new attack surface. Give an agent a browser, a payment tool, and a memory store and it has the action capability of an employee with company-card access — plus the prompt-injection vulnerability of a chatbot. OWASP's LLM Top 10 (LLM01 prompt injection, LLM06 insecure output handling, LLM07 system prompt leakage) describe attacks that, applied to a tool-using agent, become unauthorized transactions instead of leaked text. Stop a successfully prompt-injected agent from spending its principal's money and the only thing that does it is verifying the agent's identity and mandate.

Regulators are starting to ask. Transparency obligations under Article 50 of the EU AI Act cover AI systems that interact with people, and the broader compliance picture under the Act's August 2026 high-risk obligations creates accountability for deployers when an agent acts on a user's behalf. Continuous CDD logic under AMLR does not stop at the human; move money with an agent and the agent's action is the relevant CDD event.

Even one customer using an agent-based assistant to interact with your platform — and by mid-2026 you have that customer, whether you know it or not — means unverified non-human traffic sits in your authentication funnel.

The three pillars, anchored in real standards

Cryptographic agent identity. A DID and a Verifiable Credential issued by its operator sit on each agent, and that credential itself binds the agent to a principal. A verifiable presentation is the handshake, not a bearer token. The same machinery used in the EU's eIDAS 2.0 wallet rollout, applied one level up: the wallet verifies the human, the credential verifies the agent the human delegated to.

Mandate and intent verification. Scope lives inside the Verifiable Credential the agent presents: amount, merchant category, jurisdiction, time window, action type. Trusting the agent's claim about what it is doing is not required; your platform validates that the requested action sits inside the cryptographically signed mandate. Try something outside that mandate — prompt-injected, hijacked, or simply confused — and the action fails at the verification layer, not at the chargeback queue.

Model provenance and reputation. A signed attestation of the agent's runtime — base model, fine-tunes, tool set, safety configuration — bound to the credential. Operational form of the ML-BOM idea (an SBOM for the AI stack). At the agent layer, this is the pattern that defeats Fraud 4.0's AI-versus-AI dynamic: an agent whose model is sanctioned and whose runtime is attested is a different risk class from an agent whose runtime is unknown.

Together the three produce something a static API key cannot: a runtime-verified, mandate-bound, provenance-attested actor. That is the floor for letting a non-human take consequential actions on your platform.

What breaks if you skip it

Fraud exposure is not the only result of skipping KYA. Several controls collapse at once.

A legitimate user delegates to an agent. Via a malicious web page it browses, the agent gets prompt-injected. A payment the user did not authorize then executes. Your fraud system, without KYA, sees a transaction from a verified user's device and approves. With KYA, the payment fails because the mandate did not include "send funds to attacker-controlled address."

A bad actor builds an agent that mimics a legitimate one — same name, same UX, same API patterns. Distinguishing them without KYA requires heuristics. With KYA, the credentials simply do not validate.

An auditor asks who took an action and on whose authority. An authenticated session and a user ID are what you can show without KYA. With KYA, you can show the cryptographic chain from human → mandate → agent → action. A regulator is survived by the second one.

This is recognised explicitly in the industry's 20-point response to AI identity fraud. Several of its measures only function if there is an agent-identity layer underneath; defending against agent-driven fraud at scale is impossible without first being able to identify the agents.

KYA is the upper half of identity infrastructure

The human is what KYC verifies. That verification becomes a continuous, predictive signal under KYC 3.0. The agent the human delegated to is what KYA verifies. Continuous KYA — verifying the agent on every consequential action, not once — closes the loop.

Identity infrastructure for the rest of the decade takes this shape: a human verified continuously, agents verified per action, mandates signed and revocable, and provenance attested all the way to the model weights. Vendors built around 2010-era ID-document-and-selfie KYC will retrofit. Platforms that ship KYA natively will get the agentic traffic by default, because they will be the ones the Visas and Mastercards of the world can route consequential agent commerce through without inheriting the liability.

That is the Joinble bet. Our agentic KYC architecture already runs on the assumption that the actor may be an agent; KYA is the layer that makes that assumption operational. We are not retrofitting selfie-based vendors for the agent era — we built for it.

Frequently Asked Questions

Is KYA replacing KYC? No. KYA sits on top of KYC. Still verified at the bottom of the stack is the human — KYC 3.0 makes that continuous. The agent the human delegated to is what KYA verifies. Need for one is not removed by the other.

How is KYA different from API authentication? A client is what an API key authenticates. An agent's cryptographic identity, the principal it acts for, the mandate it operates under, and the provenance of its model and tools are what KYA verifies. Fully usable by an attacker is a leaked API key; a stolen KYA credential without the mandate it was signed with grants nothing actionable.

Why W3C DIDs and Verifiable Credentials? They already exist as standards, they are being deployed under eIDAS 2.0 for human wallets, and they are the only mature, interoperable cryptographic identity primitives. Keep the human and the agent in the same identity graph instead of in parallel silos by building KYA on the same substrate.

Does KYA require my platform to change every login flow? No. Invocation of KYA happens when an agent presents itself to your platform — typically via a standardized credential exchange at the API gateway or payment authorization layer. Human-only flows that already exist continue unchanged. The work sits at the perimeter, not in every product surface.

What about prompt injection of a verified agent? Confusion of the agent is not what KYA stops. Damage from a confused agent is. Act outside its mandate and a prompt-injected agent fails verification at the platform; the action does not execute. "Agent is allowed to spend on category X up to amount Y" is the credential, not "agent is allowed to do anything."

Non-human traffic is reaching your platform — and it is — so your KYC stack is no longer the whole answer. Talk to our team about wiring KYA into your authentication and payment layers before the regulators ask why you did not.