Know Your Agent is half a check

A new compliance category arrived in 2026. Know Your Agent verifies the company that publishes an AI agent and registers the agent itself, and that work is genuinely necessary. It also answers a different question from the one that liability turns on, because the accountable human is still missing from the request.

Picture the meeting. A payments company, a Thursday, a conference room with a vendor deck on the screen. The head of financial crime compliance has sat through eleven of these this quarter. The deck is good. It explains that agent traffic is arriving at the platform's checkout, that the platform currently cannot tell one agent from another, and that the vendor can fix this: verify the operator behind each agent the way you would verify a business customer, register each agent with a cryptographic key, check the registration on every request, and maintain a revocation list. There is a diagram with green ticks.

She has one question, and she asks it in the plain way that compliance people ask things when they already suspect the answer. "When one of these agents buys something, who is the customer?"

The room pauses. Someone says the operator. Someone else says the end user. The vendor says that the agent acts on behalf of the end user, and that the platform passes a user identifier in the request. She asks where that identifier comes from. It comes from the agent. She asks what proves it. Nothing proves it. The identifier is a string that the agent puts in a field, and the whole verified, registered, cryptographically signed apparatus attests that a particular piece of software from a particular company sent the request, which is a real and useful fact, and is not the fact her obligations attach to.

This is not a failure of the vendor. The vendor built exactly what the market asked for. It is a failure of the analogy the market chose.

What is Know Your Agent, and what does it actually verify?

Know Your Agent, usually shortened to KYA, is the practice of establishing who is behind an autonomous software agent before you let it transact with you. It emerged in 2026 as agent traffic stopped being a curiosity and started being a payment flow. Identity verification vendors moved into it quickly, with Sumsub reported to have launched a commercial KYA offering in January 2026, and analysts including Tiger Research have mapped an early standards race across several competing approaches.

It is worth being precise about what a KYA check contains, because the components are individually sensible and the sum is where the trouble is.

The three things KYA checks

First, operator verification. This is Know Your Business by another name. The vendor establishes that the company publishing the agent exists, is registered, has beneficial owners who are not sanctioned, and has a real address and a real director. This is mature work. Compliance teams have done it for decades and the tooling is excellent.

Second, agent registration. The agent gets an identity: a listing in a registry, a key pair, a declared purpose, a declared scope of permitted actions. Requests from the agent carry a signature so a server can confirm the request came from that registered agent and was not altered in transit. The technical mechanism here is usually HTTP message signatures, standardised as RFC 9421, which is the same machinery underneath Cloudflare's Web Bot Auth work.

Third, ongoing standing. Reputation scores, incident history, revocation. If an agent misbehaves, it can be delisted, and verifiers checking the registry stop accepting it.

Every one of those three is necessary. A world where agent traffic is anonymous and unattributable is worse than a world with KYA, and the people building this deserve credit rather than sniping. If you are a merchant deciding whether to let agent traffic through your checkout at all, KYA is the difference between a decision and a coin flip.

Why the sum is still incomplete

Here is the whole problem in one sentence. A verified agent, published by a verified operator, correctly signing every request, acting for nobody in particular or for the wrong person entirely, passes KYA cleanly.

Nothing in the check is false. The operator really is that company. The agent really is that agent. The signature really does verify. And the question of whether a specific human wanted this specific thing to happen has not been asked, let alone answered.

To see why that matters, it helps to remember why the check KYA is modelled on exists at all.

Why does KYC exist in the first place?

Customer due diligence did not appear because regulators enjoy paperwork. It exists because obligations attach to people, and because for most of the twentieth century it was straightforward to arrange matters so that no person was visibly attached to anything.

The mechanism was intermediation. You do not open an account in your own name. You form a company, and the company opens the account. If someone asks who owns the company, another company owns it, incorporated somewhere with thin disclosure. If someone asks about that one, a trust holds it, and the trustee is a professional who holds a thousand such positions. Every layer is legal. Every layer is documented. And the natural person who actually receives the benefit is four hops away from anything a bank can see.

The lesson of the shell company

