Kerberos Won Because Nobody Had to Implement It

Kerberos did not win the enterprise because the protocol was good, although it was. It won because most of the people who benefited from it never had to implement it.

An application developer on Windows in 2001 got Kerberos without reading a line of RFC 1510. They called a generic API, the platform produced whatever mechanism it could negotiate, and the tickets, keys, renewals, and trust relationships were someone else’s code. Services still needed SPNs, policy, and operational care, but application code was not full of ticket choreography. That developer experience, more than the cryptography, is what made Kerberos the default identity fabric of the Windows enterprise for two decades.

So the question I keep turning over about AAuth, the proposed agent authorization protocol I have written about in two earlier posts, is not whether it can be the next Kerberos. It is whether anyone is building the parts of Kerberos that were never the protocol. Is there an SSPI for agents?

The short answer is no. The longer answer is that fragments exist, they do not compose yet, and the layer that actually decided Kerberos’s fate has no owner at all.

So here is the thesis up front. The question is not whether AAuth has the right wire. The question is whether an agent runtime exposes a provider seam above the wire: one interface where agent code asks for authorized access, and the platform decides whether that means AAuth, MCP-style OAuth, a bearer token, or a signed request. That seam is the agent-era equivalent of SSPI, and the rest of this post is about the layers it would have to stand on. It is also the first of three essays on who controls the agent stack. This essay owns the first control point. The next two move up the stack.

The series uses one map throughout:

The first three are the control points this series contests because products can compete to own their interfaces and durable state. The fourth is the resource owner’s final decision, deliberately outside those upstream contests. No identity, credential, or approved-task record can command a resource to act.

The Stack That Carried the Protocol

Kerberos shipped inside a four-layer stack, and only one layer was the protocol.

The protocol mattered because it was good enough to disappear behind these layers.

Two counterfactuals show which layers Kerberos actually needed.

The first: GSS-API existed on Unix from 1993, a full standardized mechanism-hiding interface, but Kerberos did not become a comparably universal default in heterogeneous Unix estates where deploying and operating a realm remained a separate project. MIT realms mattered in universities, research environments, and serious Unix shops. The contrast does not prove one cause, but it makes the distribution lesson hard to ignore: the interface was necessary, and a pre-deployed identity authority was a major advantage.

The second: OAuth won the internet without an equivalent universal platform layer. There is no SSPI for OAuth. Some ecosystems hide parts of the flow behind SDKs, identity proxies, managed identities, or browser-mediated login, but the generic application still tends to own token acquisition, storage, refresh, audience mistakes, and error handling. The cost is visible everywhere: leaked refresh tokens, misconfigured redirect URIs, confused redirect flows, and entire product categories that exist to compensate. The 2022 theft of OAuth tokens issued to Heroku and Travis-CI put a name on that cost, integrators holding token custody themselves, and dozens of downstream organizations breached through it. The protocol succeeded and the developer experience stayed fragmented. Agent frameworks are re-learning that cost right now, one tool integration at a time. OAuth could win fragmented because the internet has no single platform owner to ship the missing layer, so it settled for protocol ubiquity and a permanent integration tax. That is the higher bar AAuth is trying to clear: to become invisible and not merely spoken, something OAuth achieved in particular platforms and ecosystems but never as one general application-facing seam.

Put the two together and the pattern is clear:

A protocol wins big when the people who benefit from it stop being the people who implement it.

The Same Map, Drawn for Agents

Here is the Kerberos stack mapped onto the agent world as it stands in mid-2026.

The interface row is further along than most people notice. The MCP authorization specification puts resource discovery, OAuth authorization choreography, and resource-indicator audience binding (RFC 8707) in the client. The code that decides to call a tool never sees a token. That is SSPI’s most important division of labor, and it is why MCP-based agents already have a better credential story than most hand-rolled OAuth integrations. The limits are equally clear: it is one ecosystem, it is shaped around OAuth, and it is not a general mechanism provider.

The custody row is where the vendors are. SPIFFE comes closest to a standardized custody interface: the workload asks a local API for its identity, and key material, rotation, and attestation stay with the platform. That is the LSA’s job description. Google’s Agent Identity is generally available for Agent Runtime and assigns SPIFFE-based, lifecycle-bound identities. Its outbound credential vault and authentication broker remain in preview. That is the closest thing yet to an LSA for a Google-hosted runtime, not a general cross-platform LSA. Microsoft Entra Agent ID is now generally available and is the most directory-shaped move on the board, making agents governable by the identity plane that already governs users, apps, and workloads. The proposed draft-klrc-aiagent-auth composes WIMSE, SPIFFE, and OAuth into one architecture. These are live product positions and active standards signals, with some surrounding broker and policy capabilities still pre-GA. Each is LSA-like. None supplies a general cross-platform LSA or a shared interface above it.

