Who Is This Agent? Non-Human Identity in 2026, From the RFCs to the Breaches

Two days ago I wrote that the MCP protocol got hardened and the ecosystem did not. This morning I wrote that agent payments are stuck not on the wire format but on the question of who the agent is and what it may spend. Both posts pointed at the same hole, so this one is about the hole.

The problem in one sentence: an AI agent is a workload that acts on behalf of a person, holds credentials for a dozen systems, makes decisions nobody reviewed, and is created and destroyed a thousand times a day. Every existing identity system was designed for exactly one of those properties. Service accounts are long-lived and act for nobody. OAuth delegates a human's authority to one app for one API. Workload identity (SPIFFE) proves what a process is, not whom it is acting for. Agents need all three at once, chained, with an audit trail, at a scale where a human cannot approve each grant.

This post is where that stands on 7 September 2026, from the standards bodies, the vendors, and the incidents, with the parts I consider settled separated from the parts that are still drafts. I run a platform where agents execute code in microVMs, so I have a stake in this, and I will say what I actually do at the end.

The number that reframes the problem

Palo Alto Networks, which completed its acquisition of CyberArk in February, published the combined 2026 Identity Security Landscape from a survey of 2,930 organisations: machine identities outnumber human ones 109 to 1, up from a widely cited 82 to 1 a year earlier, nine in ten organisations reported an identity-related breach, and AI agent identities were expected to grow 85% in the year. I could not reach the original 82:1 press release because the CyberArk domain now redirects, so hold the trend rather than the exact ratio. But the direction is not in dispute, and it means identity teams that spent twenty years managing humans now manage a population where humans are a rounding error.

The breaches that made this concrete were not exotic. In August 2025, an attacker tracked as UNC6395 stole OAuth tokens issued to Salesloft's Drift chatbot, used them to export Salesforce data from more than 700 organisations, and then searched the exports for AWS keys, Snowflake tokens and passwords. The agent was legitimate. Its tokens were legitimate. They were also long-lived, broadly scoped, and stored somewhere an attacker could reach. The npm worms I wrote about on Saturday harvested GitHub tokens and cloud keys from developer machines for the same reason.

And on 25 April 2026 the failure mode moved from "attacker uses agent's credentials" to "agent uses its own credentials, badly". A Cursor agent working on a startup called PocketOS found a Railway API token in the repository, created for domain management but scoped to the whole account, and deleted the production volume and its backups in about nine seconds. Railway subsequently made volume deletion a delayed operation. Nobody attacked anyone. A token that could do more than its purpose met a workload that would do whatever it could. That is the whole non-human identity problem in one incident, and I have written before about deleting my own production data with the same kind of over-broad credential, so I am not writing this from a great height.

What standardised

The IETF OAuth working group has over 70 drafts in flight, and a recap from Duende last month picked out the agent-relevant ones. Here is my own reading of the datatracker, ranked by how close each is to something you can build on.

Settled, published RFCs you should already be using. RFC 8693 (token exchange) lets a service trade one token for another with a narrower audience, and its actor_token and may_act claims are the mechanism for "agent acting on behalf of user". RFC 9396 (rich authorization requests) lets a token say what it may do in structured form rather than as a scope string, which is how you express "may transfer up to $50 to this payee" instead of "payments:write". RFC 8707 (resource indicators) and RFC 9728 (protected resource metadata) are the pair that stops a token minted for one server being replayed at another. None of these were written for agents. All of them are what the agent drafts are assembled from.

The token exchange request, verbatim from the RFC, is the single most useful thing to understand in this whole area:

POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
Authorization: Basic cnMwODpsb25nLXNlY3VyZS1yYW5kb20tc2VjcmV0
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&resource=https%3A%2F%2Fbackend.example.com%2Fapi
&subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

The response is a new access token scoped to backend.example.com, and in the RFC's example it expires in 60 seconds. The caller presented the user's token and got back a different token that says "this workload, for this user, for this backend, for one minute". Everything below is elaboration on that move.

About to be RFCs. Identity and Authorization Chaining Across Domains (draft 17, July 2026) was submitted to the IESG for publication as a Proposed Standard; it combines token exchange with the JWT authorization grant so the chain above can cross trust boundaries, which is the case where your agent calls a SaaS vendor's API rather than your own backend. Its authors are from Defakto, MITRE, the NSA, Ping and Okta, which tells you who wants it. Transaction Tokens (draft 11) is at working-group last call and does the same job inside one domain: a short-lived token carrying the user, the originating workload and the authorisation context through every hop of an internal call chain, so the fifth microservice knows why it is being asked to do something.