The regulatory response took thirty years and it converged on a single idea: follow the layers until you reach a human, and record that human. The Financial Action Task Force built this into its recommendations on transparency and beneficial ownership of legal persons. The United States implemented the customer due diligence rule requiring covered institutions to identify beneficial owners of legal entity customers, and later the beneficial ownership reporting regime under the Corporate Transparency Act. The European Union built registers. The details differ by jurisdiction and the politics are contested, but the underlying principle is uncontested and it is worth stating plainly.

You have not identified your customer until you have identified a natural person. Everything between you and that person is an intermediary, and intermediaries are things you record, not things you accept in place of the answer.

Now hold that sentence next to a KYA programme and read it again.

Is an AI agent a customer, or an instrument?

This is the question the whole category turns on, and getting it wrong at the start will be expensive to fix later.

The KYA framing treats the agent as a customer analogue. You verify it the way you verify a business: who is it, who owns it, is it in good standing, what is it permitted to do. That framing produces a coherent programme, which is precisely what makes it dangerous, because coherent programmes that answer the wrong question are the hardest to dislodge.

Consider what an agent actually does in a transaction. It receives an instruction. It selects a merchant. It presents a payment credential. It completes a purchase on behalf of someone. Now list the other things in the financial system that do exactly that set of operations on behalf of someone else: a payment terminal, a broker's order management system, a corporate treasury workstation, a payment initiation service provider, a power of attorney holder, a bank teller.

Not one of those is the customer. Every one of them is an instrument, an intermediary, or an agent in the legal sense, and in every case the compliance obligation attaches to the person on whose behalf it acts.

The wire transfer software test

Here is the test that makes it concrete. Imagine a bank told its regulator that it had implemented a rigorous customer due diligence programme, and on inspection it turned out the programme verified the wire transfer software: which vendor wrote it, which version was installed, whether the vendor was in good standing, and whether the software's cryptographic certificate was valid. All of that checked out on every transfer. The bank had no idea which account holders had instructed the transfers.

No regulator on earth would accept that. The examination would not be close. And yet, transposed into agent terms, it is close to what a KYA-only programme delivers: rigorous verification of the tool, silence on the principal.

The agent is not the customer. The agent is the newest and most capable intermediary ever built, arriving in a system whose entire transparency architecture was constructed to see through intermediaries, and arriving faster than that architecture can adapt.

There is one important disanalogy and it cuts the same way. A wire transfer terminal does not decide anything. An agent selects, negotiates, and initiates, which means the space of things it can do without a fresh human decision is enormous compared to any intermediary that came before. That makes the anchoring question more urgent, not less.

What does a complete check actually require?

If the agent is an intermediary, then a complete check has the same shape as any other intermediated transaction: identify the intermediary, identify the principal, establish the authority connecting them, and confirm that the authority is current.

That gives four questions, and only the first is well covered today.

Read the third and fourth rows together. That is the gap. Everything above them is engineering that is largely done. Everything below them depends on them.

The four questions a verifier should be able to answer

Which agent is this? Answered by KYA today, well.

Whose human is behind it? Not answered. The request carries a user identifier chosen and populated by the agent, which is an assertion by an interested party.

What did that human permit? Not answered independently. The operator declares a scope, and the operator benefits from the scope being broad.

Is that permission still current? Not answered. Agent-level revocation removes the agent. It says nothing about whether a particular human's authorisation was withdrawn while the agent remains in perfectly good standing for everyone else.

What about platform held user keys?

This is the most important objection to work through, because it is the thing many designs already do and it looks like it closes the gap.

Several agent payment designs include a signed statement of user intent. The user approves something in the platform's interface, and the platform produces a signed object recording that approval. This is a real improvement over nothing, and the designs that do it are better than the designs that do not.

The question to ask of any such object is short: who holds the private key?

If the platform holds it, then the signature is the platform asserting that a user approved something. That is a platform assertion with cryptographic packaging. It is exactly as trustworthy as the platform, which may be very trustworthy, and it is not independent evidence. If the platform is compromised, the assertion is compromised. If the platform is wrong, the assertion is wrong with high confidence and a valid signature. If the platform's own consent screen was rendered inside a session an attacker had stolen, the assertion faithfully records an intent that was never formed.

