IAM, Agent: Identity for Autonomous AI - Matthew Bates, Cofide

IAM, Agent: Identity for Autonomous AI

Speakers: Matthew Bates, Founder, Cofide

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=CvGbwn5ZrFg

Overview

In this insightful talk from KubeCon EU, Matthew Bates, a founder at Cofide, delved into the critical and rapidly evolving domain of Identity and Access Management (IAM) for autonomous AI agents. As AI capabilities move beyond simple conversational models to sophisticated, decision-making agents, the security landscape transforms dramatically. Bates highlighted the inherent risks of traditional security practices when applied to these new AI paradigms and proposed a robust framework leveraging existing Cloud Native Computing Foundation (CNCF) projects and emerging industry standards to secure them effectively.

The core of Bates's presentation centered on the unique challenges posed by AI agents, which, unlike conventional applications, possess autonomy, memory, and the ability to interact with external tools and systems. This increased agency necessitates a paradigm shift in how we manage their identities and authorize their actions. The talk underscored the importance of applying Zero Trust principles to AI agents, treating them as privileged workloads that require stringent authentication and fine-grained authorization, rather than implicitly trusting their actions.

This article will explore the architectural considerations, security pitfalls, and practical solutions presented by Bates, offering a detailed technical examination of how to build secure, production-ready AI agent systems. By drawing parallels to existing workload identity solutions like SPIFFE/Spire and introducing cutting-edge concepts like OAUTH Transaction Tokens, Bates provided a compelling vision for securing the next generation of intelligent systems, emphasizing the need for open standards and community collaboration in this fast-paced field.

Background

▶ Watch: Introduction to IAM for AI Agents (0:00)

The rapid advancements in Generative AI have led to a significant evolution in how software interacts with users and systems. Initially, much of the focus was on conversational AI, where Large Language Models (LLMs) engaged in turn-based dialogue, responding to user prompts with text or other media. While powerful, these interactions were largely reactive and lacked true autonomy.

The emergence of AI agents represents a fundamental shift. As Bates explained, an AI agent is characterized by its autonomy, decision-making, and reasoning capabilities. Unlike a simple chatbot, an agent can understand a complex task, reason about the necessary steps, access its memory, and utilize a suite of "tools" to achieve its goal. This allows agents to perform labor-intensive tasks and interact with the environment in ways previously only possible for humans or highly specialized, pre-programmed systems.

Anthropic's "Building Effective Agents" paper, referenced by Bates, describes agents as "augmented LLMs." This augmentation comes in several forms:

• Retrieval Augmented Generation (RAG): Agents can access and integrate information from external knowledge bases (e.g., internal corporate wikis, domain-specific documents) to complement their trained LLM knowledge, ensuring responses are current and contextually relevant.
• Memory: Agents can retain context from ongoing conversations or past interactions, improving coherence and efficiency by reducing token usage and allowing for more complex, multi-step tasks.
• Tools (or Functions): This is perhaps the most transformative aspect. Agents can be equipped with access to external APIs, databases, and other systems. The LLM can reason about when to invoke these tools, interpret their results, and integrate them into the overall workflow to achieve the user's objective. Examples include querying an orders database, interacting with a CRM system, or even triggering actions in other applications. The MCP (Model-Client Protocol) championed by Anthropic is one such open standard facilitating this tool integration.

While these capabilities unlock immense potential, they also introduce unprecedented security challenges. Bates illustrated this by describing a simple, "vibe coded" customer service chatbot he built using Langraph (a graph-based agent framework from the Langchain project) and Vertex AI with the Gemini Flash model. This agent was designed to access an "orders database" via APIs to check order statuses. Building such a prototype quickly exposes the inherent security risks: how do we ensure the agent is authenticated, that its access to tools is authorized, and that it acts on behalf of the user with appropriate permissions, rather than having broad, unfettered access to sensitive data? These questions form the core of the problem Bates sought to address.

