Agentic Identity Explained: How to Apply SPIFFE and Relationship-Based Authorization to AI Agents in 2026
The question that keeps coming up in enterprise AI architecture reviews is not, “which LLM should we use?” It is, “How do we know what our agents are allowed to do, prove it at runtime, and audit it after the fact?”
That question does not have a clean answer yet. Bearer tokens, the mechanism most teams reach for first, were designed for human-initiated sessions. They break in specific and dangerous ways when the principal is an autonomous agent. SPIFFE, the Secure Production Identity Framework For Everyone offers the right architectural primitives. This post explains why bearer tokens fail for agentic workloads, what a correct identity and authorization architecture looks like, and how enterprise MCP platforms fit into that stack today.
Stacklok’s CTO, Joe Beda, is a co-author of the SPIFFE specification and a co-creator of Kubernetes. The architecture described here reflects the design thinking of the people who built the standards this problem requires.
Why This Problem Is Showing Up in Enterprise Architecture Reviews Now
Financial services firms, payment processors, and regulated fintechs are not evaluating agentic AI as a future possibility. They are running it in production or in late-stage pilots. The identity and authorization problem is a blocker for these organizations.
The pattern reported across enterprise architecture reviews follows a consistent arc. A team deploys an AI agent that can query databases, call internal APIs, and invoke tools via MCP servers. The agent works. Then someone asks: “What identity did that agent use when it accessed the payments database? Was that access authorized under our access control policy? Can you show me the audit record?” In most current deployments, the honest answer is: not fully, not precisely, and not in a form your compliance team will accept.
That gap is the problem this post addresses.
Why Bearer Tokens Break for Autonomous Agents
Bearer tokens (OAuth 2.0 access tokens, API keys, JWT tokens issued at session start) are the dominant credential mechanism in web infrastructure. They work well when a human initiates a session, authenticates once, and performs a bounded set of actions within a short window. The token represents “this human authenticated and is allowed to do these things until this expiry.”
Autonomous agents violate every assumption in that model.
The Ambient Authority Problem
A bearer token carries authority that is independent of context. If an agent holds a token scoped to “read from the payments database,” that token authorizes any read from the payments database regardless of which task the agent is currently executing, which user request triggered the agent, or whether reading from the payments database is appropriate for the current reasoning step.
When an agent operates across multiple tasks, tool calls, and sub-agent delegations within a single session, a single bearer token creates ambient authority: the agent can do anything the token permits, at any point, for any reason. The token does not encode “this specific tool call, triggered by this specific user request, authorized by this specific policy evaluation.” It encodes “this agent authenticated at time T and has these permissions until time T+n.”
The Delegation Chain Problem
Multi-agent architectures compound the bearer token problem. When a root agent spawns a sub-agent to handle a specific task, and that sub-agent needs to access a resource, what credential does it use? Three patterns emerge in practice, and all three are problematic.
The first pattern: the root agent passes its own token to the sub-agent. The sub-agent now holds full ambient authority; there is no scoping to the delegated task, and the audit log shows the root agent’s identity for actions the sub-agent took.
The second pattern: the sub-agent is provisioned with its own static credential. That credential is stored somewhere (an environment variable, a secrets manager entry, an MCP server configuration). Static credentials that live in configuration are a persistent supply chain risk, and their lifecycle is typically managed by humans on a quarterly rotation cycle, not by the runtime on a per-task basis.
The third pattern: there is no sub-agent credential at all, and the sub-agent calls the resource unauthenticated or through a shared service account. This is the pattern that generates the compliance finding.
The Audit Incoherence Problem
Compliance frameworks in financial services require the ability to answer: “At time T, which authorized principal took action A on resource R, under which policy, and what was the business justification?” Bearer tokens issued at session start cannot answer this question at the tool-call level. The audit record shows “agent session S accessed resource R” not “this specific MCP tool invocation, triggered by this user request, authorized under this policy evaluation.”
For regulated enterprises, audit incoherence is not a technical inconvenience. It is a control failure.
What SPIFFE Provides and Why It Matters for Agents
SPIFFE (the Secure Production Identity Framework For Everyone) is an open standard for workload identity. It defines a way to issue cryptographically verifiable identities to software workloads based on their provenance and runtime context, without requiring a human to provision credentials manually.
The core construct in SPIFFE is the SPIFFE Verifiable Identity Document (SVID). An SVID is a short-lived, cryptographically signed credential that asserts: “This workload, running in this context, with this verified provenance, has this identity.” SVIDs are issued by a SPIFFE-compliant trust domain (typically implemented via SPIRE, the SPIFFE Runtime Environment) and rotate automatically throughout the workload’s lifetime.
Why SPIFFE Is the Right Identity Primitive for Agents
SPIFFE solves the provisioning problem that makes static credentials dangerous. There are no long-lived API keys to rotate, store, or leak. The identity is bound to the workload’s runtime attestation. An agent that was not started by an authorized orchestrator cannot obtain a valid SVID, regardless of whether it has access to the configuration files or secrets manager entries that a static credential model would require.
For multi-agent architectures, SPIFFE enables scoped delegation. Each agent in a delegation chain can hold its own SVID, scoped to its specific role in the workflow. The audit record can show the full delegation chain: root agent identity, sub-agent identity, the resource accessed, and the SPIFFE trust domain that issued each identity. This is the audit coherence that compliance frameworks require.
SPIFFE does not solve the authorization problem on its own. SPIFFE answers “who is this workload and is its identity verifiable.” It does not answer “given this verified identity, is this specific action on this specific resource permitted in this specific context.”
Why Relationship-Based Authorization Fits Agentic Workloads
Agentic workloads create authorization questions that flat RBAC models cannot express cleanly. Consider the question: “Is this sub-agent permitted to read from the customer transaction database, given that it was delegated by a root agent acting on behalf of user U, who has read access to their own transaction records but not to other customers’ records?”
That question requires evaluating a chain of relationships: user U’s permissions, the scope of the delegation from root agent to sub-agent, the relationship between the sub-agent’s current task and the resource being accessed, and the contextual constraint (own records only). A flat role assignment cannot encode all of these conditions simultaneously.
The Complete Architecture: SPIFFE + MCP Platform
A complete agentic identity and authorization architecture requires three layers working together.
Layer 1: Workload Identity (SPIFFE/SPIRE)
Every agent, every MCP server, and every orchestration component holds a SPIFFE SVID issued by a trust domain operated by the enterprise. SVIDs rotate automatically. No static credentials are stored in configuration. The identity of every workload in the system is cryptographically verifiable and bound to runtime attestation.
This layer answers: “Who is this workload, and can I verify that claim?”
Layer 2: Relationship-Based Authorization (OpenFGA or SpiceDB)
The authorization system maintains a relationship graph encoding: which users have which permissions on which resources, which agents are permitted to act on behalf of which users, what delegation constraints apply to each agent-to-sub-agent relationship, and what contextual conditions (data classification, time window, regulatory scope) apply to each permission.
Every tool call by an agent generates an authorization check: the agent’s SVID-derived identity, the resource being accessed, the permission type, and the delegation context are submitted to the authorization system, which evaluates the relationship graph and returns permit or deny with a full audit-ready traversal record.
This layer answers: “Given this verified identity and this context, is this specific action permitted?”
Layer 3: MCP Platform Enforcement (Stacklok)
The identity and authorization layers define the model. The MCP platform is where enforcement happens at runtime for agent tool calls. Every MCP server invocation passes through the platform’s gateway. The gateway validates the requesting agent’s identity, submits the authorization check, enforces the result, and emits the audit record — before the tool call reaches the MCP server.
This layer answers: “Is this specific MCP tool invocation, from this verified agent identity, authorized under the current policy — and is the result logged in a form the compliance team can use?”
Where Stacklok Fits in Today
Stacklok is an enterprise MCP platform built on ToolHive, the most widely adopted open-source MCP platform (Apache 2.0 licensed). Stacklok’s current architecture enforces per-request identity at the MCP gateway layer using OIDC and OAuth 2.0, with native integrations for Okta, Microsoft Entra ID, and Google Workspace.
In the three-layer architecture described above, Stacklok occupies Layer 3 and enforces the identity model established by whatever identity provider sits in Layer 1. For enterprises already operating SPIRE or an OIDC-compliant IdP, Stacklok’s vMCP gateway validates the identity token on every MCP tool call, applies the configured authorization policy, and emits an OpenTelemetry audit record tied to the resolved identity.
Native SPIFFE/SVID integration is on Stacklok’s roadmap. When that integration ships, Stacklok will be able to receive SVID-attested workload identities directly from SPIRE, without requiring an OIDC bridge. The architectural direction reflects Stacklok CTO Joe Beda’s authorship of the SPIFFE specification: the platform is being built toward the identity model that Beda and his co-authors defined as the correct primitive for workload identity.
What Stacklok Enforces at the MCP Layer Today
Per-request identity resolution: Every MCP tool call carries an identity token. Stacklok validates that token against the configured IdP on every request. There is no session-level ambient authority; each tool invocation is independently authorized.
Container isolation per MCP server: Every MCP server runs in an isolated container with minimal permissions. Network access and filesystem scope are configurable via JSON profiles. A compromised or misbehaving MCP server cannot access the credentials or session context of other servers running in the same deployment.
OpenTelemetry audit records: Every tool call generates an OTel trace that includes the resolved agent identity, the MCP server invoked, the tool called, the parameters passed, and the authorization result. These traces integrate with Grafana, Datadog, Splunk, New Relic, and Honeycomb without custom instrumentation.
Policy enforcement via vMCP: The virtualized MCP gateway (vMCP) applies configured access policies before tool calls reach MCP servers. Policy can be scoped per agent identity, per team, per MCP server, or per tool.
Supply chain attestation: Stacklok provides provenance attestation and server signing for every MCP server in the registry. Enterprises can verify the integrity of every tool their agents can invoke. This is the supply chain layer of agent security that identity frameworks alone do not address.
A Reference Architecture for Regulated Enterprises
For a financial services or fintech organization that needs to deploy AI agents in compliance with audit and access control requirements, a production-ready reference architecture as of mid-2026 looks like this:
Identity layer: SPIRE deployed as the enterprise workload identity authority. Every agent container and MCP server container receives an SVID on startup via SPIRE’s attestation API. SVIDs rotate every hour. No static credentials in configuration.
Authorization layer: OpenFGA deployed as the relationship-based authorization service. The relationship graph encodes user permissions, agent delegation chains, and resource access policies. Every MCP tool call triggers an authorization check via the OpenFGA API before the call is forwarded.
MCP enforcement layer: Stacklok deployed as a Kubernetes Operator. The vMCP gateway intercepts every MCP tool invocation, validates the identity token (OIDC today, SVID natively when available), forwards the authorization check to OpenFGA, enforces the result, and emits the OTel audit record to the enterprise’s existing observability stack.
Observability: OpenTelemetry traces from Stacklok feed into the existing SIEM (Splunk, Datadog, or New Relic). The audit record for every agent action includes: timestamp, agent identity (resolved from SVID or OIDC token), MCP server, tool, parameters, authorization decision, and the OpenFGA relationship traversal path that produced the decision.
This architecture produces a complete answer to the compliance question: “At time T, which authorized agent took action A on resource R, under which policy, and what was the authorization chain?” Every component in this stack is open source. No SaaS dependency is required for any layer.
Which Architecture Should You Implement?
Your agents are in early production and you need per-request identity now, without a SPIRE deployment. Stacklok’s OIDC/OAuth model with Okta or Entra ID integration is production-ready today. Every MCP tool call carries a validated identity token, and audit records are emitted via OpenTelemetry. This is the right starting point for most enterprises and can be extended to full SPIFFE integration as the deployment matures.
Your security team requires workload-attested identity. Deploy SPIRE alongside Stacklok. SPIRE handles SVID issuance and rotation; Stacklok validates the identity at the MCP enforcement layer. This combination closes the “how do we know this is the right agent binary running in the right context” question that OIDC alone cannot answer.
Your compliance framework requires delegation chain auditability for multi-agent workflows. Add OpenFGA or SpiceDB as the authorization layer between SPIRE and Stacklok. The relationship graph encodes your access control model; the authorization check runs per tool invocation; the traversal path is the audit record. This is the complete architecture for regulated financial services and healthcare environments.
You are in a greenfield deployment and want to build the right architecture from the start. Start with Stacklok’s OIDC model, deploy SPIRE for workload attestation, and design your authorization model in OpenFGA before agent workloads scale. Retrofitting relationship-based authorization onto a flat RBAC model at scale is significantly more expensive than modeling it correctly from the start.
Frequently Asked Questions
Q: What is SPIFFE and why does it matter for AI agents?
SPIFFE (Secure Production Identity Framework For Everyone) is an open standard for issuing cryptographically verifiable identities to software workloads based on their runtime provenance. For AI agents, SPIFFE eliminates static credentials by binding agent identity to what the workload is and where it is running.
Q: Does Stacklok support SPIFFE today?
Stacklok’s current production architecture uses OIDC and OAuth 2.0 for per-request identity, with native integrations for Okta, Microsoft Entra ID, and Google Workspace. Native SPIFFE/SVID integration is on Stacklok’s roadmap. Stacklok CTO Joe Beda is a co-author of the SPIFFE specification, and the platform’s identity architecture is being built toward full SPIFFE support.
Q: Why is a per-request identity model important for MCP tool calls specifically?
MCP tool calls are the action surface where agents interact with real systems, including databases, APIs, internal services. A session-scoped bearer token grants ambient authority across all tool calls in the session, with no per-call authorization check. Per-request identity means every tool invocation carries an independently validated identity, enabling tool-level audit records and preventing an agent from using a valid session token to perform actions outside its current task scope.
June 03, 2026