The signature stamp in the drawer

Think of a rubber signature stamp with your name on it, kept in a drawer in someone else's office. Every document that comes out of that office bears your signature, and every one of them is genuine in the sense that the stamp is really your stamp. What the stamp cannot tell anyone is whether you were in the room. A signature that lives on your own device, and that only produces output when you unlock it, is a different kind of fact entirely, because possession and use are yours.

This is the distinction between authenticity of a document and authenticity of consent, and it recurs throughout this series. We wrote about it from the payments side in the token proves the agent may pay, and from the attacker's side in your MFA worked perfectly. The same failure appears in both because it is the same failure.

What does human anchoring look like on the wire?

The good news is that this composes. Nothing here requires replacing KYA. It requires carrying one more field, and being able to verify it without asking the operator anything.

An agent request today carries a signature over the request, per RFC 9421, proving which agent sent it. The addition is a reference to a delegation that the human signed on their own device. The verifier fetches or receives the delegation, checks it, and checks that this request falls inside it.

POST /v1/orders HTTP/1.1
Host: merchant.example
Signature-Input: sig1=("@method" "@authority" "@path"
    "content-digest" "manav-delegation");
    created=1789012345; keyid="agent-key-8f21"; alg="ed25519"
Signature: sig1=:MEUCIQD...:
Content-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
Manav-Delegation: dlg_01J8Q4X2M7VN3KP9
Content-Type: application/json

{"sku":"AX-4410","qty":1,"amount":"149.00","currency":"USD"}

Two independent facts now travel with the request. The Signature header proves the agent. The Manav-Delegation reference points at the human's authorisation. Neither substitutes for the other, and a verifier that checks only one has checked only half.

The delegation the human actually signed

Here is the object the reference resolves to. It is signed by a key that lives in the human's device secure element and never leaves it. The agent cannot mint it, the operator cannot mint it, and Manav cannot mint it.

{
  "v": 1,
  "id": "dlg_01J8Q4X2M7VN3KP9",
  "humanKey": "ed25519:2yF9...c7Ab",
  "delegateKey": "ed25519:8f21...9dE3",
  "scope": {
    "actions": ["purchase.create"],
    "merchantCategories": ["5734", "5943"],
    "maxAmountPerAction": "250.00",
    "maxAmountTotal": "1000.00",
    "currency": "USD"
  },
  "constraints": { "maxChainDepth": 1 },
  "notBefore": "2026-09-18T09:00:00Z",
  "notAfter":  "2026-10-18T09:00:00Z",
  "revocationId": "rev_01J8Q4X2N0",
  "sig": "ed25519:MEQCIF...=="
}

Read what that gives a compliance function that a KYA record alone does not. There is a specific human key, which is a stable pseudonymous identifier the platform can map to its own customer record. There is a bounded scope, so an agent that buys something outside category 5734 is outside its authority and the verifier can see that without asking anyone. There are time bounds, so authority expires by default rather than persisting until someone remembers to remove it. There is a revocation identifier, so the human can withdraw this authorisation without the agent being delisted for everybody else.

The verification walk

The check a merchant or a network runs is mechanical, offline, and fast. No callback to the operator, no callback to Manav.

def verify(request, delegation, published_keys):
    # 1. The agent really sent this request, unaltered.
    assert rfc9421_verify(request, key=delegation.delegateKey)

    # 2. The human really signed this delegation.
    assert ed25519_verify(delegation.sig,
                          canonical(delegation),
                          key=delegation.humanKey)

    # 3. The authorisation is live right now.
    assert delegation.notBefore <= now() <= delegation.notAfter
    assert delegation.revocationId not in revoked_set

    # 4. This specific action is inside what was permitted.
    assert request.action in delegation.scope.actions
    assert request.amount <= delegation.scope.maxAmountPerAction
    assert request.mcc in delegation.scope.merchantCategories

    return delegation.humanKey   # the accountable party

