How to Secure the Trust Chain in Agentic AI

Key insights

• The biggest security risk in agentic AI is not the model itself but the identity chain connecting user, agent, and tool. Most AI security discussions focus on model safety while ignoring infrastructure-level trust.
• Agents need their own verifiable identities, not just inherited user tokens. A rogue agent can spoof any user if the system only checks user credentials and never authenticates the agent itself.
• Never pass identity tokens to the LLM. It does not need them, and prompt injection can extract them. A simple rule that many early implementations get wrong.

In Brief

AI agents are being handed real access to tools, APIs, and databases. That creates a trust problem: how do you make sure the chain from user to agent to tool is not broken at any point? Grant Miller, Distinguished Engineer at IBM, walks through the four main risks in agentic systems and the token-based architecture that addresses each one. The security principles are not new (the first real standards date back to 1985), but agentic systems introduce unique challenges because AI behavior is non-deterministic.

The agentic flow

Miller starts by drawing out a typical agentic flow: a user interacts with a chat interface, which sends requests to an orchestrator. The orchestrator delegates work to one or more AI agents, which communicate with MCP servers (Model Context Protocol, a standard for connecting AI models to external tools), and those servers connect to the actual tools and data sources.

Large language models sit alongside this flow, not inside it. They help the chat understand the user's intent, help the orchestrator plan the workflow, and help individual agents decide how to respond. But the LLMs are advisory. The actual work moves through the chain.

An identity provider authenticates the user at the start and issues a token. That token is supposed to propagate through the entire chain so every component knows who the user is and what they are allowed to do. The problem is that this propagation can break in at least four ways.

Risk 1: Credential replay

The first risk is credential replay, where an attacker steals an authentication token and reuses it to gain unauthorized access. Miller describes two ways this happens. In one scenario, developers accidentally include the user's token in prompts sent to the LLM. A bad actor can then use prompt injection (crafting inputs that trick the model into revealing information) to extract that token. In another, a man-in-the-middle attack intercepts tokens between components because connections are not encrypted.

The fix is two-fold. Use TLS or mTLS (mutual TLS, where both sides of a connection verify each other) across the entire communication flow, and encrypt any stored credentials. The second part is even simpler: do not send identity information to the LLM. It does not need it. The LLM's job is to understand the task, not to know who is asking. Keeping tokens out of prompts eliminates an entire class of attacks.

Risk 2: Rogue agents

The second risk is rogue agents that spoof the identity of legitimate agents. An unauthorized agent shows up, claims to be part of the workflow, and requests access to tools or data meant for the real agent.

The solution mirrors how companies already handle human users: give agents their own identities through an identity provider, and authenticate them. When agent one passes work to agent two, agent two's identity can be validated against the provider. The same check happens at MCP servers. If an agent cannot prove its identity, it does not get access. This is a shift from traditional auth systems, which assume every actor is human.

Risk 3: Impersonation through delegation

Even if you trust that an agent is who it claims to be, you still need proof it is acting on behalf of a specific user. Without that proof, any authenticated agent could claim to represent any user. Miller calls this impersonation, and the solution is delegation tokens.

A delegation token combines two pieces of information: the subject (the user) and the actor (the agent). When the user authenticates and an agent authenticates separately, the identity provider issues a combined token that binds them together. As this token moves through the flow, any component can verify both who the user is and which agent is acting on their behalf. No agent can assert its own delegation. It has to be validated and issued by the identity provider.

Token exchange happens at every hop. At each step in the chain, the incoming token is exchanged for a new one through the identity provider. This ensures trust is verified continuously, not just at the entry point.

Risk 4: Overpermissioning

The fourth risk is agents having broader access than they need. A user might have permissions across many tools and data sources, but for any given task, only a small subset is relevant. The same applies to agents.

Miller's answer is scoped tokens with least privilege at each exchange point. When tokens are exchanged at each hop, the scopes are narrowed to only what is needed for the next step. Agent one can talk to agent two, and that is all its token allows. Agent two can connect to a specific tool through MCP, and nothing more. This prevents a compromised agent from accessing resources beyond its immediate task.

The last mile: MCP to tool

The final piece is what Miller calls the last mile: the connection between an MCP server and the actual tool it needs to access. Up to this point, everything moves through tokens. But the tool itself often requires its own API credentials, database passwords, or other secrets.

Storing those credentials on the MCP server is the wrong approach. It creates a single point of exposure. Instead, Miller recommends a secure vault that manages tool credentials and issues temporary, short-lived credentials to the MCP server on demand. The agent provides its delegation token, the vault verifies it, and hands back a temporary credential scoped to that specific tool interaction. When the interaction ends, the credential expires.

Four pillars

Miller closes with a summary of the four pillars that make an agentic system trustworthy. Authentication verifies who is operating across the flow: users and agents alike. Authorization controls what each actor can do through scoped tokens and least privilege. Delegation binds agents to the users they represent, verified by an independent identity provider. And propagation ensures all of this information moves securely through every hop in the chain.

None of these concepts are new. Token exchanges, mTLS, vaults, and scoped permissions have been part of enterprise security for decades. What is new is the need to apply them to AI agents that act autonomously, make non-deterministic decisions, and connect to real tools with real consequences.

Glossary

---

Sources and resources