The identity-authority row is the one that decided Kerberos’s fate, and for agents no generally accepted cross-runtime owner has emerged. Active Directory won because the KDC arrived with the domain, the machine account arrived with the join, and the SPN arrived with the install. Agent enrollment and credential issuance are now being added to systems enterprises already run, but every candidate begins inside its own boundary: the enterprise IdP, cloud runtime, harness vendor, or agent provider, which is a claim at least one vendor now makes explicitly. An agent built in one company can act against resources in another, so the analog cannot stop at a directory everyone joins. It needs verifiable runtime evidence, enterprise binding, and issuer trust across domains. Which product owns that binding, and whether a layer can operate above several runtimes, is the second essay’s question rather than this one’s answer.

The rollout row is quietly in the best shape, with an important caveat. HTTP does not give agents SPNEGO. It gives protocols response surfaces on which capabilities and requirements can coexist. WWW-Authenticate advertises authentication schemes. Accept-Signature can require HTTP Message Signatures. AAuth uses its own AAuth-Requirement header for agent tokens, authorization, and deferred interaction while explicitly allowing existing WWW-Authenticate challenges beside it. That is enough for incremental rollout, but not enough by itself for safe mechanism selection. Clients still need policy, downgrade protection, and resource allowlists so “supports bearer” does not silently beat “must sign here.” The useful parallel with Kerberos is coexistence: legacy credentials where that is all the resource speaks, signed identity and mediated authorization where both sides are capable.

Where AAuth Sits on This Map

AAuth proposes the wire, and its August 2026 draft specifies several ways to enter it: a key-bound agent identifier, requests protected with HTTP Message Signatures, four progressively richer resource-access modes, and an orthogonal governance layer in which a Person Server can mediate consent and missions. The lowest mode lets a resource recognize signed agent identity without deploying a Person Server or Access Server. The richer modes add resource-managed authorization, Person Server assertions, and federation. My earlier posts cover what the protocol gets right and where the mission layer still falls short of portable containment. This post is about a different axis: not whether the protocol is sound or incrementally designed, but whether its mechanisms disappear behind a paved provider seam.

Today those mechanisms do not disappear. The draft records exploratory implementations in TypeScript, .NET, Python, and Java, and the project publishes SDK and demo entry points. That running code matters. It is how early adopters survive and provider interfaces get proven. But a library or demo is not the provider interface itself. Agent applications still have to opt into AAuth identity, signing, discovery, and challenge handling. This is pre-SSPI Kerberos: usable by implementers, but not yet a mechanism the platform selects and operates on behalf of otherwise unchanged agent logic.

The proposal names the right lower boundary. An Agent Provider issues a short-lived agent token that binds an identifier to the agent’s key after a platform-specific enrollment step. How the instance proves itself to that provider is deliberately outside the wire protocol. Self-hosted and organizationally bundled deployments are possible. What remains unclaimed is the seam this post opened with: the interface between agent code and that platform machinery that lets agent logic written once come out speaking AAuth, MCP-style OAuth, or a plain bearer token, depending on what the resource and local policy permit.

That seam is not primarily a new wire protocol. A small provider interface may eventually need standardization, but every responsibility it must cover has a Kerberos precedent and an existing piece to reuse:

The missing ingredient is not another agent-authentication scheme. It is ownership. A harness vendor has to ship this seam as the default path, the way Windows shipped SSPI in the box. The harness is the operating system of this era, and it has the strongest claim on the seam, because it already knows which tool is being invoked and can pick a mechanism by intent rather than only sign bytes. But the claim is contested. An enterprise AI gateway or egress proxy can inject tokens and sign requests transparently, without the framework linking anything, which is the more invisible option, closer to IPsec than to SSPI. Its limit mirrors its strength. It sees the wire, not the work, so it can attach a credential but cannot decide which mechanism the task warrants or carry mission context the resource can enforce, and that same egress boundary is already a policy enforcement point for what an agent may reach. Whether the seam lands in the harness or the gateway is the live question, and it may be both, the harness choosing the mechanism and the gateway enforcing the floor.

The Analogies Need Precise Agent Names

The deeper reason the Kerberos analogy is worth taking seriously is that its supporting concepts expose problems the agent identity work is already solving under different names. They do not map one-to-one, and the differences identify work the analogy cannot do for us.

The machine account is the enrollment root, not the agent instance. A Kerberos machine account belonged to the enrolled host, not to the application running on it, and its keys existed because of the join rather than developer provisioning. Its closest modern analog is runtime or workload identity: proof about the execution substrate and its key. An agent client instance is one layer above that root, a running actor distinct from both host and client software identity. The proposed Client Instance Assertion gives that higher binding a verifiable form. Collapsing the two would let a shared host identity impersonate every agent it runs.

Constrained delegation requires more than the actor chain. S4U2Proxy made onward delegation depend on KDC policy and target restrictions rather than the service’s preference alone. The OAuth analog is issuer-enforced delegation: authenticated actor context, an audience-specific credential, and authority that is the same or narrower at every hop. An act claim carried consistently across assertion grants and access tokens preserves the attribution half, which the proposed Actor Profile makes interoperable. It does not prove narrowing by itself. Treating an actor chain as a delegation constraint would turn audit context into authority.