Adopted, still moving. The Client ID Metadata Document draft makes a client's ID an HTTPS URL that points at its own metadata, which the authorization server fetches. This replaces dynamic client registration, and it matters because MCP just made it the preferred mechanism. The Identity Assertion JWT Authorization Grant is the basis of what Okta ships as Cross App Access: an app you signed into via your IdP gets a token for a different app's API from that same IdP, without a second consent screen and without the user's password ever going anywhere.

Individual drafts, not adopted. The one that got the most coverage last year, "On-Behalf-Of User Authorization for AI Agents" with its requested_actor parameter, expired without working-group adoption. A newer individual draft on transaction authorization challenges (June 2026) lets a resource server reply "this specific operation needs a human-approved, transaction-scoped token", which is the right shape for "the agent wants to delete the volume" and which I would watch. If you see a vendor citing the on-behalf-of draft as a standard, they are citing something that is not one.

MCP. The 2026-07-28 revision I covered on Friday deprecated dynamic client registration in favour of the metadata-document draft, added issuer identification, requires that client credentials be keyed by issuer and never reused across authorization servers, formalised scope step-up, and moved extensions to a separate repo where the "Enterprise-Managed Authorization" extension, which is Okta's cross-app access under a vendor-neutral name, is marked stable. The 2025-06-18 rules still stand: OAuth 2.1, PKCE, resource indicators, no token passthrough, and a section on the confused deputy that requires per-client consent for any MCP proxy using a static client ID.

Workload identity. SPIFFE and SPIRE (v1.15.3 in August) are the proven way to give a process a cryptographic identity without a secret in a file, and the IETF's WIMSE group is writing the architecture to carry that identity through multi-system calls. Section 3.4.11 of the current draft treats an AI intermediary explicitly as a delegated workload that inherits and must propagate its caller's security context, which is a quiet but important statement: the standards body's position is that an agent is a workload, not a user. The Go library already has experimental support for the WIMSE identity token. Getting a workload's SVID is one command against the local agent:

bin/spire-agent api fetch x509 -write /tmp/
# SPIFFE ID:  spiffe://example.org/myservice
# Writing SVID #0 to file /tmp/svid.0.pem.
# Writing key #0 to file /tmp/svid.0.key.
# Writing bundle #0 to file /tmp/bundle.0.pem.

Web-scale bot identity. Cloudflare's Web Bot Auth uses HTTP message signatures (RFC 9421) so a crawler or agent proves who it is per request instead of by IP range or user-agent string; the IETF chartered a webbotauth working group around it, and Cloudflare's signed agents programme and agent registry list OpenAI, Block, Browserbase, Amazon Bedrock AgentCore, Vercel, Shopify and Visa. I checked the well-known key directories this week: OpenAI publishes an Ed25519 key set at chatgpt.com/.well-known/http-message-signatures-directory. Anthropic does not, at any of its domains. That is a concrete gap that any site trying to distinguish Claude's browsing from an impersonator will notice.

What shipped

Standards are the slow half. This is what you can buy or deploy today, in the order it went generally available.

