Know Your Agent (KYA) Guide: Verifying AI Agents

AI agents now arrive at websites, APIs and payment systems claiming to act for a person or a company, and most services have no reliable way to check who built the agent, who runs it, who it represents or what it has been allowed to do. "Know Your Agent" (KYA) is the name the market has started to use for answering those questions before granting access or money. This guide treats KYA as an emerging, non-standard term: no standards body defines it, and vendors use it for different things. It sets out a vendor-neutral KYA model built from standards that do exist, such as HTTP Message Signatures, signed A2A Agent Cards, verifiable mandates and workload identity, and explains how to verify, tier, monitor and revoke agents. It is written for fraud, IAM, API security and platform teams on the receiving side of agent traffic, and for teams that operate agents and must make them verifiable.

Key takeaways

KYA is a practice, not a standard. The term is vendor-driven and has no agreed definition; build it from standard building blocks and avoid locking into one proprietary agent identity.
Verify four things, separately. Who operates the agent, which agent instance is calling, which human or organisation it acts for, and what that principal has authorised. Passing one check says nothing about the others.
Identity is not intent. A cryptographically verified agent can still be prompt-injected; KYA decides how far to trust an agent, and authorisation and monitoring still bound what it can do.
Tie every agent to an accountable party. The most useful KYA output is a verified link from the agent key to an operator you can contact, suspend and, where relevant, hold liable.
Make it continuous. Keys rotate, operators change and agents get compromised; KYA needs revocation, re-verification and behavioural monitoring, not a one-off onboarding check.

What KYA means and where it comes from

KYA borrows its framing from Know Your Customer (KYC) and Know Your Business (KYB): before you transact, establish who you are dealing with and how much risk they carry. Searches for the term return vendor material almost exclusively, and the definitions differ: some focus on agent credentials or tokens, some on verifying the developer, some on wallets and spending authority. Treat any claim that a product "is KYA" as a description of that product, not of a standard.

The standards community frames the same problem as agent identity and authorisation. The NIST National Cybersecurity Center of Excellence (NCCoE) published a concept paper in February 2026, open for comment until 2 April 2026, on applying existing identity standards to software and AI agents. Its focus areas are identification (distinguishing agents from humans), authorisation, access delegation that links user identities to agents, logging and transparency that tie actions to non-human identities, and tracking data flows. It names MCP, OAuth 2.0 and 2.1, OpenID Connect, SPIFFE/SPIRE, SCIM, NGAC, NIST SP 800-207, SP 800-63-4 and NISTIR 8587 as relevant standards. The OpenID Foundation's October 2025 whitepaper on identity management for agentic AI recommends treating agents as first-class identities with lifecycle, governance and accountability, and flags recursive delegation and cross-domain trust as unsolved gaps.

KYA differs from KYC in one important way: the agent itself is not the accountable party. A human or organisation always sits behind it, so KYA is mostly about verifying that chain. See the Identity Proofing and KYC Guide and the KYB Guide for the human and business layers.

The four KYA questions

Question	What you verify	Building blocks	Typical evidence
1. Who operates the agent?	The agent provider or deploying organisation	KYB of the operator; domain control; contractual onboarding	Verified legal entity, domain hosting the key directory, contact and abuse channel
2. Which agent is this?	That the request comes from a key controlled by that operator	RFC 9421 HTTP Message Signatures; Web Bot Auth key directory; signed A2A Agent Card; workload identity (SPIFFE, OAuth client credentials)	Valid signature, key ID matching a published key, unexpired signature
3. Who does it act for?	The human or organisation behind this session	OAuth delegation and token exchange; verifiable credentials; network programmes that bind agents to a cardholder	Access token with subject and actor; consented user identifiers
4. What is it allowed to do?	The scope, limits and expiry of the authority	OAuth scopes; signed mandates such as AP2; spending allowances	Constraints the verifier can evaluate in code

Questions 1 and 2 are the "know the agent" part; questions 3 and 4 are delegation and authorisation. Many failures come from answering question 2 and assuming the rest. See the OAuth Token Exchange and Delegation Guide and the AI Agent Authorisation Guide.

Verification methods compared

