principal, permissions and trust history of an autonomous AI agent before it acts.”>Know Your Agent is only useful if it is operational. This checklist walks through verifying an agent before you let it act — and what to log and how to revoke it. It assumes you already accept the premise behind What is KYA?: that an autonomous actor needs a provable identity, a named principal, scoped authority and a working off switch.
The steps below are ordered, but they are not a one-time gate. Agents are typically verified per interaction, not per deployment: identity, delegation and credential are re-checked at the point of action, and revocation can take effect between calls.
For each step, “what good looks like” describes a verifiable control; “failure modes” lists the ways the step is commonly weakened. If a step has no evidence you can point to, treat it as unverified rather than passed.
1. Identify the principal
Establish who is accountable: the human or organisation on whose behalf the agent acts. Without a named principal there is no one to hold responsible. In OAuth terms the agent acts “on behalf of the resource owner”, and RFC 8693 token exchange exists specifically to carry delegation versus impersonation semantics, so a downstream service can see both who is acting and on whose behalf.
What good looks like: every agent identity resolves to a named principal (a person or legal entity), and the delegation is recorded. For regulated activity the principal itself is subject to KYC/KYB — an agent does not remove that requirement.
Failure modes: an agent that acts with no accountable principal; a principal recorded as a shared team account; delegation that exists only in a wiki, not in a token or registry entry.
2. Verify the agent’s identity
Require an attested identity, not a self-declared name: a workload identity (e.g. SPIFFE/SPIRE), a verifiable credential, or a signed agent passport issued by a trusted authority. Self-declared strings provide no cryptographic proof of who is acting; an attested identity such as a SPIFFE Verifiable Identity Document (SVID) is designed to be “proven as authentic” and “proven to belong to the presenter”. See agent identity in the glossary.
What good looks like: the identity is cryptographically verifiable against a published trust anchor, is unique to the agent, and is issued by a party you trust. Credentials are short-lived and rotated rather than static.
Failure modes: trusting a self-asserted name or User-Agent string; a shared service account standing in for many agents; long-lived keys or API tokens that never rotate, which OWASP’s Non-Human Identities Top 10 treats as a distinct risk (Secret Leakage, Long-Lived Secrets).
3. Check the scope of delegation
Confirm what the agent is authorised to do: which actions, which services, which limits (amount, data scope, time). Prefer scoped credentials over broad, long-lived tokens. Fine-grained authorization can be carried explicitly in an OAuth request using rich authorization details. See delegation in the glossary.
What good looks like: the delegation names the actions, resources and limits, and the token’s scopes match least privilege. Zero trust removes implicit trust based on network location, so scope — not the network the agent sits on — decides access.
Failure modes: a broad token that can call any endpoint the principal can; scopes that are granted but never enforced at the resource; an agent whose authority silently accumulates over time and is never re-scoped.
4. Verify the credential at the point of action
Validate signature, issuer, audience, expiry, and proof-of-possession (e.g. DPoP). Reject replayed or tampered credentials. DPoP is a mechanism for sender-constraining OAuth 2.0 tokens at the application level and is explicitly intended to allow detection of replay of access and refresh tokens; mutual-TLS can bind tokens to a client certificate instead.
What good looks like: the resource server validates the token on every request (signature, issuer, audience, expiry) and, for sender-constrained tokens, checks that the presented proof matches the key or certificate the token is bound to.
Failure modes: validating the token once at onboarding and never again; accepting a bearer token whose network transit can be replayed; skipping the audience check so a token minted for one service is accepted by another.
5. Confirm the action is authorised
Check the request against the delegation: is this action, amount and target within scope for this principal? This is the step that distinguishes “the agent has a valid credential” from “this specific action is allowed”.
What good looks like: an explicit policy decision per request, with deny as the default, and high-risk actions gated on human approval. The decision is logged with its reason.
Failure modes: authorisation inferred from the agent’s reputation or prior history; a valid token used to justify an out-of-scope action; no policy for the “agent asks for more scope mid-task” case.
6. Log to an audit trail
Record what the agent did, on whose authority, when, and with which credential. Use an append-only, tamper-evident log. The record should let you reconstruct both the actor (agent) and the subject (principal) for every action — the same delegation distinction the token carries.
What good looks like: append-only, hash-chained entries that capture actor, principal, action, target, decision, timestamp and credential reference; logs that correlate with the agent registry so an identity can be traced to a lifecycle record.
Failure modes: logging only the agent but not the principal; mutable logs; credentials or secrets captured in cleartext in log payloads; no way to answer “what did this agent do last Tuesday?”.
7. Make revocation work
Ensure you can withdraw an agent’s authority immediately, and that services re-check it (introspection or short-lived credentials). OAuth defines a token revocation endpoint that invalidates a token and, where applicable, other tokens derived from the same grant; token introspection lets a resource server query whether a token is still active. Short-lived credentials reduce reliance on revocation lists because they expire on their own. See revocation in the glossary.
What good looks like: a tested, end-to-end kill switch — revoke the identity or credential, and confirm the very next action is refused. Short lifetimes bound the worst case if revocation propagation is slow.
Failure modes: revocation that only removes the agent from a list but leaves issued tokens valid; revocation never tested until an incident; credentials with lifetimes measured in months.
Decision tables
Use these two tables to decide what evidence to require. The first is about identity proof; the second is about credential scope. Both are decision aids, not compliance rules.
Identity: self-declared vs attested
| Approach | What it proves | Strength | Use when |
|---|---|---|---|
| Self-declared name or ID | Only that a caller claims a string; no cryptographic proof | Weak — spoofable | Never as the sole basis for trust |
| Issuer-signed token (OIDC/JWT) | Claims were signed by an issuer you validate | Moderate — depends on signature, issuer, audience and expiry checks | Agents acting within an established OAuth/OIDC estate |
| Workload identity (SPIFFE SVID) | Identity is cryptographically verifiable and bound to the presenter, with short-lived, rotated keys | Strong | Service-to-service and agent identity inside a trust domain |
| Verifiable credential / agent passport | Claims made by an issuer, held by the agent and verifiable by a relying party | Strong, portable | Cross-organisation agent identity and authorisation |
Credential: broad token vs scoped credential
| Credential style | What it allows | Risk | Prefer when |
|---|---|---|---|
| Broad, long-lived token | Everything the principal can do, for a long time | High — over-privileged and leak-prone | Only as a legacy fallback, with compensating controls |
| Bearer token, unbound | Anyone holding the token can use it | Replay if intercepted | Short-lived, low-value, low-scope calls |
| Scoped, short-lived token | Named actions and limits, expiring quickly | Bounded by scope and lifetime | The default for agent actions |
| Scoped token plus proof-of-possession | As above, but bound to the agent’s key or certificate | Lowest — a stolen token alone is not enough | High-value or cross-boundary actions |
Checklist
- Named, verifiable principal
- Attested agent identity (not self-declared)
- Explicit, scoped delegation
- Credential validated per action (signature, audience, proof, replay)
- Action checked against scope
- Append-only audit trail
- Revocation tested end to end
FAQ
Is verifying an agent the same as KYC?
No. KYC verifies the customer — a natural person or, via KYB, a legal entity and its beneficial owners — using risk-based procedures. KYA verifies the agent: its identity, principal, permissions and revocability. The two are complements, not substitutes: where an agent acts for a regulated principal, that principal still needs KYC/KYB. “KYA” as an umbrella term is this site’s framing; the underlying activity is being standardised by bodies such as NIST’s NCCoE.
Do I have to re-verify on every single action?
Not necessarily in full, but you should re-check the parts that can change between calls: token expiry, scope, audience and revocation state. DPoP and mutual-TLS binding let you confirm the caller still holds the key the token is bound to, and introspection lets you confirm the token is still active before a high-value action.
What is the minimum bar if an agent only self-declares its identity?
Treat self-declaration as untrusted input. At minimum, require an identity that is cryptographically verifiable and tied to a principal, keep credentials short-lived, and scope them to the narrowest set of actions the task needs. If you cannot attest the identity, you cannot reliably hold anyone accountable for the agent’s actions.
How do I revoke an agent?
Revoke at the identity/credential level (disable the agent identity and invalidate its tokens via the authorization server’s revocation endpoint) and rely on short credential lifetimes to bound propagation delay. Then test it: a revocation that has never been exercised end to end is an assumption, not a control. For the mechanical steps, see the code examples.
Sources
- NIST NCCoE, “NCCoE Agentic AI Identity and Authorization Project Resource Hub” — https://pages.nist.gov/nccoe-ai-identity/ (accessed 2026-10-03)
- NIST, “SP 800-207: Zero Trust Architecture” — https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf (accessed 2026-10-03)
- IETF, “RFC 8693: OAuth 2.0 Token Exchange” — https://www.rfc-editor.org/rfc/rfc8693.html (accessed 2026-10-03)
- IETF, “RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP)” — https://www.rfc-editor.org/rfc/rfc9449.html (accessed 2026-10-03)
- IETF, “RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens” — https://www.rfc-editor.org/rfc/rfc8705.html (accessed 2026-10-03)
- IETF, “RFC 7662: OAuth 2.0 Token Introspection” — https://www.rfc-editor.org/rfc/rfc7662.html (accessed 2026-10-03)
- IETF, “RFC 7009: OAuth 2.0 Token Revocation” — https://www.rfc-editor.org/rfc/rfc7009.html (accessed 2026-10-03)
- IETF, “RFC 9396: OAuth 2.0 Rich Authorization Requests” — https://www.rfc-editor.org/rfc/rfc9396.html (accessed 2026-10-03)
- SPIFFE project, “SPIFFE Concepts” — https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/ (accessed 2026-10-03)
- W3C, “Verifiable Credentials Data Model v2.0” — https://www.w3.org/TR/vc-data-model-2.0/ (accessed 2026-10-03)
- OWASP, “Non-Human Identities Top 10” — https://owasp.org/projects/non-human-identities-top-10 (accessed 2026-10-03)
- OpenID Foundation, “Identity Management for Agentic AI” — https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf (accessed 2026-10-03)
Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.