$HEADLESS SYSTEMS
$ cat /blog/agent-identity-missing-primitive

Agent payments shipped. Agent identity didn't.

Petr Pátek··17 min·systems
Agent payments shipped. Agent identity didn't.

On March 2, 2026, Banco Santander and Mastercard executed Europe’s first live end-to-end payment by an AI agent. The transaction ran on Santander’s production payment rails using Mastercard Agent Pay, with PayOS orchestrating the end-to-end flow. It was small. It was controlled. It was real.

The cryptographic plumbing of the agent economy is now in production. Stripe provisions scoped network tokens for agentic commerce on Visa and Mastercard. Six commerce protocols are stacking on top of each other: ACP (OpenAI and Stripe), UCP (Google), AP2 (Google and the payment networks), MCP, A2A, and Visa TAP. The plumbing for an agent to spend money on your behalf exists, works, and is being adopted by the most regulated financial institutions on Earth.

Underneath the plumbing, the question that nobody fully solved is: which agent, on whose behalf, with what authority, with what audit trail? The Gravitee State of AI Agent Security 2026 report puts numbers on the gap. 88% of organizations confirmed or suspected AI agent security incidents in the past year. Only 21.9% treat agents as independent, identity-bearing entities. 45.6% are still using shared API keys to authenticate agent-to-agent calls. The agent economy is being built on shared API keys.

This is the missing primitive. The thesis of this publication has been that machines are the new primary consumers of software. That thesis needs a corollary. If machines are the principals, software has to recognize them as principals, with identity that is verifiable, scoped, attestable, and bound to accountable humans. Agent identity is not a security feature anymore. It is the bottleneck.

What agent identity actually has to answer

Identity for an AI agent has to answer four questions before any meaningful action: which agent is this, on whose behalf is it acting, what authority does it carry, and what audit trail will it leave. Today’s typical enterprise deployment answers one of those (the API key tells you which long-lived credential was used) and bluffs the rest.

Human identity systems were built around assumptions that do not hold for agents. People are durable, slow, and pseudonymous across services. An employee logs in once a day with a password and an MFA prompt, their session lasts hours, and their identity persists across years of employment. Agents invert every one of these assumptions. They are ephemeral, spawned to handle one task and destroyed. They are fast, capable of making more API calls in an hour than a human will make in a year. And they are delegated, acting on behalf of either a human, an organization, or another agent that itself was delegated.

That structural mismatch is why grafting human identity onto agents falls apart in production. A shared API key is the easiest path because every existing system understands it, but it strips off three of the four answers that identity needs to carry. When a breach occurs, the logs show that “the key” did it. They do not show which of fourteen agents using that key did it, on whose behalf, with what scope. Forensics, compliance, and remediation all collapse into a single question that the system cannot answer.

The correct answer is structurally different. Agent identity has to be short-lived, cryptographically signed, scoped to specific actions and resources, and cryptographically tied to the human or organization that authorized its existence. That set of properties does not exist in any single legacy protocol. It is being assembled from pieces that are shipping now.

What an agent-identity primitive must actually provide

It helps to separate three things that shared API keys collapse into one: identity, credential, and authority. The credential is the bearer secret. Identity is the verifiable claim about who or what is presenting it. Authority is the set of actions that identity is permitted to take. A shared key is a credential with no identity and no bounded authority, which is why it answers only one of the four questions.

An agent-identity primitive has to carry more than a name. The minimum set of properties is concrete.

Attestation. The system needs cryptographic proof that the agent is the code, model, and runtime it claims to be, not an impostor process that stole a token. Without attestation, identity is a self-asserted label.

Delegation chains. Agents act on behalf of humans, organizations, or other agents, often several hops deep. The primitive has to represent the full chain: this agent, authorized by that agent, authorized by that human. A single “service account” field cannot express a chain.

Attenuation. Authority should only ever narrow as it moves down the chain. An agent that receives a scoped right must be able to hand a strictly smaller right to the next agent, and never a larger one. This is the property that makes multi-agent systems safe to compose.

Agent-granular revocation. When one agent misbehaves, you have to be able to kill that agent’s identity without revoking every other agent that shares its lineage. Shared keys make this impossible: revoking the key stops everything.

