SPIFFE and relationship-based authorization for AI agents

At a glance

What this is: This is a how-to analysis of agentic identity architecture, and its key finding is that bearer tokens do not provide safe or audit-ready control for autonomous AI agents.

Why it matters: It matters because IAM, PAM, and NHI programmes need a runtime model for AI agents that can prove identity, constrain tool use, and preserve audit evidence.

👉 Read Stacklok's guide to SPIFFE and relationship-based authorization for AI agents

Context

AI agent identity is the control problem, not the model choice. When an agent can query databases, call APIs, and invoke tools on its own, a session token no longer answers the core governance questions of who acted, what was allowed, and whether the action can be defended later.

The identity gap shows up most clearly in delegated and multi-agent workflows, where a root agent, sub-agents, MCP servers, and backend services all participate in one task chain. Existing IAM patterns were built for human-paced sessions, while agentic workflows need per-request identity, delegation scoping, and auditable policy checks at runtime.

For enterprises in regulated sectors, the issue is not theoretical architecture. It is whether the access control model can survive compliance scrutiny when an AI agent reaches into a sensitive system through an MCP tool call and leaves behind evidence a human reviewer can trust.

Key questions

Q: How should security teams govern AI agents that call internal tools from Kubernetes?

A: They should separate runtime containment from identity governance. Kubernetes can isolate execution, but the tool boundary still needs delegated identity, per-request authorization, and action-level logging. Without those controls, the agent behaves like an unscoped service account with model-driven output, which makes attribution and revocation much harder.

Q: Why do bearer tokens create governance risk in API-driven workflows?

A: Bearer tokens confer access to whoever holds them, so the token itself becomes the credential. That means exposure in code, logs, pipelines, or SDK caches can create immediate misuse potential unless the API validates expiry, audience, and signature consistently and the organisation can revoke access quickly.

Q: What is the difference between workload identity and authorization for AI systems?

A: Workload identity proves what the AI system is, while authorization decides what it can do. A strong identity without tight authorization still allows overreach, and tight authorization without reliable identity cannot safely distinguish one workload from another. Effective AI governance needs both controls working together.

Q: How can organisations audit multi-agent access without losing the delegation chain?

A: They need logs that preserve the root agent, sub-agent, resource, policy decision, and contextual constraint for each invocation. If the audit record collapses the chain into one session or one shared account, the organisation loses the evidence required to explain why the action was allowed.

Technical breakdown

Why bearer tokens create ambient authority for AI agents

Bearer tokens, OAuth access tokens, API keys, and JWTs all assume a bounded session that begins with human intent and ends before privilege drifts too far. Autonomous agents break that assumption because they can keep acting across multiple tool calls, tasks, and delegation hops while the same token remains valid. That creates ambient authority, where the token authorises any permitted action regardless of current context. The result is a credential that is technically valid but governance-poor, because it cannot express task scope or tool-level justification.

Practical implication: Treat session-scoped bearer tokens as insufficient for agent tool access and move toward per-request identity and authorisation.

How SPIFFE changes workload identity for agentic systems

SPIFFE provides workload identity rather than human login identity. Its SVIDs are short-lived, cryptographically verifiable credentials bound to runtime attestation, which means the agent identity is tied to the workload instance and not to a static secret stored in configuration. That matters for AI agents because it removes long-lived API keys from the control plane and gives each workload a verifiable identity that can rotate automatically. In a multi-agent design, every agent and MCP server can carry its own identity rather than sharing one credential.

Practical implication: Use workload-attested identity as the base layer for agent security instead of distributing static credentials across containers and tools.

Why relationship-based authorization fits delegated agent workflows

Flat RBAC struggles when a resource decision depends on the user, the root agent, the sub-agent, the task, and the data domain all at once. Relationship-based authorization models such as OpenFGA or SpiceDB can represent those links directly, so policy can evaluate who delegated what, on whose behalf, and under which contextual limits. That produces a traversal record that supports audit and compliance review instead of a coarse allow or deny. For regulated tool use, the policy graph becomes part of the evidence trail, not just a hidden control layer.

Practical implication: Model agent delegation and resource access as relationships, not only roles, if you need defensible authorisation at tool-call level.

Threat narrative

Attacker objective: The objective is to gain broad, hard-to-audit access through an identity model that was never built for autonomous runtime behaviour.

1. Entry occurs when a bearer token, API key, or shared session credential is reused for an AI agent that was never designed to hold ambient authority across multiple tool calls.
2. Escalation occurs when the agent or sub-agent reuses that credential across delegated tasks, allowing access that is broader than the original request context.
3. Impact occurs when the resulting access cannot be tied cleanly to a specific authorised tool invocation, leaving regulated systems with weak audit evidence and unbounded action scope.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Bare bearer tokens are the wrong trust primitive for autonomous agents: They were designed for sessions that begin with human intent and stay inside a bounded request path. Agentic workflows break that assumption because the same credential can survive across task changes, tool calls, and delegation hops. The implication is that access control for agents has to start from workload identity and per-request authorisation, not from a human-session model retrofitted onto software actors.

