Kane Narraway, in a June 2026 LinkedIn note on Anthropic's Zero Trust for AI Agents whitepaper:
Anthropic released their Zero Trust for AI agents guide last week. Overall a good read, especially on the identity side. Pushes more towards the SPIFFE architecture with dedicated agent identities and not using API keys or OAuth as mentioned last week.
And then the pragmatic caveat a few sentences later:
A lot of smaller orgs will probably struggle implementing SPIFFE-like designs, and will just fall back to long lived API tokens everywhere.
Both observations are correct. SPIFFE is the right substrate for workload identity, including AI agents. Long-lived API tokens are what most teams will actually use this quarter. The interesting question is what the governance layer above either looks like, and whether the team running on OAuth tokens has to wait for a SPIFFE migration before they can govern agents seriously.
This post is about the two-layer architecture: SPIFFE (or its equivalent) at the substrate, intent-bound governance at the runtime above it. And about what the runtime layer does when the substrate isn't ideal.
What SPIFFE actually solves
Workload identity. Each process, container, function, or agent gets a cryptographically rooted identifier. The identifier (a SPIFFE ID) takes the form spiffe://trust-domain.example.com/payment-service or spiffe://trust-domain.example.com/claude-code-agent/instance-42. The identifier is delivered through an SVID (SPIFFE Verifiable Identity Document), which is typically an X.509 certificate or a JWT, signed by a trust authority that runs in the same environment.
The reason this matters for AI agents: the alternative is API keys and OAuth client credentials, both of which are bearer tokens. A bearer token in a config file is exfiltratable. A bearer token in memory survives a process restart. Anthropic puts the problem bluntly: static API keys "are among the first things an attacker with model-assisted code analysis will find."
SPIFFE's contribution is that the SVID is bound to attested workload attributes (the host's identity, the container's identity, the process's identity) and not to a long-lived secret. If you steal the file the token is in, you can't replay it from a different host because the host's identity won't match. If you compromise the host, you can use the credential but only from that host, and the runtime can detect the anomaly faster because the credential's scope is tighter.
This is what makes SPIFFE the right ceiling for workload identity. It's also what makes it hard to deploy.
What SPIFFE doesn't solve
Authorization at the action level.
A SPIFFE-issued credential tells the receiving service that the workload is who it claims to be. It doesn't tell the service whether the action the workload is currently taking is appropriate for the task it was invoked to do.
Two examples.
A Claude Code agent has a SPIFFE ID. The IdP issues it a scoped token. The session opens for the declared task "analyze retry patterns in the payments service." The agent's SPIFFE-verified identity is correct. The credential is appropriate. Mid-session, the agent attempts to export the customer transactions table. The credential check passes (the agent has read on the database; the database accepts SPIFFE-verified workloads from this domain). The action is wildly outside the declared intent.
SPIFFE didn't catch this. SPIFFE can't catch this. The verification SPIFFE performs is about identity, not about whether the verified identity should be doing this thing right now.
A second example. Sub-agent B has a SPIFFE ID. The orchestrator passes it an instruction that originated as a prompt injection upstream. Sub-agent B executes the instruction. The audit log shows: spiffe://example/sub-agent-b performed action X with valid credentials. Everything looks clean. The action was nevertheless not what the originating user asked for.
The first case is intent drift mid-session. The second case is confused deputy. Both are authorization-layer problems, not identity-layer problems. SPIFFE is necessary for both (without verified identity the rest can't work) but not sufficient.
The two-layer architecture
The working version is straightforward. The substrate is SPIFFE; the runtime is intent.
The substrate layer.
- Each agent gets a SPIFFE ID bound to attested workload identity. Hardware-rooted where the deployment supports it (TPMs, confidential computing); container-rooted where the deployment is Kubernetes-style.
- The SPIFFE ID is the canonical identifier in audit logs, IAM policies, and federation flows.
- The IdP federates this identity to SaaS providers using OAuth extensions (Cross-App Access, ID-JAG) where the SaaS supports it. Where it doesn't, the IdP issues short-lived scoped credentials directly.
The runtime layer.
- Each session opens with a declared intent.
- The session's actions are evaluated against intent. Mismatches block or escalate.
- The audit log captures the SPIFFE-verified identity, the session intent, and the alignment of each action.
- Sub-agents inherit a constrained slice of the parent's intent, not the full envelope. Cross-agent instructions are evaluated against the originating intent, not just against the immediate caller's authority.
Both layers compose. The substrate makes identity hard to forge. The runtime makes credentialed identities hard to misuse.
The fallback when SPIFFE isn't ready
This is where Kane's caveat hits. Most teams won't ship SPIFFE this quarter. The honest deployment cost (SPIRE server, attestors per workload type, runtime integration) is real. For a team without a platform engineer, it's the kind of project that gets postponed.
The fallback is intent-bound governance above whatever credential layer you do have. OAuth client credentials, STS-style brokering, even shared service tokens in the worst case. The credential is weaker; the runtime layer compensates partially.
What the runtime layer can do with weaker substrate:
- Bind each session to an intent. Even if the credential is shared or long-lived, the session is short-lived and scoped.
- Evaluate each action against the session's intent. Even if the credential could authorize a wide envelope, the runtime narrows the effective scope to the declared task.
- Capture an audit chain that includes the human triggering the session, the credential used, and the intent-alignment outcome. The chain compensates partially for the credential's weakness by making misuse legible.
What it can't do:
- Prevent credential exfiltration from a compromised host. If the bearer token leaks, it leaks.
- Distinguish a legitimate session from a session opened by a stolen credential. The intent declaration is what the attacker would also do; the alignment check catches subsequent misuse but not the initial impersonation.
- Survive a fundamentally weak substrate indefinitely. A team running on shared API tokens for production agents is one model-assisted attacker away from a serious incident regardless of the runtime layer.
The fallback is a real defense. It's also not the answer to "we don't need SPIFFE." The honest framing is: ship intent-bound governance now, plan the SPIFFE migration over the next twelve months, and run the practical version in the meantime.
What this changes for your roadmap
The substrate decision and the runtime decision are separate. Most teams treat them as one project ("we need to figure out agent identity") and the project doesn't ship.
Split them.
The substrate question is an infrastructure roadmap item. SPIFFE is the right target if you're cloud-native; alternatives (CA-based PKI for traditional environments, managed identity for hybrid) are options. The work is real and worth doing. The timeline is quarters, not weeks.
The runtime question is a governance roadmap item. Intent-bound sessions, per-action evaluation, audit chains. This work can ship above whatever credential layer is in production today. The timeline is weeks, not quarters.
Don't wait. The substrate matters; the runtime matters more for what an attacker actually does once they have a credential. Ship the runtime layer above the credentials you have. Migrate the substrate underneath when the work is right.
Kane's pragmatic caveat is the spirit of the right answer. The architecture target is both layers. The reality of next quarter is the runtime layer above whatever substrate you can actually ship. Iden's role is consistent across both: governance above the identity layer, regardless of how cryptographically strong the layer underneath is.