IBM's Security Architecture for Agentic AI Systems

IBM is proposing a comprehensive security architecture for agentic AI systems that treats authentication and authorization as separate, continuous processes rather than one-time events. The approach, detailed by Grant Miller in a recent technical presentation, acknowledges something the company doesn't say explicitly: most organizations are deploying these systems without a coherent security model.

The architecture addresses what Miller calls the "unique challenges" of agentic systems—though it's worth noting that many of these challenges aren't particularly unique. They're variations on problems that have existed since the 1985 security standards Miller references. What's changed is the context: AI agents operate with more autonomy, access more systems, and make more decisions than traditional automation.

The Architecture's Core Problems

Miller identifies five distinct security risks in agentic flows, each requiring its own mitigation strategy. The first is credential replay—where an attacker captures authentication tokens and reuses them to gain unauthorized access. This happens in two ways: either through prompt engineering that tricks an LLM into revealing embedded credentials, or through traditional man-in-the-middle attacks on unencrypted communication channels.

The proposed solution is straightforward: use TLS or mTLS for all communication, encrypt stored credentials, and crucially, "make sure you're not passing in identity information to the LLM. The LLM doesn't need that. It just needs to be able to organize and figure out what the task is for it."

That last point deserves emphasis. Organizations are apparently feeding authentication tokens to language models—either through carelessness or misunderstanding of what data LLMs actually need. Miller's guidance implies this is common enough to warrant explicit prohibition.

The second risk is rogue agents—unauthorized actors spoofing legitimate agent identities to gain system access. IBM's answer is to require all agents to authenticate with an identity provider before accessing any tools. "We have an agent come up, we have a agent come and we say, please prove you are who you say that you are," Miller explains. This prevents unauthorized agents from participating in workflows, though it requires organizations to maintain a registry of legitimate agents and implement validation at multiple points in the flow.

Delegation and the Impersonation Problem

The third risk is more subtle: agent impersonation of users. Even if an agent is authenticated and legitimate, how do you verify it's actually working on behalf of the user it claims to represent?

Miller's solution introduces delegation tokens that combine two identities: the subject (the user) and the actor (the agent). This dual-identity token is issued by the identity provider, not the agent itself. "Not anywhere along this way can an agent assert what it's doing," Miller emphasizes. "It has to be validated and provided by an independent party, in this case, which is the identity provider."

This addresses a real vulnerability. Without delegation verification, any authenticated agent could claim to be acting for any user, and downstream systems would have no way to validate that claim. The architecture forces that validation through a central authority.

The fourth risk involves token propagation through multi-hop flows. IBM recommends token exchanges at each node—the system calls the identity provider at every step to exchange the incoming token for a new one specific to that leg of the journey. This creates an audit trail and ensures that compromised tokens have limited scope. It also introduces latency and creates a single point of failure at the identity provider, though Miller doesn't address these trade-offs.

Overpermissioning and Scope Restriction

The fifth risk is overpermissioning—granting agents or users broader access than necessary for their specific task. "A user may be able to connect to lots of tools, but in the context of this flow, we only want to be able to show what that user can connect to," Miller explains.

The solution uses token scopes that restrict permissions to the minimum required for each interaction. This is least-privilege access control, a principle that's been around for decades. What makes it challenging in agentic systems is the need to determine appropriate scopes dynamically based on the task being performed.

The Last Mile Problem

The architecture's final component addresses what Miller calls "the last mile"—the connection between MCP (Model Context Protocol) servers and actual tools or APIs. Up to this point, the flow has been tokens and validation. But now the MCP server needs to authenticate to external systems that may not speak the same protocol.

IBM's answer is a secure vault that manages tool credentials and issues temporary credentials to MCP servers on demand. This prevents the MCP server from storing long-lived credentials that could be compromised. It's a sensible approach, though it requires organizations to deploy and manage yet another infrastructure component.

What's Missing from This Picture

The architecture is technically sound but conspicuously silent on several practical questions. What happens when the identity provider is unreachable? How do organizations handle the latency introduced by multiple token exchanges per request? What's the operational overhead of maintaining agent registries and updating delegation policies?

More fundamentally, IBM is describing an enterprise-grade security model that assumes centralized control, maintained infrastructure, and technical sophistication. This works for large organizations with security teams. It's less clear how it applies to smaller companies deploying agentic systems, or to scenarios where agents need to operate across organizational boundaries.

The architecture also assumes agents will respect the authentication framework. But agentic systems are by definition autonomous. What prevents a poorly designed or compromised agent from attempting to bypass these controls? Miller's presentation doesn't address adversarial scenarios where the agent itself is the threat.

There's also the question of standards. IBM is proposing this architecture, but so are Microsoft, Google, and various startups. Without industry consensus on token formats, delegation protocols, and identity verification methods, organizations may end up with incompatible security models that don't interoperate.

What Miller has outlined is less a complete solution than a framework for thinking about agentic security. The architecture identifies the right problems and proposes defensible mitigations. Whether it becomes the standard approach or just one vendor's interpretation will depend on factors beyond technical merit—including how quickly other organizations recognize these risks and how willing the industry is to coordinate on common standards.

—Samira Okonkwo-Barnes