Offline verifiability. A downstream service should be able to verify an agent’s identity and scope from the token itself, cryptographically, without a network round-trip to a central authority on every call. Machine-speed traffic makes per-call lookups a bottleneck and a single point of failure.

Non-repudiation to a human. The chain has to terminate in an accountable legal entity that cannot later disclaim it. This is the property regulators care about, and the one shared keys erase entirely.

No legacy protocol delivers all six. The pieces shipping now each deliver a subset, which is why the real work is integration rather than invention.

What is actually shipping right now

The shape of the answer is visible across four parallel tracks. None of them is complete on its own. Together they are starting to look like a stack.

KYA and human binding. Sumsub launched AI Agent Verification on January 29, 2026 with an explicit Know Your Agent (KYA) framework. The model is straightforward: KYC the human first, then cryptographically bind every agent that human authorizes to that verified identity. Device intelligence and bot detection identify automation in real time. Liveness verification confirms a human is present at critical moments (onboarding, account control changes, high-value payouts). Network-level signals expose mule patterns before they scale. The Sumsub Identity Fraud Report 2025–2026 logged a 180% year-on-year increase in multi-step coordinated attacks globally in 2025. The product exists because the threat is already measurable.

Workload identity via SPIFFE. The Cloud Native Computing Foundation’s 2026 recommendation for internal service authentication is SPIFFE for identity, OAuth 2.0 for access delegation, and OPA for policy. SPIFFE issues short-lived SPIFFE Verifiable Identity Documents (SVIDs) as X.509 certificates or JWTs. SVIDs are tied to workloads, not people. They auto-rotate. They eliminate the standing-credential problem that shared API keys create. HashiCorp makes the case explicitly that AI agents combine the worst properties of every workload type ever built. Ephemeral, fast, delegated, and operating at machine speed. SPIFFE was designed for exactly this shape.

Delegated authorization. The production stack most teams reach for today is OAuth 2.1 + PKCE + RFC 8693 token exchange. RFC 8693 is the part that matters for agents: it lets one principal exchange its credentials for a scoped, downstream token that another principal (an agent) can use, with the original principal’s authority restricted to a specific action. Biscuits and Macaroons add offline attenuation: the agent receiving a token can cryptographically narrow its own scope before passing it further down the call chain. The combination starts to answer “what authority does this agent carry” with cryptographic precision.

Protocol-level hardening. The Model Context Protocol’s 2025-06-18 specification release reworked its authorization model to align with how OAuth 2.0 is deployed in practice. It classifies MCP servers as OAuth resource servers and requires clients to implement Resource Indicators per RFC 8707, so a malicious server can no longer obtain access tokens minted for another service. The protocol that 97 million SDK downloads per month now run through is closing the gap that allowed token confusion attacks. MCP did not invent agent identity, but it is no longer leaving it as an exercise for the reader.

The pieces are real. The integration is what’s missing.

Know Your Agent is not Know Your Customer with a wrapper

KYA borrows its name from KYC, and the marketing treats them as cousins. They solve different problems, and the difference is the whole point.

KYC verifies a durable legal person once. A bank confirms that a real human with a real identity opened an account, and that identity persists for years. The subject is slow, singular, and legally accountable by default. Onboarding friction is acceptable because it happens rarely.

KYA verifies an entity that is ephemeral, delegated, and often has no legal personhood of its own. An agent is spawned to do one task and then destroyed. It does not have a passport. Its accountability is entirely borrowed from whoever authorized it, which means the primitive KYA has to establish is not “who is this person” but “which verified human or organization stands behind this specific agent, right now, for this action.”

That reframing changes three things.

KYA is continuous, not a one-time gate. Agents spin up and tear down constantly, so verification cannot be an onboarding event. It has to happen at provisioning time for every agent and be re-checkable at the moment of a consequential action.

KYA is about binding, not just verification. The novel primitive is agent-to-human binding with non-repudiation, so the human cannot later claim they did not authorize the agent. KYC has no equivalent concept, because a person is their own principal and does not delegate their legal identity to spawned subprocesses.

KYA has to model delegation and attenuation. KYC assumes a flat relationship between an institution and a customer. KYA has to represent chains and shrinking scope, because an agent frequently acts for another agent that acts for a human.