Method	How it works	Strength	Limits
User-Agent string or IP ranges	Agent declares a name; operator publishes IP lists	Trivial to adopt	Spoofable; shared cloud IPs; no link to a user
API key or OAuth client credentials	Pre-registered client authenticates to your API	Strong for known bilateral integrations	Does not scale to unknown agents; shared secrets leak
HTTP Message Signatures (Web Bot Auth)	Agent signs each request; verifier fetches public keys from `/.well-known/http-message-signatures-directory`	Per-request proof, open verification, no shared secret	Internet-Draft; proves operator key, not user or intent
Signed A2A Agent Card	Agent publishes `/.well-known/agent-card.json` signed with JWS over an RFC 8785 canonical form	Tamper-evident description of skills and endpoints	Signing is optional (MAY); trust depends on the key source
Network or platform registration	Agent registered and verified with a card network or platform before acting	Operator vetted; tokens tied to the agent	Ecosystem-specific; coverage varies by market
Delegation credentials and mandates	User-signed authority (OAuth token with actor, AP2 mandate, verifiable credential)	Answers who and what, not just which agent	Needs verifier support for the format

How the building blocks work

Signed agent requests

RFC 9421: defines the Signature-Input and Signature fields, derived components such as @authority, @path, @method and @target-uri, and parameters created, expires, nonce, alg, keyid and tag.
Web Bot Auth: the IETF working group draft draft-ietf-webbotauth-httpsig-protocol-00 (September 2026) profiles RFC 9421 for automated traffic. It adds a Signature-Agent header pointing to the operator's key directory, requires created and expires (recommending expiry within 24 hours), requires tag="web-bot-auth", requires keyid to be a JWK SHA-256 thumbprint and forbids shared HMAC secrets. The directory is a JWK Set served over HTTPS, and keys are rotated by publishing the new key beside the old one.
Visa Trusted Agent Protocol: uses RFC 9421 signatures bound to the merchant domain and page, with tags that separate browsing from payment.

Agent descriptions and workload identity

A2A Agent Cards: the A2A specification (latest released version 1.0.0) says clients SHOULD verify at least one signature before trusting a card, SHOULD fetch keys over HTTPS, MAY keep a trusted key store for known providers, and MUST NOT use expired or revoked keys. See the Agent-to-Agent Authentication Guide.
Workload identity: inside an organisation, give each agent runtime its own workload identity (for example a SPIFFE ID or a dedicated cloud service identity) rather than a shared API key, so every call is attributable to one agent. See the SPIFFE and SPIRE Guide.

Delegated authority

Mandates: AP2 binds an agent's public key into a user-signed mandate (cnf claim) with constraints and expiry, so a verifier can check both the agent key and what the user approved. The Agent Payments Protocols Guide covers this in detail.
Verifiable credentials: an operator or user credential presented with selective disclosure can prove attributes without exposing everything. See the Verifiable Credentials Guide.

Risk-tiering agents

Not every agent needs the same scrutiny. Tie the depth of KYA to what the agent can do on your service.

Tier	Example actions	Minimum KYA	Default treatment of unverified agents
Read public content	Browse catalogue, read documentation	Signed requests or declared identity; rate limits	Allow with rate limits and bot controls
Act in an account	Log in, change settings, read personal data	Verified operator plus delegated user authorisation (OAuth with user consent)	Block; require the user to authorise the agent
Create accounts or content	Sign-up, publishing, posting reviews	Verified operator, per-operator quotas, verified contact details	Challenge or block; never issue credentials before verification completes
Move money	Purchase, transfer, subscription	Registered agent, user-signed mandate or network agent token, step-up outside limits	Block or fall back to a human checkout

Small organisations can usually rely on their CDN, bot management or payment provider to verify signatures and maintain agent allow lists, and spend their effort on tiering and limits. Large platforms should run their own verification, keep an operator registry with contact and suspension procedures, and publish what they require from agents. See the Bot vs AI Agent Traffic Management Guide.

Where KYA meets existing fraud controls

Customer KYC still applies: when an agent opens an account or applies for credit for a person, the person must still pass your normal identity proofing. KYA confirms the agent and its operator; it never substitutes for proofing the human.
Device and behaviour signals change meaning: agents run in cloud infrastructure and headless browsers, so signals tuned to flag automation will fire on legitimate agents. Feed signature results into fraud models as a feature, so a verified agent is scored differently from an anonymous bot rather than exempted.
Step-up must reach the human: a one-time passcode sent to the agent is not step-up. Challenges for high-risk actions should go to the user on their own authenticator, such as a passkey. See the Passwordless and Passkeys Guide.

Implementing a KYA programme

