---
title: "Kerberos Won Because Nobody Had to Implement It"
date: "2026-07-08T10:00:00-07:00"
lastmod: "2026-07-08T10:00:00-07:00"
description: "Kerberos did not win the enterprise on protocol merit alone. It won because SSPI hid the mechanism, the LSA owned credential lifecycle, and Active Directory shipped the authority by default. For AAuth to become infrastructure rather than another integration pattern, a platform has to build those layers for agents."
summary: "The question worth asking about AAuth is not whether the protocol is good. Kerberos won because of everything around the protocol: SSPI and GSS-API hid the mechanism from application developers, the LSA owned keys and ticket lifecycle, machine accounts existed as a side effect of domain join, Active Directory shipped the KDC by default, and SPNEGO made rollout incremental. Mapping that stack onto agents shows where the work is: the MCP client is the most SSPI-shaped thing shipping, SPIFFE and vendor brokers are competing for the custody layer, HTTP authentication challenges are a useful but weaker SPNEGO analog, and nobody ships the authority by default. AAuth has specified the wire and named the platform split. The layers that made Kerberos invisible are still unclaimed."
slug: "kerberos-won-because-nobody-had-to-implement-it"
tags:
  - "AAuth"
  - "Agentic Identity"
  - "Authorization"
  - "OAuth"
  - "MCP"
  - "Kerberos"
  - "Standards"