Key Findings

▶ Watch: Augmented LLM: Retrieval and Memory for Agents (3:20)

Matthew Bates's talk identified several critical findings regarding the security of autonomous AI agents:

1. Traditional IAM Fails for Autonomous Agents: The conventional approach of using long-lived API keys or service account tokens for LLM access and granting broad permissions to backend systems is fundamentally insecure for AI agents. These agents have decision-making capabilities and can potentially be prompted to misuse or exfiltrate data if over-privileged.
2. Workload Identity is Paramount: Each component in an AI agent architecture—the agent itself, its tools (APIs, databases), and the LLM provider—must have a cryptographically verifiable, short-lived identity. This shifts trust from static, easily compromised credentials to dynamic, attested identities.
3. Existing CNCF Standards Provide a Foundation: Projects like SPIFFE (Secure Production Identity Framework For Everyone) and its reference implementation, Spire, are highly effective in providing robust workload identity. They enable service-to-service trust, eliminate long-lived tokens, and allow for fine-grained authorization based on attested identities. Bates demonstrated how Spire can integrate with hyperscalers via OIDC to secure LLM access.
4. User Context Attenuation is Essential but Challenging: Propagating a user's original, full-privilege JWT through an agent system is risky due to potential token replay and over-privileging the agent. A mechanism is needed to "attenuate" user permissions, creating a new, short-lived token that specifically reflects the user's intent for a given request, rather than their full access rights.
5. Emerging Standards Address Attenuation Gaps: The IETF's OAUTH Transaction Tokens (OTrTT) initiative, though still in draft, offers a promising solution for encapsulating user and request context into an attenuated, signed token. This allows for precise authorization decisions downstream without exposing the original, high-privilege user token to the agent.
6. Zero Trust Principles are Non-Negotiable: Securing AI agents demands a strict adherence to Zero Trust principles, combining both workload identity and attenuated user context to make fine-grained, policy-based authorization decisions at every step of an agent's interaction with internal systems.

Technical Deep Dive

▶ Watch: LLMs now equipped with tools, APIs, and databases (4:20)

The core of Bates's presentation revolved around addressing the significant security vulnerabilities inherent in early AI agent deployments, particularly concerning identity and access management. He meticulously laid out the problems and then demonstrated how existing and emerging standards offer viable solutions.

The Problem: Implicit Trust and Over-Privilege

Initially, building an AI agent, as Bates illustrated with his "vibe coded" prototype, often involves several critical security oversights:

1. Long-Lived LLM Tokens: Access to LLM providers (e.g., Google's Vertex AI) typically relies on long-lived API keys or service account tokens. If these tokens are compromised, an attacker gains unrestricted access to the LLM, potentially leading to abuse or data exfiltration.
2. Unauthenticated/Unauthorized Tool Access: Many prototype agents grant tools (e.g., APIs for an orders database) open access or use weak, static credentials. This means the agent, or a malicious actor exploiting it, could access the entire database, violating the principle of least privilege.
3. Lack of Agent Identity: The agent itself often lacks a distinct, verifiable identity. Without this, it's impossible to audit its actions or apply fine-grained authorization policies to its interactions with tools.
4. User Context Propagation Risks: When a user interacts with an agent, their identity (e.g., via a JWT from an OIDC provider like Dex) needs to be considered. Simply propagating the user's raw JWT through the system is dangerous. It exposes a high-privilege token to the agent and downstream systems, creating risks of token replay attacks and allowing the agent to potentially act with more privilege than intended for a specific request. Bates noted that in his early examples, an agent with full access could easily be prompted to reveal all customer orders, not just the requesting user's.

Solution 1: Workload Identity with SPIFFE/Spire

To address the service-to-service trust and long-lived token issues, Bates advocated for SPIFFE (Secure Production Identity Framework For Everyone) and its reference implementation, Spire. SPIFFE is a graduated CNCF project providing standards and APIs for issuing and validating cryptographically verifiable identities to software workloads.

Here's how SPIFFE/Spire fundamentally changes the security posture:

• Server-Agent Architecture: Spire operates with a server and agents. A Spire Agent runs on each node (e.g., in a Kubernetes cluster), and a Spire Server manages the overall trust.
• Attestation: Instead of static credentials, Spire uses an attestation process. The agent, running out-of-band, proves the workload's provenance (e.g., by verifying its Kubernetes API registration, container image signature, or other contextual attributes). This proof is validated by the Spire Server.
• Short-Lived Identities: If attestation is successful, the Spire Server issues a SPIFFE Verifiable Identity Document (SVID) to the workload. These SVIDs are short-lived (e.g., minutes or hours) and automatically rotated, eliminating the risk of long-lived tokens. SVIDs can be either X.509 SVIDs (for mTLS connections) or JWT SVIDs (for conveying identity as a credential).
• SPIFFE ID: Each SVID contains a unique SPIFFE ID, a URI that cryptographically encodes the workload's identity (espiffe://<trust-domain>/<path>). This ID can be structured to reflect environmental context, labels, or other attributes, making it highly useful for fine-grained authorization.
• Integration: Workloads can obtain SVIDs directly using the SPIFFE SDK (e.g., for Go or Python). Alternatively, sidecar proxies like Envoy (which supports SPIFFE via the SDS protocol) or service meshes like Istio (which uses SPIFFE under the hood) can handle identity issuance and mTLS automatically, abstracting it from application code.

By applying SPIFFE/Spire to the AI agent architecture, Bates demonstrated:

• Credentialed Components: The AI agent itself, its backend tools (e.g., the orders API), and potentially even the LLM connector (if running as a separate service) are all provisioned with unique, short-lived SPIFFE IDs. This establishes service-to-service trust and enables mutual authentication.
• Secure LLM Access (OIDC Integration): Spire can act as an OIDC provider, publishing a JWKS endpoint. Hyperscalers (like Google Cloud) can be configured to trust this Spire OIDC provider. When the AI agent needs to call the LLM, it requests a JWT SVID from Spire. This JWT SVID is then exchanged with Google Cloud for access to Vertex AI, effectively replacing long-lived service account tokens with short-lived, verifiable credentials. This integration removes all long-lived tokens from the architecture.

Solution 2: User Context Attenuation with OAUTH Transaction Tokens (OTrTT)

Even with robust workload identity, the challenge of securely propagating user context remains. Bates highlighted that simply passing the user's original JWT (obtained from an OIDC provider like Dex) through the system is problematic due to the token's broad privileges and replay risks. The agent needs to know who initiated the request and what their specific intent is, but not necessarily possess their full identity token.

This led Bates to discuss OAUTH Transaction Tokens (OTrTT), an emerging standard from the IETF's OAUTH working group. While still in draft status, OTrTT provides a mechanism to:

• Encapsulate Context: Combine user identity and the specific request context into a new, short-lived, signed token.
• Attenuate Access: This new token is "attenuated," meaning it grants only the necessary permissions for the specific transaction, rather than the user's full privileges.
• Propagation: This attenuated token can then be safely propagated through the system's call stack (e.g., from an API Gateway to the agent, and then to the tools).

Bates explained that the model is similar to Google's internal "end-user context token" approach, where a front-end service performs user authentication and then mints a context-specific token for internal propagation. An early implementation of OTrTT, called token-edes, exists for experimentation.

In practice, this would involve:

1. Gateway Integration: An API Gateway (e.g., Envoy, or a custom Go reverse proxy as in Bates's example) receives the user's original access token.
2. Transaction Token Service: The gateway interacts with a Transaction Token Service (TTS), providing it with the user's access token and the gateway's own attested workload identity (from Spire).
3. Minting Attenuated Token: The TTS then mints a new, short-lived, signed JWT (the transaction token) that encapsulates the user's identity and the specific purpose/context of the request.
4. Secure Propagation: This attenuated token is then passed downstream to the AI agent and its tools. Downstream services can validate this token and make fine-grained authorization decisions based on the contained context, ensuring the agent can only access data relevant to the requesting user and the specific task.

This combination of SPIFFE/Spire for workload identity and OAUTH Transaction Tokens for attenuated user context creates a robust Zero Trust architecture for AI agents, enabling precise authorization decisions based on "who" (workload ID), "what" (request context), and "on behalf of whom" (attenuated user ID).

Demo / Proof of Concept

▶ Watch: How agents use specific tools in their workflow (5:05)

Matthew Bates illustrated these concepts using a practical Proof of Concept of a customer service chatbot agent. The agent was built using Langraph, a framework from the Langchain project designed for creating graph-based agents with decision-making cycles. For the underlying Large Language Model (LLM), Bates leveraged Vertex AI with the Gemini Flash model from Google.

The agent's primary function was to answer customer inquiries about orders. To achieve this, it was given access to two mock APIs, representing an "orders database": get_orders and get_order_details. Bates provided a detailed prompt defining the agent's role and instructing it on how to utilize these tools based on user input.

In the demonstration, Bates showed a user interacting with the chatbot:

1. User Query: The user asks, "What is the status of my order?"
2. Agent Reasoning: The chatbot (powered by the Gemini Flash LLM) reasons about the user's question and determines that it needs to use the get_orders API tool to retrieve relevant information.
3. Tool Invocation: The agent then invokes the get_orders API. In the secure architecture, this invocation is protected by SPIFFE/Spire. The agent presents its JWT SVID to the orders API, establishing workload identity. Simultaneously, the agent's call to the LLM (Vertex AI) is also secured using a JWT SVID issued by Spire and trusted by Google Cloud via an OIDC federation.
4. User Context: Bates also integrated Dex (an OIDC provider) to authenticate the end-user. The user's identity was passed to the agent, and in later iterations, this was to be attenuated using the OAUTH Transaction Tokens concept, ensuring the agent could only retrieve orders belonging to the authenticated user.
5. Response and Follow-up: The agent retrieves a list of orders. The user then specifies a particular order, prompting the agent to use the get_order_details API, again under the protective umbrella of SPIFFE/Spire and with attenuated user context. The agent then provides the specific order details.

This proof of concept effectively demonstrated how an autonomous AI agent could leverage external tools and information to fulfill user requests, while simultaneously showcasing how SPIFFE/Spire provides robust workload identity for both the agent and its tools, and how OIDC federation secures the connection to the LLM. The discussion around OAUTH Transaction Tokens further highlighted the critical need to secure and attenuate user context to prevent privilege escalation and data exposure within these highly dynamic systems.

Defensive Implications

▶ Watch: Example: Building a secure customer service chat agent (6:00)

The rise of autonomous AI agents presents both opportunities and significant security challenges for defenders. Matthew Bates's talk outlined a clear path for organizations to secure these emerging systems by adopting a Zero Trust mindset and leveraging robust identity solutions.

Here are the key defensive implications and actions:

1. Embrace Workload Identity for All Agent Components:

• Implement SPIFFE/Spire: Treat AI agents, their tools (APIs, databases), and any intermediary services as distinct workloads requiring cryptographically verifiable, short-lived identities. SPIFFE/Spire is a mature CNCF project that can provide this.
• Eliminate Long-Lived Tokens: Actively replace static API keys and service account tokens for LLM access and tool invocation with JWT SVIDs or X.509 SVIDs issued by Spire. This drastically reduces the attack surface from credential compromise.
• Federate with Hyperscalers: Configure Spire as an OIDC provider and establish trust relationships with cloud providers (e.g., Google Cloud, AWS, Azure) to enable LLM access using short-lived JWT SVIDs, further enhancing security.

1. Implement Fine-Grained Authorization for Tools:

• Policy Enforcement: Leverage the SPIFFE ID embedded in workload identities to enforce granular access policies for every tool an agent can invoke. An agent should only have access to the specific data and actions required for its intended function.
• Prevent Over-Privilege: Ensure that tools do not grant broad access to entire databases or sensitive systems. Authorization policies must restrict access based on the agent's identity and the specific request context. This prevents an agent from being prompted (maliciously or accidentally) to exfiltrate data it shouldn't see.

1. Secure and Attenuate User Context:

• Do Not Propagate Raw User Tokens: Avoid directly forwarding a user's original, high-privilege JWT through the agent system. This creates risks of token replay and grants excessive privilege to the agent.
• Explore OAUTH Transaction Tokens (OTrTT): While still in draft, defenders should monitor and prepare for standards like OTrTT. Implement an attenuation mechanism at the system's entry point (e.g., API Gateway) to create a short-lived, purpose-specific token that encapsulates the user's intent without exposing their full identity. This token should then be used for all downstream authorization decisions.
• Combine Identities for Authorization: Policy decisions should be based on a combination of the workload's identity (the agent's SPIFFE ID) and the attenuated user context (from the transaction token). This ensures that the agent acts with the correct permissions on behalf of the correct user for the specific task requested.

1. Monitor and Audit Agent Actions:

• Logging: Implement comprehensive logging of agent decisions, tool invocations, and responses, associating these actions with both the agent's identity and the originating user's context.
• Anomaly Detection: Develop mechanisms to detect unusual agent behavior, such as attempts to access unauthorized tools, retrieve excessive data, or deviate from its defined purpose.

1. Stay Engaged with Open Standards:

• Participate: Bates emphasized that the field of AI agent security is rapidly evolving. Defenders should engage with open standards bodies like the IETF (Whimsy, OAUTH groups) and the CNCF to contribute to and stay informed about emerging best practices and solutions for securing autonomous systems.

By proactively adopting these defensive strategies, organizations can build more secure and resilient AI agent architectures, mitigating the unique risks posed by their autonomy and access to critical systems.

Key Takeaways

• AI Agents Demand a New IAM Paradigm: Traditional security models with long-lived tokens and implicit trust are insufficient for autonomous AI agents due to their decision-making capabilities and access to external tools.
• Workload Identity is Foundational: Utilize SPIFFE/Spire to assign cryptographically verifiable, short-lived identities (X.509 SVIDs, JWT SVIDs) to all agent components, including the agent itself, its tools, and connections to LLM providers, eliminating long-lived credentials.
• Secure LLM Access with OIDC Federation: Leverage Spire's OIDC provider capabilities to enable trusted, short-lived JWT SVID-based authentication with hyperscalers for LLM access, removing the need for static service account tokens.
• User Context Attenuation is Critical: Avoid propagating full user JWTs through agent systems. Emerging standards like OAUTH Transaction Tokens (OTrTT) offer a promising solution to create attenuated, purpose-specific tokens that safely convey user intent for fine-grained authorization downstream.
• Embrace Zero Trust Principles: Implement authorization policies based on a combination of workload identity (agent's SPIFFE ID) and attenuated user context to ensure agents operate with the least privilege necessary for each specific task.
• Actively Engage in Standards Development: The security landscape for AI agents is rapidly evolving. Participate in relevant open standards groups (e.g., IETF OAUTH, Whimsy) to contribute to and stay ahead of best practices.

About the Speaker(s)

Matthew Bates is a founder at Cofide, a UK startup that focuses on workload identity. He is deeply engaged with open standards and tools within the CNCF, which are integral to Cofide's work. Bates is passionate about the evolving challenges in securing cloud-native environments and is actively involved in exploring solutions for next-generation systems, particularly in the realm of AI agents. He has a keen interest in how projects like SPIFFE/Spire can be leveraged to address complex identity and access management problems at scale.