Measure agent traffic first. Classify current automated traffic by declared agent, signature presence and signature validity. You cannot set policy for traffic you cannot see.
Define tiers and evidence. Agree, per action tier, which of the four questions must be answered and with what evidence, and document how unverified agents are treated.
Verify in log-only mode. Validate RFC 9421 signatures, Agent Card signatures and delegation tokens on live traffic without blocking. Record failure reasons (unknown key, expired signature, wrong tag, missing user delegation).
Onboard operators. For agents that need more than public read access, run KYB on the operator, record its key directory URL, an abuse contact and the user consent model it uses.
Enforce tier by tier. Start with money movement and account creation, where the harm is clearest, then account actions. Keep public read access open with rate limits.
Bind sessions to the verified identity. Issue your own short-lived tokens to verified agents, scoped to the tier and bound to the agent key where possible, so a stolen token is less useful.
Prepare revocation and rollback. Be able to remove an operator or key from your allow list in minutes, revoke issued tokens, and switch a tier back to log-only if verification breaks legitimate traffic.
Re-verify on change. Re-check when an operator's key directory changes, when ownership changes, and on a fixed schedule.

If you operate agents: making them verifiable

Sign outbound requests: publish a key directory on a domain you control and sign every request; never share one key across unrelated agents.
Publish and sign Agent Cards: include provider details and endpoints, and rotate keys with overlapping signatures.
Keep keys out of the model's reach: sign in a separate component or key service the LLM cannot call freely.
Carry the user's authority explicitly: use delegated tokens or mandates that name the user and limits, not the agent's own broad credentials.
Be reachable: provide an abuse contact and respond to suspension requests. Register agents in your own inventory; see the Identity Governance for AI Agents Guide.

Detection and measurement

Log, for every agent request: declared agent, Signature-Agent URI, key ID, signature result, operator record, delegated user (if any), tier and decision. Watch for unsigned traffic claiming a known agent name, valid keys appearing from unusual infrastructure, bursts of account creation per operator, and a verified agent whose behaviour changes sharply.

Share of agent traffic with a valid signature, by tier.
Verification failure rate by reason, trended weekly.
Operators onboarded with completed KYB as a share of operators with above-read access.
Time to suspend an operator or key after an abuse report.
Abuse incidents per verified operator versus unverified traffic.

Framework mapping

Framework	Reference	KYA relevance
NIST CSF 2.0	PR.AA-01; PR.AA-02; PR.AA-03; PR.AA-05	Manage agent identities; proof and bind them to credentials; authenticate; enforce least privilege
NIST SP 800-53 Rev. 5	IA-9 Service Identification and Authentication; SA-9 External System Services; AU-10 Non-repudiation; SI-4 System Monitoring	Authenticate external agents; manage agent operators as external services; attributable actions; monitor behaviour
ISO/IEC 27001:2022 Annex A	5.16 Identity management; 5.19 Information security in supplier relationships; 8.16 Monitoring activities	Agent identity lifecycle; operator onboarding; ongoing monitoring
MITRE ATT&CK v20	T1078 Valid Accounts; T1136 Create Account; T1550 Use Alternate Authentication Material	Agents using stolen or unverified accounts; mass account creation; replayed tokens or signatures
OWASP Top 10 for LLM Applications 2025	LLM01:2025 Prompt Injection; LLM06:2025 Excessive Agency	A verified agent can still be steered; limit what any agent may do

Common failure patterns

Trusting the declared name: allowing traffic because the User-Agent says it is a well-known assistant. Names and IP ranges are easy to spoof; require signatures for anything above public read access.
Issuing credentials before verification completes: in the GemStuffer RubyGems campaign, an agent swarm mass-created accounts with disposable email addresses and a bug issued working API keys to accounts that had never verified their email. Attribution to an operator came later from independent researchers, not from the platform's own controls.
Stopping at "which agent": verifying the operator key but not checking which user the agent acts for or what that user authorised.
Treating verified as safe: giving a verified agent broad permissions. Verification sets a trust level; least privilege, limits and monitoring still apply.
One-time onboarding: no re-verification when keys rotate or an operator changes hands, and no fast way to suspend an operator.
Proprietary lock-in: accepting only one vendor's agent token, so legitimate agents from other ecosystems are blocked or pushed to unsigned, less visible routes.

Practitioner checklist

Inventory automated traffic and classify it by declared agent and signature status.
Define action tiers and the KYA evidence each requires, covering all four questions.
Verify RFC 9421 and Web Bot Auth signatures, checking tag, expires and key directory origin.
Verify A2A Agent Card signatures and reject expired or revoked keys.
Run KYB on operators of agents that act in accounts, create content or move money.
Require delegated user authorisation, not the agent's own credentials, for account actions.
Issue short-lived, tier-scoped tokens to verified agents and bind them to the agent key where possible.
Keep an operator registry with abuse contacts and a tested suspension procedure.
Re-verify on key rotation, ownership change and on a schedule.
Report signature coverage, failure reasons and time to suspend each month.

Know Your Agent (KYA) Guide: Verifying AI Agents Before You Trust Them