Why agent identity is a new problem

We already identify software: service accounts, API keys, mTLS certificates, SPIFFE workload identities. So why is agent identity a genuinely new problem?

Because an autonomous agent combines three properties that existing machine-identity tooling was not built to express together: it acts on behalf of a principal, it decides what to do across many steps, and it needs per-action, revocable authority. A service account is a fixed caller with fixed rights. An agent is a delegate with judgement.

What we had before

Each prior actor type solved part of the problem — and left a gap.

  • Service accounts and API keys authenticate a caller. They prove a secret was presented, but they do not say who the caller represents, what it is allowed to do beyond a static scope, or how to revoke access quickly and precisely.
  • Workload identity (e.g. SPIFFE/SPIRE) gives services cryptographic identities derived from where and what they are, not a shared secret. Excellent for service-to-service calls — but a SPIFFE ID identifies a workload, not a principal or a mandate.
  • mTLS and certificates prove possession of a private key and support revocation, but they are notoriously hard to scope to fine-grained, short-lived permissions.
  • OAuth 2.0 introduced delegated authorization: an access token with scopes, issued to a client acting for a user. This is the closest ancestor of KYA — and the reason agent identity work is landing in the IETF’s OAuth community.

None of these was designed for software that chooses its next action.

What is actually different about agents

1. They act on behalf of someone

A service account usually acts for itself or its owner-operator. An agent acts for a principal — a person or organisation that is legally accountable. Identity therefore needs a link from agent to principal, not just an agent credential. This is why OAuth “on-behalf-of” work for AI agents explicitly threads the agent’s identity through consent and into the token.

2. Authority is dynamic and per-action

You cannot express “this agent may pay up to €200 for a train ticket today” as a static account. The authority must be scoped, time-bound, and evaluated per request — the direction of fine-grained authorization mechanisms like OAuth Rich Authorization Requests (RFC 9396) and scope-minimising profiles such as the MCP authorization spec, which recommends least privilege and step-up authorization.

3. They are probabilistic

Traditional authorization is deterministic: a rule either matches or it does not. An agent’s behaviour is generated, so it can be manipulated. NIST’s adversarial-ML taxonomy and the OWASP Top 10 for LLM applications both treat prompt injection as a top risk. Identity does not fix that, but identity is what prevents a manipulated or spoofed agent from being trusted anyway.

4. They need verifiable claims, not just keys

Proving an agent is who it says — that it runs approved code, under a named principal, with a defined mandate — calls for tamper-evident claims. W3C Verifiable Credentials provide the issuer/holder/verifier model for exactly that; emerging payment protocols such as AP2 use signed, credential-based mandates so a merchant can verify user intent cryptographically rather than trusting an inference.

5. They need to be identifiable to strangers

An agent increasingly interacts with services that have no prior relationship with it — browsing, purchasing, booking. Cloudflare’s Web Bot Auth uses HTTP message signatures so a previously unknown agent can cryptographically prove it is a legitimate, registered bot. This is a different shape from enterprise IAM, where both sides are usually known to each other.

6. They need fast, precise revocation

Compromise or misalignment must be stoppable in seconds, scoped to one agent or one mandate, without disabling a whole integration. That requires revocation paths (token revocation, credential status lists) designed in from the start.

Why “just treat it as a service account” fails

A service account model answers one question — does the caller hold valid credentials? — and implicitly assumes the caller is benign, deterministic, and tightly scoped by construction.

For an agent, that model leaves the hard questions unanswered:

  • Who is accountable if the agent acts wrongly?
  • Was this action within the mandate?
  • How do you prove the agent is the approved one and not a spoof?
  • How do you revoke precisely without collateral damage?
  • How do you keep a defensible record?

Those are KYA questions. They are not new in kind — KYC asked “who is this and should we trust them” of customers; zero trust asked it per request for resources. They are new in combination: a non-human actor, a legal principal, per-action authority, and machine-verifiable evidence.

What good looks like (in progress)

As of October 2026, no single standard solves agent identity end to end. But a workable pattern is assembling from existing pieces:

  1. A cryptographic agent identity (workload identity, certificates, or signed requests).
  2. A verifiable link to a principal (the KYC/KYB subject).
  3. A scoped, time-bound, revocable credential expressing the mandate.
  4. Per-request policy evaluation (zero trust) that checks identity and authority.
  5. Tamper-evident logs of actions and the authority behind them.
  6. A working revocation path.

Everything except the agent-specific conventions is mature technology. The new work — in the IETF, W3C, payments, and vendor ecosystems — is joining them into a coherent chain.

FAQ

Can’t I just give each agent its own service account? You can, and you should scope it tightly. But an account does not express a principal, a per-action mandate, or a revocable delegation. Use it as one layer, not the whole answer.

Is agent identity just OAuth again? OAuth is the closest fit and where much of the standards work lives. But OAuth’s classic model assumes a client and a user; agent-specific needs (identifying the agent itself, verifiable mandates, cross-domain strangers) are still being specified.

Isn’t this solved by zero trust? Zero trust gives you the decision framework — evaluate every request. KYA supplies the identity-and-authority inputs for that decision when the requester is an agent.

Do I need verifiable credentials? Not necessarily, but you need tamper-evident, verifiable evidence of identity and authority. VCs and signed mandates are the leading way to get it.

Keep reading

Sources

  1. NIST, SP 800-207, Zero Trust Architecture — https://csrc.nist.gov/pubs/sp/800/207/final (accessed 2026-10-03)
  2. NIST, SP 800-63-4, Digital Identity Guidelines — https://pages.nist.gov/800-63-4/ (accessed 2026-10-03)
  3. SPIFFE, SPIFFE Concepts — https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/ (accessed 2026-10-03)
  4. W3C, Verifiable Credentials Data Model v2.0 — https://www.w3.org/TR/vc-data-model-2.0/ (accessed 2026-10-03)
  5. IETF, draft-klrc-aiagent-auth-00 — https://www.ietf.org/archive/id/draft-klrc-aiagent-auth-00.html (accessed 2026-10-03)
  6. Cloudflare, Web Bot Auth — https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/ (accessed 2026-10-03)
  7. Model Context Protocol, Authorization — https://modelcontextprotocol.io/specification/draft/basic/authorization (accessed 2026-10-03)
  8. NIST, AI 100-2 E2025, Adversarial Machine Learning — https://csrc.nist.gov/pubs/ai/100/2/e2025/final (accessed 2026-10-03)
  9. OWASP, Top 10 for LLM Applications — https://genai.owasp.org/llm-top-10/ (accessed 2026-10-03)
  10. Google, Agent Payments Protocol (AP2) — https://ap2-protocol.org/ (accessed 2026-10-03)