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

The next account opened on your platform will not be opened by a human.

That sounds like marketing. It is not. In 2026, the entity submitting a form, calling your API, or attempting a payment is increasingly an autonomous AI agent acting under a person's instructions. Visa launched Agentic Ready as a payment framework for AI-driven commerce. Mastercard followed with Agent Pay. OpenAI, Anthropic, and Google ship agent runtimes with tool use, browser control, and payment authority baked in. The Model Context Protocol turned tool invocation by agents into a standard.

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

What KYA actually is

KYA is the verification layer for non-human actors. It validates three things, none of which are optional:

Identity. The agent has a cryptographic identity that resolves to its owner, its operator, and its execution context — not a username, not an API key in someone's pocket. This is exactly what W3C Decentralized Identifiers (DIDs) and Verifiable Credentials were standardized for, applied to software actors instead of humans.

Authority. The agent can prove it is acting within 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." The presence of a key is not the same as the presence of consent.

Provenance. The agent runs on a model and tool stack you can attest to — known weights, known guardrails, known supply chain. The growing ecosystem of agent builders, 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 KYC check tells you "a human verified once." A KYA check tells you "this agent, with this mandate, on this model, is acting right now." They are not interchangeable, and one does not subsume the other.

Why this is urgent in 2026, not 2030

Three forces collapsed the timeline.

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

Tool-use is the new attack surface. An agent given a browser, a payment tool, and a memory store has the action capability of an employee with company-card access — but with 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. Verifying the agent's identity and mandate is the only thing that stops a successfully prompt-injected agent from spending its principal's money.

Regulators are starting to ask. The EU AI Act includes transparency obligations under Article 50 for 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. AMLR's continuous CDD logic does not stop at the human; if an agent moves money, the agent's action is the relevant CDD event.

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

The three pillars, anchored in real standards

Cryptographic agent identity. Each agent carries a DID and a Verifiable Credential issued by its operator, which itself binds the agent to a principal. The handshake is a verifiable presentation, not a bearer token. This is 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. The Verifiable Credential the agent presents includes the scope: amount, merchant category, jurisdiction, time window, action type. Your platform does not have to trust the agent's claim about what it is doing; it validates that the action requested is inside the cryptographically signed mandate. If the agent tries to do something outside the mandate — because it was prompt-injected, hijacked, or simply confused — 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. This is the ML-BOM idea (an SBOM for the AI stack) made operational. The pattern that defeats Fraud 4.0's AI-versus-AI dynamic at the agent layer is exactly this: an agent whose model is sanctioned and whose runtime is attested is a different risk class from an agent whose runtime is unknown.

These three together 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

Skipping KYA does not just create fraud exposure. It collapses several controls at once.

A legitimate user delegates to an agent, the agent gets prompt-injected via a malicious web page it browses, and it executes a payment the user did not authorize. Without KYA, your fraud system 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. Without KYA, distinguishing them requires heuristics. With KYA, the credentials simply do not validate.

An auditor asks who took an action and on whose authority. Without KYA, you can show an authenticated session and a user ID. With KYA, you can show the cryptographic chain from human → mandate → agent → action. The second one survives a regulator.

The industry's 20-point response to AI identity fraud explicitly recognises this. Several of its measures only function if there is an agent-identity layer underneath; you cannot defend against agent-driven fraud at scale without first being able to identify the agents.

KYA is the upper half of identity infrastructure

KYC verifies the human. KYC 3.0 turns that verification into a continuous, predictive signal. KYA verifies the agent the human delegated to. Continuous KYA — verifying the agent on every consequential action, not once — closes the loop.

This is the shape of identity infrastructure for the rest of the decade: 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. The 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. The human is still verified at the bottom of the stack — KYC 3.0 makes that continuous. KYA verifies the agent the human delegated to. One does not remove the need for the other.

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

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

Does KYA require my platform to change every login flow? No. KYA is invoked when an agent presents itself to your platform — typically via a standardized credential exchange at the API gateway or payment authorization layer. Existing human-only flows continue unchanged. The work is at the perimeter, not in every product surface.

What about prompt injection of a verified agent? KYA does not stop the agent from being confused. It stops a confused agent from doing damage. If a prompt-injected agent tries to act outside its mandate, the verification fails at the platform and the action does not execute. The credential is "agent is allowed to spend on category X up to amount Y," not "agent is allowed to do anything."

If non-human traffic is reaching your platform — and it is — 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.