Know Your Agent (KYA) is the practice of establishing enough verifiable information about an AI agent to decide whether to rely on what it is doing: which agent it is, who it acts for, what it has been authorised to do, whether the current action falls within that authority, whether that authority is still valid, and who is accountable. The common shorthand for KYA is "which agent is this?". That is the first of six questions, and on its own it is rarely the one that decides whether an action should be accepted.
The term borrows deliberately from Know Your Customer (KYC) and Know Your Business (KYB), and the analogy is helpful up to a point. But agents are not customers and they are not businesses. They are delegates. That difference changes what KYA needs to prove.
KYC vs KYB vs KYA
KYC and KYB are mature practices, particularly in regulated financial services. KYC establishes the identity of an individual customer and assesses risk. KYB does the same for a business, including understanding who owns and controls it. Both are largely about the counterparty at onboarding, refreshed periodically.
KYA has a different shape. The entity in front of you is software. It may be well built and well intentioned, but it has no standing of its own. Its legitimacy is borrowed from a principal, through a mandate, for a purpose.
| KYC | KYB | KYA | |
|---|---|---|---|
| Subject | An individual | A legal entity | An AI agent acting for a principal |
| Core question | Who is this person? | What is this business and who controls it? | Who is this agent acting for, with what authority, on this action? |
| Source of legitimacy | The person themselves | The registered entity and its owners | Delegation from a human or organisation |
| When it matters most | Onboarding, then periodic review | Onboarding, then periodic review | At the moment of each consequential action |
| What changes over time | Relatively slowly | Relatively slowly | Mandates can be issued, narrowed, expire or be revoked at any time |
| Typical failure mode | Impersonation, synthetic identity | Shell entities, hidden control | Agent acting outside scope, stale or revoked authority, invisible principal |
| What a "pass" means | This is the person | This is the business | This action is inside a valid mandate from a verified principal |
The final row is the important one. A KYC pass is a statement about a person. A useful KYA pass is a statement about an action.
Why "which agent is this?" is not enough
Agent identity is genuinely valuable. Knowing that a request comes from a specific agent, operated by a known provider, with keys that can be checked, gives a service something solid to reason about. The web is moving in this direction, and work on signed requests from automated clients is a positive step.
But consider two scenarios:
- A well-known, verified shopping agent attempts to purchase a 3,000 dollar laptop. Its user authorised it to buy groceries under 200 dollars.
- A smaller, lesser-known agent attempts to book a 180 dollar train ticket. Its user explicitly authorised train bookings under 250 dollars this month, and that mandate is verifiable.
If KYA stops at agent identity, the first passes more easily than the second. That is the wrong outcome. The question that actually matters to the merchant is whether this action is authorised by someone who stands behind it.
This is the distinction Proof of Actor draws between agent identity and agent authority. Identity answers "which agent is this?". Authority answers "who authorised it, what authority does it have, and is this action inside that authority?". The second is what Proof of Authority is designed to establish.
The six things KYA needs to prove
We think a complete KYA check needs to establish six claims. Each one addresses a different way agent trust can fail.
1. Agent identity
Which agent is this, and who operates it? This is the foundation: a stable, verifiable identifier for the agent and a link to the provider or operator responsible for running it. Without it, nothing else can be bound to anything. But it should be treated as the start of the check, not the conclusion.
2. The principal
Who does this agent act for? The principal is the human or organisation the agent ultimately represents. It might be an individual, a company, or another service that itself holds delegated authority. The receiving service needs evidence that a real, identifiable principal exists and is bound to this agent.
This is where privacy design matters most. A merchant often needs to know "a verified person stands behind this agent", not that person's name and address. KYA should support claims such as "verified principal, identity undisclosed", in line with our privacy principle: prove what matters without revealing what doesn't.
3. The mandate and its scope
What has the principal authorised this agent to do? A mandate should be explicit about permitted action types, value limits, counterparties, time windows, and, just as importantly, what is excluded. "May book travel, maximum 800 dollars per booking, economy only, no non-refundable fares, expires 30 November" is a mandate. "Has access to my card" is not.
4. The current action against that scope
Is this specific request inside the mandate? This is the step most KYA discussions skip, and arguably the most important. Scope checking has to happen against the actual action at the time it is requested, because that is where an over-eager, confused or compromised agent will diverge from what its principal intended.
5. Revocation and validity
Is the authority still in force? Mandates expire. Principals change their minds. Organisations offboard agents. A useful KYA check must reflect current status, not the status at onboarding. Revocability is a design requirement, not an optional feature: agent authority must be withdrawable, and withdrawal must take effect for future actions.
6. Accountability
Who ultimately stands behind this action, and is there a record? If the action is later disputed, the service needs to show which agent acted, for whom, under which mandate, whether the action was in scope and whether any required human approval was obtained. This is what makes it reasonable to accept agent actions at all.
What a KYA result might look like
Bringing the six claims together, a KYA outcome is less a badge and more a receipt. The following is a conceptual illustration of an Actor Trust Receipt for an agent interaction, not a live format:
ACTOR TRUST RECEIPT (conceptual illustration)
Actor AI Agent
Agent identity Verified
Principal Verified organisation (identity disclosed to service)
Mandate Purchase SaaS subscriptions, up to 5,000 USD
Requested action Purchase, 1,200 USD, approved vendor
Action vs scope Inside delegated scope
Human approval Not required by mandate
Mandate status Valid, expires 31 December 2026
Attestation ID act_7c2e...
A service checking this programmatically might use an interface along the lines of the following Proposed API. It is illustrative only and the design is evolving:
// Proposed API - illustrative only, not available today
const authority = await ProofOfActor.verifyAuthority({
agent,
action: { type: "purchase", amount: 1200, currency: "USD" }
});
// The relying service applies its own policy, for example:
// accept if principal is verified, mandate is valid
// and the action is inside scope.
The output is designed to become an Actor Attestation: a machine-readable record the service can store for audit and dispute.
KYA is continuous, not a one-time onboarding step
KYC is mostly front-loaded. You verify a customer once, then monitor. KYA cannot work that way, for three reasons:
- Authority is dynamic. A mandate issued this morning may be narrowed this afternoon.
- Agents act at high frequency. A single agent may perform many actions in a session, each with different risk.
- The risk is in the action, not the actor. The same agent can be trustworthy for one request and out of scope for the next.
This is why we describe KYA as a check at the point of action, not only at registration. Registration establishes identity and binding. Each consequential action then needs its own answer to "is this inside a valid mandate?"
When KYA needs a human
Some actions are consequential enough that authority alone is not sufficient. A bank may accept an agent paying a routine utility bill under an existing mandate, but require the principal to explicitly confirm a new payee or a large transfer.
In those cases, KYA hands off to human intent: evidence that the principal approved this action, at this time, under these conditions. That is where agent trust meets Proof of Control, and where the question shifts from "is the agent authorised?" to "is the human actually present and in control of this approval?". We explore the human side in What Is Human Control Verification?.
Where KYA fits in the broader trust stack
KYA is not a standalone category so much as one part of a larger question: who or what is actually acting? In the Proof of Actor model, any interaction can be understood as Human, Human + AI, Authorised Agent or Unverified Actor. KYA is the evidence that moves an agent from "Unverified Actor" (trust relationship unknown) to "Authorised Agent" (acting within authority delegated by an identified principal).
That framing keeps KYA from becoming a gate that only admits large, well-known agent platforms. A small agent with a clear, verifiable mandate should be able to earn trust on the merits of its authority. For more on delegation and accountability, see The Missing Trust Layer for AI Agents, and for a sector view, agentic commerce and financial services.
Frequently asked questions
What does KYA stand for?
KYA stands for Know Your Agent. It refers to establishing verifiable information about an AI agent, including who it acts for and what it is authorised to do, before relying on its actions.
What is the difference between KYC and KYA?
KYC verifies the identity of a person. KYA verifies a relationship: an AI agent, the principal behind it, and the authority between them. KYC is mostly performed at onboarding, while KYA also needs to be checked at the point of each consequential action because mandates can change or be revoked.
Is agent identity the same as Know Your Agent?
No. Agent identity answers which agent is acting. A complete Know Your Agent check also establishes the principal, the mandate and its scope, whether the current action is inside that scope, whether the authority is still valid, and who is accountable.
Does KYA require revealing the principal's identity?
Not always. Many services only need evidence that a verified principal stands behind the agent and that the action is authorised. Privacy-aware KYA should allow the principal's identity to stay undisclosed where it is not needed.
Help define what KYA should prove
Know Your Agent will become a routine part of how services decide whether to accept actions from AI agents. Getting its definition right now, so that it covers authority, scope, revocation and accountability rather than identity alone, will shape how open and trustworthy the agent ecosystem becomes. Proof of Actor is building this as part of a broader trust infrastructure, described on how it works. We are in development and working with early design partners, and we would welcome agent builders and the services they interact with to join the Developer Preview or become a design partner.