Identity does not equal authorisation, and SPIFFE proves why that distinction matters: A verifiable workload identity answers who the agent is at runtime, but it does not by itself answer what the agent may do. That separation is useful because the identity layer and the policy layer can fail independently, which is exactly what regulated enterprises need when audit evidence must survive scrutiny. Practitioners should read this as proof that agent security is an identity stack, not a single control.

Relationship-based authorization is the first model that can describe delegated AI work without flattening context: When a root agent, sub-agent, user, and data resource all influence one decision, roles alone lose too much meaning. A graph-based policy can preserve delegation scope, task ownership, and resource boundaries in a way that auditors can reconstruct later. That is the practical difference between a system that authorises tools and a system that merely permits access.

Named concept: ambient authority debt: Every session token or static credential that remains valid while an agent continues to reason, branch, or delegate creates security exposure that the original policy never reviewed. This debt grows because the access decision was made once, but the agent keeps changing what that access is used for. Practitioners need to recognise this as a governance problem, not just a credential hygiene problem.

Agentic MCP architectures will force IAM teams to redesign evidence, not just enforcement: The control question is no longer only whether a tool call was blocked or allowed. It is whether the organisation can reconstruct which identity made the request, which policy evaluated it, and which delegation chain justified it. That shifts agent security from a point control mindset to a lifecycle and evidence model across IAM, PAM, and NHI governance.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap becomes more dangerous as OWASP Agentic AI Top 10 threat categories move from theory into production workloads.

What this signals

Ambient authority debt: Enterprise teams should expect agent identity controls to move from session-centric validation to request-level proof of purpose. Once agents can branch across tools and sub-agents, the security model has to preserve the delegation chain instead of compressing it into one login event.

The practical signal for IAM and NHI teams is that auditability now depends on runtime identity evidence, not just authentication success. That is why workload identity, policy traversal logs, and resource-scoped enforcement will become baseline design requirements rather than advanced hardening measures.

For teams mapping their programme to external guidance, the control shape aligns closely with the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026, both of which treat runtime behaviour and governance evidence as first-class concerns.

For practitioners

• Replace session-scoped trust with per-request identity Validate every MCP tool call independently so the policy engine sees the current agent identity, not a session token that can be reused across unrelated actions.
• Introduce workload-attested identity for agents and MCP servers Use SPIFFE or an equivalent workload identity model so each agent instance proves its runtime provenance before it can obtain usable credentials.
• Model delegation as relationships, not just roles Represent user-to-agent, agent-to-sub-agent, and agent-to-resource links in a relationship graph so the policy engine can enforce task scope and ownership.
• Require audit records at the tool-call layer Capture the resolved identity, tool name, parameters, and authorisation result for every invocation so compliance teams can reconstruct the full action chain.
• Isolate MCP servers and remove static credentials from configuration Run each server in a constrained container, block credential sharing between components, and eliminate API keys that persist longer than the workload itself.

Key takeaways

• Agentic AI breaks the trust assumptions behind bearer tokens, because tokens are not designed to carry safe, auditable authority across changing tasks.
• Workload identity plus relationship-based authorization gives enterprises a defensible model for proving who acted, what was allowed, and why.
• The governance problem is no longer just credential hygiene. It is preserving identity evidence and delegation scope across every agent tool call.

Key terms

• Ambient authority: Access that exists because the surrounding environment already has permissions, rather than because the actor was explicitly granted them. In swarm systems, ambient authority hides who is truly acting and makes revocation, attribution, and containment much harder.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Relationship-Based Access: An access model where entitlements are justified by the current business relationship, such as employee, contractor, student, vendor, or service account status. In practice, the relationship defines scope, duration, ownership, and review requirements.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.

What's in the full article

Stacklok's full how-to covers the operational detail this post intentionally leaves for the source:

• Reference architecture examples for pairing SPIFFE, OpenFGA or SpiceDB, and an MCP enforcement layer in regulated environments
• Per-layer implementation details for workload identity, delegation policy, and audit logging across agent and server components
• Operational guidance on when to start with OIDC today and when to move toward SPIFFE-attested workload identity
• Container and gateway design choices for enforcing per-request authorisation before tool calls reach MCP servers

👉 Stacklok's full how-to covers the runtime architecture, audit model, and deployment choices for regulated AI agents.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or maturing your programme, it is worth exploring.