The PAC is authorization context that travels. The Privilege Attribute Certificate put the authority’s statement of authorization data inside the ticket, so the resource did not have to reconstruct it from scratch. AAuth’s mission context is the nearest agent-world analog, task-shaped authorization context minted upstream at approval and consumed downstream. The analogy should not be pushed too far, a PAC is directory-shaped data inside a ticket, but the lesson carries. The PAC interoperated because a single vendor defined it and everyone else conformed. An agent ecosystem gets no such shortcut, so the equivalent artifact has to interoperate across vendors from the start. Context that travels only as correlation is not enough. The receiving resource needs enough stable meaning to enforce it, and that is precisely the containment gap the current mission layer has not closed.

Where the Analogy Breaks

Five differences keep the analogy honest.

Kerberos won at home. It won the intranet and lost the internet. Cross-realm trust was its weakest feature, and the open web went to TLS and OAuth instead. Agents are inherently cross-domain, so the next Kerberos has to win on exactly the terrain the first one lost. That inverts the weighting of the stack: negotiation and federation, minor for Kerberos, become necessary for agents.

Active Directory never had to compete for the role. One authority owned every principal in the domain: users, machines, and services alike. Agent authority has at least four claimants, and each has a structural reason to want the position. Until one of them ships enrollment by default, “the Active Directory of agents” is a market position, not an architecture.

Tickets expire, missions terminate. Expiry was the only lifecycle Kerberos needed, because a ticket held no purpose, only a principal and a window of validity. A durable agent task needs more: termination that reaches the runtime, suspension that means something different from cancellation, and revocation that propagates faster than the work. Those are the lifecycle gaps the AAuth mission layer is still working through, and no amount of Kerberos nostalgia supplies them.

The trusted principal is now untrusted reasoning. Kerberos assumed a hostile network and a trustworthy principal. Once the KDC authenticated you, what you did with the ticket was your business, and the wire was the thing under attack. Agents invert both halves. TLS already secured the wire, and the untrusted element moved inside, into reasoning that prompt injection and drift can steer. A seam that faithfully signs whatever the agent asks for authenticates the request without making the decision safe. That is a different problem from the one this post is about, and I take it up in the least-privilege series, where the model is untrusted reasoning and the protocol layer’s job is to govern the invocation, not the reasoning. The point here is narrower. An SSPI for agents makes the credential invisible. It does not make the authenticated agent trustworthy, and those layers are not the ones Kerberos supplies.

HTTP response negotiation is not SPNEGO. SPNEGO negotiates mechanisms inside a security framework. HTTP exposes status codes and independent headers whose semantics come from their own specifications. WWW-Authenticate, Accept-Signature, and AAuth-Requirement can coexist, but their coexistence does not create a trustworthy preference order. The agent platform has to know when bearer is acceptable, when signed requests are required, which authorization flow it can satisfy, and when to fail rather than downgrade.

The Practical Takeaway

Is there an SSPI for agents? Not yet. There are fragments: the MCP client is the most SSPI-shaped component shipping, SPIFFE is the closest thing to a standardized custody interface, the vendor brokers are competing LSAs, and HTTP response negotiation is a useful rollout surface. Nobody owns the seam that joins them, and nobody ships a generally accepted cross-runtime binding layer by default.

One distinction keeps the conclusion honest. The harness can plausibly become the SSPI of this era, and an egress gateway may take part of the role, the harness choosing the mechanism because it sees the requested tool and the gateway signing transparently at the boundary. But whichever holds the seam, it is not automatically the identity binding layer. It can select and hold credentials. It cannot, by itself, establish enterprise ownership, approve a behavioral deployment, create legitimate task authority, or override resource policy. The next two essays are about those records.

For AAuth, or any agent protocol with the same ambition, the protocol itself is the smallest part of the work, and unusually, it is the part in the best shape. The order of work the Kerberos precedent suggests:

1. The interface. A provider seam in the harness, or split with an egress gateway, so agent logic never touches the mechanism and the platform decides what gets spoken on the wire.
2. The custody. Keys, attestation, caching, refresh, and signing at the platform layer, with instance enrollment as a side effect of deployment rather than a developer task.
3. The binding handoff. Verifiable runtime evidence that an enterprise-chosen system can bind to an Agent and Agent Deployment record before an issuer projects the result into a credential.
4. The policy-aware rollout. Challenge-driven upgrade with explicit downgrade protection, so bearer tokens and signed requests can coexist on the same resources for years, because coexistence is unavoidable.

AAuth has proposed a wire and, unusually for a young proposal, named an Agent Provider and a platform-specific enrollment boundary. What it cannot do from inside a wire specification is make the provider and binding layers exist. Kerberos did not become invisible because MIT wrote more RFCs. It became invisible because platform vendors made the surrounding stack part of the paved road. The pattern that decided Kerberos’s fate supplies the series’ couplet. Distribution determines the default. Standard seams determine whether the default can be challenged.

The next Kerberos will not be picked by agent developers comparing protocols. It will be shipped by whoever owns the layers they never have to see.