The regulatory lineage is shared: both descend from anti-fraud and accountability regimes. The failure mode is not. A compromised customer identity is exploited at human speed. A compromised agent identity is exploited at machine speed, which is why liveness checks at critical moments and network-level pattern detection matter more in KYA than the one-time document check that anchors KYC.

Where workload identity fits, and where it stops

SPIFFE is the strongest available answer to the first of the four questions: which agent is this. It is worth being precise about what it does and where it hands off.

SPIFFE establishes identity through attestation, not through a shared secret. A SPIFFE implementation like SPIRE attests both the node the workload runs on and the workload itself before issuing an SVID. The identity is expressed as a SPIFFE ID, a URI of the form spiffe://trust-domain/path, and delivered as a short-lived X.509 certificate or JWT that auto-rotates. Because the SVID is minted from attestation and expires quickly, there is no standing credential to steal, which is the exact failure mode of a shared API key.

Trust domains and federation matter for the agent case specifically. An SVID is scoped to a trust domain, and SPIFFE federation lets one trust domain verify identities issued by another. That is the mechanism for an agent in one organization to prove its identity to a service in a different organization without both sides sharing a secret, which is precisely the cross-org agent-to-agent scenario the commerce protocols assume but do not solve.

The limit is just as important. SPIFFE tells you which workload is calling with cryptographic confidence. It does not, on its own, tell you on whose behalf the workload is acting, and it does not carry task-scoped authority. A single agent process can act for many different users across its lifetime, and its SVID says nothing about which user a given call is for.

This is why the workload identity layer is a substrate, not a solution. You put SPIFFE underneath for “which agent,” OAuth 2.1 token exchange on top for “on whose behalf and with what authority,” and a policy engine like OPA beside them for “is this specific action allowed.” The CNCF recommendation is three layers because no single layer answers all four questions. SPIFFE closes the identity question so cleanly that it exposes how open the delegation and authority questions still are.

Why identity is the bottleneck, not intelligence

The agent economy’s payments layer is shipping because the payments problem decomposes cleanly. A token represents a scoped right to spend. The card network validates the token. The merchant accepts the payment. Each step has thirty years of cryptographic infrastructure behind it. The identity layer does not decompose cleanly because no thirty-year stack solves it.

Six agentic-commerce protocols are now in market: ACP, UCP, AP2, MCP, A2A, and Visa TAP. Each defines how an agent expresses intent, how the payment moves, how the merchant gets paid. Each one assumes someone solved identity. None of them does. The protocols specify what happens when a properly identified agent acts. They are silent on how the agent is identified in the first place.

The breach surface is already visible. 88% of organizations had agent security incidents last year. Autonomous agents now account for 1 in 8 reported AI breaches. Runaway agents have been documented burning through massive volumes of API calls in loops before anyone noticed. Without identity, you cannot rate-limit per agent. You cannot revoke a single misbehaving agent without revoking everything that uses the same key. As I argued in more agents is not the answer, the bottleneck in agent systems is not agent intelligence; it is API quality. Identity is the part of API quality nobody has measured yet. You cannot tell a forensics investigator which of your 40 agents did the thing your auditors are asking about.

This is what a16z is pointing at when its Big Ideas 2026 describes the agent economy bottleneck shifting from intelligence to identity. Bessemer Venture Partners is more direct: securing AI agents is the defining cybersecurity challenge of 2026. When the smartest investors in infrastructure agree that the next chokepoint is identity, the next chokepoint is identity.

The pattern is familiar from web architecture. We solved payments before fraud. We solved authentication before authorization. We solved HTTP before HTTPS. Each time, the missing primitive arrived only after the underlying activity was already at scale. The agent economy is following the same script. The activity is already at scale. The primitive is still missing. The companies that build it well will look like Cloudflare or Auth0 in five years.

The regulators got there before the vendors did

While vendors are still arguing about which token format wins, regulators have already decided that agents need identity, and they have written it into law.

The EU AI Act mandates operator identity in behavior logs of high-risk AI systems. If you operate an AI agent that takes consequential action, the regulation says the logs have to identify both the agent and the operator behind it. Vague aggregate logging does not satisfy the requirement. The text exists. The enforcement timelines exist.