Product	Status	What it actually does
Auth0 for AI Agents	GA Nov 2025	Token Vault (RFC 8693 underneath), asynchronous human approval via CIBA, fine-grained authz for retrieval
Ping Identity for AI	GA 31 Mar 2026	Agent IAM core, agent gateway, agent detection
Microsoft Entra Agent ID	GA Apr 2026	Agent identities with sponsors and owners, an auth SDK sidecar, Conditional Access templates split into autonomous and on-behalf-of
Google Cloud Agent Identity	GA	SPIFFE IDs (spiffe://trust-domain/resources/service/path), auto-issued 24-hour X.509 certs, mTLS plus DPoP through an agent gateway; user tokens brokered and decrypted only at the gateway
AWS Bedrock AgentCore Identity	GA Oct 2025; Secrets Manager integration Jun 2026; managed OAuth consent portal 1 Sep 2026	Credential providers per gateway, secrets by ARN
HashiCorp Vault	Enterprise public preview 23 Jun 2026	Agent registry, on-behalf-of delegation tracking, "ceiling" policies the agent cannot exceed, RFC 9396 per-request authorisation
Okta Agent SSO	GA 24 Aug 2026	Agents in the directory with short-lived tokens; included in core SSO at no extra charge
1Password Unified Access	Mar 2026	Runtime-scoped credentials for agents promised later this year; partners include Anthropic, OpenAI, Cursor

The consolidation is as informative as the launches. In eight months Palo Alto bought CyberArk, CrowdStrike announced SGNL, Cisco bought Astrix, SailPoint bought Entro for a reported $200 million, and Oasis signed a letter of intent with Cyera after raising $120 million in April. Every large security vendor has decided that non-human identity is a feature of its platform rather than a category, which usually means the standalone products have about a year left.

Three design choices in that table are worth copying regardless of vendor. Google's 24-hour certificates with DPoP binding, so a stolen token is useless without the key and is dead by tomorrow anyway. Vault's ceiling policies, where a human sets the maximum an agent may ever be delegated and every on-behalf-of grant is intersected with it. And Entra's sponsor model, which gives every agent a human who is accountable for it and whose departure triggers the agent's review. OWASP's Non-Human Identities Top 10 puts improper offboarding at number one for a reason: the agent that outlives its purpose is the one nobody is watching.

The chain I would build

Here is the delegation chain, drawn the way I think about it. Every arrow is a token exchange, every box gets a narrower token than the one before, and nothing on the right ever sees the credential from the left.

Concretely:

1. The agent is a workload first. It gets a SPIFFE identity from the platform at start, and that identity, not an API key in an environment variable, is what it presents to the authorization server. On PandaStack, each microVM gets its identity from the host at restore time; I have written about what fork preserves, and identity material is on the list of things a forked VM must not inherit.
2. The user's authority arrives as a token, is exchanged once, and is never stored. The agent runtime trades the user's token plus its own identity for a short-lived actor token with the user as subject and the agent as actor. Vault's preview, Auth0's Token Vault and Google's auth manager all do this exchange for you; if you roll your own, RFC 8693 is a hundred lines in any OAuth library.
3. Every tool call is another exchange, with the operation in the token. The MCP gateway exchanges the actor token for a per-tool token carrying authorization_details that say what the call may do. "Delete volume" is not a scope; it is a transaction that should trigger the step-up flow, and until the transaction-challenge draft matures, that means a human in the loop for anything destructive, which is what Railway ended up implementing by making deletes slow.
4. Ceilings are set by humans, intersected by machines. The agent's maximum authority is a policy a person wrote. Every exchange returns the intersection of that ceiling, the user's grant and the tool's own scope. A prompt injection can push an agent to the ceiling; it cannot push through it.
5. Tokens expire before anyone has to revoke them. Sixty seconds for a tool call, 24 hours for a workload certificate. The Salesloft tokens lived for months. Revocation is a control that assumes you noticed.
6. Every agent has a sponsor and an end date. The offboarding problem is the oldest one in identity and it is worse for agents because nobody feels responsible for a program. Entra's sponsor model is the right primitive; implement it in your own directory if you do not use theirs.

The OWASP Top 10 for Agentic Applications, published in December, lists "identity and privilege abuse" third, after goal hijacking and tool misuse. I would put it first, because the other two are only dangerous in proportion to what the agent's identity lets it do. The five-nation guidance from CISA, NSA, ASD and the UK and New Zealand centres in April, which I could only read via a CSA summary, says the same in a sentence: each agent should be "a distinct principal: a verified identity with a cryptographically anchored key or certificate, using short-lived credentials". That sentence is, as far as I can tell, the entire consensus of the field as of this month, and it is a good one.

What I actually do

PandaStack does not implement all of the chain above, and I would rather say so than imply otherwise. Each VM has a platform-issued identity and a per-tenant token with a fixed lifetime; there is no token exchange with a customer's IdP, no rich authorization details on tool calls, and the audit log records the VM and the API call but not the human on whose behalf it ran. The confused-deputy protections in the MCP spec are implemented where I expose MCP; the sponsor model is a spreadsheet.

What I have changed since the PocketOS incident is narrower and, I think, more useful for anyone reading this: every credential an agent can find in a VM is now scoped to the one thing it was created for, checked at creation by a script that refuses account-wide tokens, and destructive operations against tenant storage go through a delayed queue that a human can cancel. Astrix's scan of public MCP configurations, which I have only via secondary reporting, found around 24,000 unique secrets in config files and hard-coded credentials in half the servers sampled. Fixing that does not require waiting for an RFC. It requires op:// references or Secrets Manager ARNs instead of strings, which every runtime in the table now supports, and a scanner in CI that fails the build on the string.

The standards will arrive: identity chaining will be an RFC by year end at the current pace, transaction tokens shortly after, and the metadata-document draft is already what MCP clients implement. What will not arrive on its own is the ceiling policy, the sponsor, and the delayed delete, because those are decisions about what your agents may do, and no protocol can make them for you.

---

Related: MCP Security in 2026, The Worms Learned to Use Your AI Agent and Isolation Is Not an Abuse Control.