---


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](https://www.rfc-editor.org/rfc/rfc1510). 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](https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/), the proposed agent authorization protocol I have written about in [two](/notes/mission-architecture-on-aauth/) [earlier](/notes/aauth-now-has-a-mission-layer/) 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.

## The Stack That Carried the Protocol

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

| Layer | What it was | What it removed |
| --- | --- | --- |
| The interface | [SSPI](https://learn.microsoft.com/en-us/windows/win32/secauthn/sspi) on Windows, [GSS-API](https://www.rfc-editor.org/rfc/rfc2743) in portable stacks | Applications never learned the mechanism. They called `InitializeSecurityContext` and got whatever the platform negotiated. |
| The custody | The Local Security Authority: TGT at logon, ticket cache, automatic renewal, machine account keys rotated on schedule | Nobody managed keys or ticket lifecycle. Credentials existed because the machine joined the domain. |
| The authority | Active Directory: every domain controller a KDC, every joined machine an enrolled principal, every service an SPN | Enterprises did not deploy a separate authority. The KDC came with the domain and was already running when the first Kerberized application arrived. |
| The rollout | [SPNEGO](https://www.rfc-editor.org/rfc/rfc4178) negotiation, [HTTP Negotiate](https://www.rfc-editor.org/rfc/rfc4559) | Nobody coordinated a flag day. Applications could fall back to NTLM until both sides could do better. |

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

Two counterfactuals show which layers were load-bearing.

The first: GSS-API existed on Unix from 1993, a full standardized mechanism-hiding interface, and Kerberos still never became the default anywhere the authority was not pre-deployed. MIT realms mattered in universities, research environments, and serious Unix shops, but running the authority was a project, and the fabric never spread far past the teams willing to take that project on. The interface was necessary. The pre-deployed authority was decisive.

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 protocol succeeded
and the developer experience stayed fragmented. Agent frameworks are
re-learning that cost right now, one tool integration at a time.

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.

| Kerberos layer | Agent-world analog | State today |
| --- | --- | --- |
| SSPI / GSS-API | The harness: an MCP client or agent runtime acquiring credentials on behalf of agent logic | Shipping in MCP clients, not generalized |
| LSA, ticket cache, machine accounts | Platform key custody, attestation, brokered short-lived tokens | Fragmented across SPIFFE, cloud runtimes, and vendor brokers |
| Active Directory | Default agent enrollment in something enterprises already run | No default owner |
| SPNEGO | HTTP authentication challenges | Workable, but weaker than SPNEGO and policy-dependent |

The interface row is further along than most people notice. The [MCP authorization specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) puts resource discovery, OAuth authorization choreography, and resource-indicator audience binding ([RFC 8707](https://www.rfc-editor.org/rfc/rfc8707)) 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](https://spiffe.io/) 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](https://docs.cloud.google.com/iam/docs/agent-identity-overview) builds a broker and credential vault on SPIFFE: the closest thing yet to an LSA for a hosted runtime, binding identity to the agent's lifecycle and hiding key handling inside the platform, though not a general cross-platform LSA. Microsoft's [Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/agent-oauth-protocols) is the most directory-shaped move on the board, making agents governable by the same identity plane that already governs users, apps, and workloads, from the company that shipped the original stack. And the proposed [draft-klrc-aiagent-auth](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) composes WIMSE, SPIFFE, and OAuth into one architecture. Each of these is LSA-like. None of them is the LSA, and they do not agree on the interface above them.

The authority row is the one that decided Kerberos's fate, and for agents it is empty. Active Directory won because the KDC arrived with the domain, the machine account arrived with the join, and the SPN arrived with the install. Nothing enterprises already run enrolls agents by default and issues their credentials without per-application integration work. The candidates are obvious, and they are competitors: the enterprise IdP, the harness vendor, and the agent provider itself, which is [a claim I have read at least one vendor making explicitly](/notes/agent-provider-is-the-idp-standards-reading-of-workos-auth-md/). Kerberos never had this problem. Active Directory did not have to negotiate for the role of domain controller.

The rollout row is quietly in the best shape, with an important
caveat. HTTP does not give agents SPNEGO. It gives them authentication
challenges: the resource advertises acceptable schemes in
`WWW-Authenticate`, and the client can choose a supported scheme. That
is enough for incremental rollout, but it is not enough by itself for
safe negotiation. Clients still need policy, downgrade protection, and
resource allowlists so "supports bearer" does not silently beat "should
use signed requests here." AAuth's 401-driven flow sits on this
surface. That is the useful part of the NTLM-fallback path that made
Kerberos deployable: bearer tokens where that is all the resource
speaks, signed requests and mediated authorization where both sides
are capable.

## Where AAuth Sits on This Map

AAuth has specified the wire, and specified it well: agent identifiers, requests bound to keys with [HTTP Message Signatures](https://www.rfc-editor.org/rfc/rfc9421), a Person Server mediating consent, and mission context that travels with the request. My earlier posts cover [what the protocol gets right](/notes/mission-architecture-on-aauth/) and [where the mission layer still falls short of portable containment](/notes/aauth-now-has-a-mission-layer/). This post is about a different axis: not whether the protocol is sound, but whether it is positioned the way Kerberos was.

Today it is not. The developer story is "implement signed HTTP
requests with your agent token," softened by
[SDKs for Node, .NET, and Python](https://www.aauth.dev/).
SDKs matter; they are how early adopters survive and how
interfaces get proven. But SDKs are libraries, not a provider
interface. This is pre-SSPI Kerberos: every
application linking the Kerberos libraries directly, holding its own
credentials, handling its own cache. That model converts enthusiasts.
It does not convert ecosystems.

To its credit, the proposal already names the right split. Hosting platforms are expected to handle agent enrollment, per-platform key handling, attestation, and token refresh. That is the LSA's job description, written into a wire spec that is waiting for someone to build the operating system around it. What remains unclaimed is the seam this post opened with: the interface between agent code and that platform layer that lets agent logic written once come out speaking AAuth, MCP-style OAuth, or a plain bearer token, depending on what the resource negotiates.

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:

| Responsibility | Kerberos precedent | Existing piece |
| --- | --- | --- |
| Hold keys, never expose them to agent code | The LSA | SPIFFE Workload API, platform keystores and attestation |
| Acquire, cache, and refresh credentials | TGT and ticket cache | MCP client authorization, standard OAuth token choreography |
| Sign or attach credentials per request | `InitializeSecurityContext` | HTTP Message Signatures implementations |
| Answer challenges, select the mechanism | SPNEGO | `WWW-Authenticate` plus local policy and downgrade protection |
| Enroll the instance, prove the platform | Machine account and domain join | Attestation-based client authentication, client instance assertions |

The missing ingredient is not another agent-authentication scheme. It
is ownership: a harness vendor shipping 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 is the only place where key custody,
mechanism selection, and credential lifecycle can be made invisible to
the developer at the same time.

## The Concepts Already Have Agent Names

The deeper reason the Kerberos analogy is worth taking seriously is that its supporting concepts, the ones that made the authority model work, map one-to-one onto problems the agent identity work is already solving under different names.

**The machine account is the client instance.** A Kerberos machine account belonged to the enrolled host, not to the software running on it, and its keys existed because of the join, not because a developer provisioned them. The agent version of that object is instance identity: [the running instance as an actor, distinct from the client software identity](/notes/client-instances-are-actors-not-new-clients/), which is what the proposed [Client Instance Assertion](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/) draft gives a verifiable form.

**Constrained delegation is the actor chain.** S4U2Proxy moved the delegation decision out of the service and into the KDC: a service could obtain tickets onward only to the targets the directory allowed, and the service's own opinion did not matter. That is delegation decided at issuance and expressed in the credential, which in OAuth terms is [an `act` claim carried consistently across assertion grants and access tokens](/notes/standardize-act-across-assertion-grants-and-jwt-access-tokens/), the shape the proposed [Actor Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/) draft standardizes.

**The PAC is authorization context that travels.** The [Privilege Attribute Certificate](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064-c863-41e1-9c23-edaaa5f36962) 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

Four 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, which were minor for Kerberos, are load-bearing 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 three 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](/notes/aauth-now-has-a-mission-layer/), and no amount of Kerberos nostalgia supplies them.

**HTTP challenges are not SPNEGO.** SPNEGO negotiates mechanisms
inside a security framework. `WWW-Authenticate` advertises schemes and
parameters. That is enough to stage adoption, but it does not create a
trustworthy preference order by itself. The agent platform has to know
when bearer is acceptable, when signed requests are required, 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 authentication challenges are a useful
rollout primitive. Nobody owns the seam that joins them, and nobody
ships the authority.

One distinction keeps the conclusion honest. The harness can plausibly become SSPI. It is already in the call path, already knows which tool is being invoked, and already has a natural place to hide token acquisition and request signing. But the harness is not automatically Active Directory. It can select and hold credentials; it cannot, by itself, decide which agents exist, which humans they represent, which enterprise policies bind them, or which resources trust them. That authority still has to live in an enterprise control plane.

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, 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 authority.** Credential issuance pre-deployed in something enterprises already run, whether that turns out to be the IdP, the harness vendor, or the agent provider.
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 specified the wire and, unusually for a young proposal, named the platform split that layers two and three require. What it cannot do from inside a wire specification is make those layers exist. Kerberos did not become invisible because MIT wrote more RFCs. It became invisible because a platform vendor decided the whole stack was its job.

> 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.