The US NIST AI Risk Management Framework lists agent identity management as a priority standards area. OWASP shipped its Top 10 for Agentic Applications 2026, with ASI01 Agent Goal Hijack as the first entry: attackers embed malicious instructions in content an agent reads (emails, documents, code comments, web pages) that override the agent’s original goals. Defending against ASI01 requires the system to know which goals are the agent’s actual authorized goals and which are injected. That is an identity-and-authority problem before it is a content-filtering problem.

The compliance gap is what enterprises should be watching. Most organizations are still binding agents to humans through shared keys and aggregate logs. EU AI Act audits do not accept that. A Fortune 500 company that deployed 40 agents through Microsoft Copilot or Salesforce Agentforce will, within the next 18 months, have to answer “which agent did this” with cryptographic precision, not service-account ambiguity. The retrofit is going to be expensive.

Regulators are forcing the issue ahead of the vendors. The vendors that build agent-identity-as-a-feature into their products before customers are subpoenaed for the answer will win the next procurement cycle.

What enterprise architects should do now

The agent identity problem looks unsolvable in the abstract and concrete once you decompose it. Five steps move a real production system from “shared API key bluff” to “identity-bearing principals.”

Stop using shared API keys for agents. The single most impactful move is to issue per-agent identity with finite TTL. SPIFFE/SPIRE is the most mature open-source path. Hyperscaler equivalents (AWS IAM Roles Anywhere, GCP Workload Identity Federation, Azure managed identities for workloads) are catching up. The cost of migrating 40 agents off a shared key is real. The cost of explaining at an audit that “the key” performed a regulated action is higher.

Bind every agent to a verified human sponsor at provisioning time. KYA is not a feature. It is a system property. Every agent should carry a cryptographic link to a verified human or organization that holds legal accountability for what the agent does. Sumsub provides one productized path. Internal systems can build their own bindings against existing IAM. The detail that matters is non-repudiation: the human cannot later claim they did not authorize the agent.

Adopt OAuth 2.1 + token exchange for delegated authority. RFC 8693 is the cleanest mechanism for an agent to act on behalf of a user with scope strictly narrower than the user’s. Combined with Biscuits or Macaroons for downstream attenuation, this answers “what authority does this agent carry” in a way that downstream services can independently verify without a network round-trip.

Log agent ID, human sponsor, and scope on every privileged action. This is the audit trail. It is also the input to every interesting agent-aware control: per-agent rate limits, per-agent anomaly detection, per-agent forensics. The cost is a logging schema change. The benefit is every other capability in this list.

Treat agent identity as a procurement criterion. As SAP’s API policy made explicit, vendors are starting to compete on how they gate agent access; identity scoping is the other half of that conversation. When evaluating SaaS vendors, ask how they scope agent identity, how short-lived their tokens are, how they audit agent actions, and whether their identity model survives an EU AI Act review. Vendors who answer “we use API keys” are signaling that their next renewal will be more expensive. Add the question to the same checklist as SOC 2 and data residency. As the Headless Index evolves, identity scoping is moving up the rubric.

The headless thesis needs identity to land

This publication has argued that software is becoming machine-consumed, that UI is becoming optional, that APIs are the product, and that vendors who refuse to expose their software headless will lose. That thesis is correct. It is also incomplete without identity.

A headless API consumed by anonymous callers is a security incident waiting to happen. A headless API consumed by identity-bearing agents bound to accountable humans is the future the regulators, the cybersecurity researchers, and the smartest infrastructure investors all see arriving. The difference is whether the agents calling your API are principals or anonymous traffic.

The payments problem has been solved. The intelligence problem is being solved every six months. The identity problem is open, the regulations are closing in, and the breach data is already in the millions of dollars per incident. KYA, SPIFFE, OAuth 2.1 token exchange, and protocol-level hardening like the MCP 2025-06-18 authorization overhaul are the pieces that will assemble into the missing primitive. The companies that assemble them well now will define what agent identity means in 2028.

Money without identity is fraud at scale. Agency without identity is liability at scale. The agent economy is building both right now. The next 18 months pick whether identity gets there in time.