The function returns the thing the compliance file needs and currently does not have: a durable identifier for the accountable human, backed by a signature that human produced on hardware they hold.

Step three deserves a note. Checking revocation offline requires a status mechanism, and the honest options each trade something. Short lived delegations expire on their own and need reissuing. Aggregate status lists preserve privacy but lag. Live status checks are fresh and reintroduce the callback you were trying to avoid. We worked through that whole tradeoff in can you verify a credential without phoning the issuer, and the short version is that the answer to revocation is usually shorter lifetimes.

Does this survive the obvious objections?

"Operator liability is enough"

The argument runs: make the operator responsible for everything its agents do, and the operator will police its users. This is a genuine regulatory option and it might well be where some jurisdictions land.

It has a known failure mode, which is that it recreates the correspondent banking problem. When institution A relies on institution B's customer checks, A's diligence becomes a contractual assurance rather than a fact A can verify, and the quality of that assurance is invisible until something goes wrong at scale. The response in banking was not to abandon reliance, it was to require that the underlying identification exist and be producible on request. The same answer applies here, and a signed delegation is exactly the producible artifact.

"Requiring a human signature breaks autonomy"

It would, if the human had to sign every action. They do not. The human signs a delegation once, and it governs many actions for a bounded period inside a bounded scope. The signing moment is the same gesture as unlocking a phone, and it happens when the relationship is established, not when the agent buys toner.

The design question is which action classes deserve a fresh signature rather than falling under a standing delegation, and that is a risk decision each firm makes for itself. Irreversible, high value, and new counterparty are the usual triggers.

"This is just KYC of the end user, with extra steps"

It is deliberately not. The delegation carries a public key, a scope and a validity window. It does not carry a name, a document, a date of birth or an address. A merchant verifying it learns that a specific human authorised this purchase within these limits, and learns nothing about who that human is. If the merchant separately has a KYC obligation to that customer, it discharges it the way it always did.

This distinction matters enormously for adoption, because a design that turns every agent interaction into an identity disclosure will be rejected by users, by privacy regulators, and eventually by the platforms themselves. Human anchoring must be pseudonymous by construction.

Honest limits

This is where the argument earns its keep or does not.

• An agent acting for a compromised human passes every check here. If an attacker controls the human's device and can produce signatures, the delegation is valid, the chain verifies, and the fraud proceeds with impeccable paperwork. Human anchoring establishes accountability, not good behaviour.
• No identity control replaces transaction monitoring. Anchoring tells you who is accountable. It does not tell you that a pattern is suspicious. Firms that reduce monitoring because they added anchoring will have made themselves worse off.
• Enrollment is the trust bottleneck. Someone, once, must bind a key to the right human. Everything downstream inherits the quality of that moment, and that moment is under active attack, as we covered in the camera is no longer evidence.
• Coverage is a network problem. A field that only some verifiers check and only some humans have enrolled for is of limited use in year one. This gets better with adoption and is genuinely weak before it.
• Manav has shipped delegation chains and offline receipt verification. It has not shipped an AP2 adapter, card network integration, or composition into any specific KYA vendor's format. Everything in the wire examples above is implementable today against the signing API, and the standardised field is a proposal, not a deployed reality.
• A standard would commoditise the format, and that is fine. If a KYA specification adopts a human anchoring field, the format stops being anyone's advantage. What remains is the enrolled human network and the verifier adoption, which is the correct outcome for the ecosystem even though it is the less comfortable one for a vendor.

What to do this week

For a compliance, risk or platform team evaluating KYA right now:

1. Ask the customer question in your next vendor call. "When an agent you have verified makes a purchase, what artifact in the request proves which of my customers authorised it?" Write down the answer verbatim.
2. Find out who holds the key for any "user signed" object in the design. If the platform holds it, record it as a platform assertion in your risk documentation, not as customer authentication.
3. Write the four questions into your evaluation criteria: which agent, whose human, what scope, how fresh. Score each vendor on all four rather than on the first two.
4. Check whether your agent-level revocation can revoke one human's authority without delisting the agent for every other user. If it cannot, you have a blunt instrument and you will hesitate to use it.
5. Map your action classes by irreversibility and decide which ones should require a fresh human signature rather than falling under a standing delegation. Keep the list short enough that people will tolerate it.
6. Ask your KYA vendor whether they will carry a human anchoring reference as an opaque field, even before any standard exists. Carrying a field costs them almost nothing and gives you an upgrade path.
7. Document the gap now, in writing, so that when a regulator or an auditor asks how you identify the accountable person behind agent traffic, your answer is a considered position rather than an improvisation.

Frequently asked questions

Does Know Your Agent verify the human behind the agent? No. KYA verifies the operator that published the agent and the agent's own registered identity, usually with request signatures. The human on whose behalf the agent acts is typically an identifier the agent itself supplies, which is an assertion by an interested party rather than a proof. Establishing the human requires a delegation that person signed on a device they control.

What is the difference between KYA and KYC? KYC identifies the natural person who is the customer, because legal obligations attach to people. KYA identifies the software and the company that published it. They are complementary rather than equivalent, and treating KYA as KYC for agents mistakes an intermediary for a principal. In compliance terms an agent behaves much more like a payment instrument than like a customer.

Is Know Your Agent required under the EU AI Act? The AI Act does not use the term. It imposes human oversight duties for high risk systems under Article 14 and transparency duties under Article 50, and vendors reasonably cite these when selling agent governance tooling. Whether any specific KYA product satisfies a given obligation is a legal question for your counsel, and oversight duties are difficult to evidence if you cannot say which human was responsible.

Are platform held user keys good enough? They are better than nothing and they are not independent evidence. A signature produced by a key the platform controls is the platform asserting that a user approved something. It inherits every weakness of the platform, including a stolen session at the moment consent was captured. A key held in the user's own device produces a fact that does not depend on trusting the platform.

Does human anchoring mean identifying the end user to every merchant? No, and it should not. The delegation carries a public key, a scope and a validity window, with no name, document or address. A verifier learns that a specific human authorised this action within these limits and learns nothing about who they are. Any design that turns agent interactions into identity disclosures will fail on privacy grounds and deserves to.

Will a standard make this unnecessary? A standard would make it universal, which is the desirable outcome. Standardising a human anchoring field would commoditise the format while leaving the harder parts in place: enrolling humans, binding keys to the right people at enrollment, and getting verifiers to check. Those are network and operational problems that no specification removes.

How is this different from an agent reputation score? Reputation is a probabilistic judgment built from past behaviour, and it degrades exactly when it matters, against a well behaved agent operated by someone who just took over an account. A delegation is a deterministic check: either this human signed this authority covering this action, or they did not. Reputation is useful alongside it and cannot substitute for it.

Sources

1. Financial Action Task Force, recommendations and guidance on transparency and beneficial ownership of legal persons. fatf-gafi.org
2. FinCEN, customer due diligence requirements for financial institutions and beneficial ownership reporting. fincen.gov
3. RFC 9421, HTTP Message Signatures, IETF. rfc-editor.org
4. Cloudflare, Web Bot Auth and signed agent requests. blog.cloudflare.com
5. Regulation (EU) 2024/1689, the AI Act, Articles 14 and 50. eur-lex.europa.eu
6. Agent Payments Protocol specification and mandate model. ap2-protocol.org
7. Visa, Intelligent Commerce and agent payment programmes. usa.visa.com
8. Sumsub, agent verification product announcements, reported January 2026. sumsub.com
9. Ethereum Improvement Proposals index, for draft agent identity and registry proposals including ERC-8004. eips.ethereum.org
10. W3C Verifiable Credentials Data Model 2.0. w3.org

If you want to see the delegation and receipt mechanics rather than read about them, the agent delegation demo runs the whole flow in a browser, and the developer documentation covers the signing and verification calls.

You have not identified your customer until you have identified a natural person. Everything between you and that person is an intermediary, and an AI agent is the most capable intermediary ever built.