Notifications
Clear all
Topic starter
18/08/2026 2:42 pm
TL;DR: Bearer tokens and session-scoped API keys break down when the principal is an autonomous agent, because they create ambient authority and weak auditability across tool calls, according to Stacklok. The practical answer is workload identity plus relationship-based authorization, with per-request enforcement that proves who acted, what they touched, and under which policy.
NHIMG editorial — based on content published by Stacklok: Agentic Identity Explained: How to Apply SPIFFE and Relationship-Based Authorization to AI Agents in 2026
Questions worth separating out
Q: How should security teams govern AI agents that call internal tools from Kubernetes?
A: They should separate runtime containment from identity governance.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Stacklok's guide to SPIFFE and relationship-based authorization for AI agents →
AI agent identity architecture: are bearer tokens enough?
Explore further
18/08/2026 3:25 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SPIFFE and relationship-based authorization for AI agents
