How AI Agents Connect to Tools Securely

Here's the thing nobody tells you when they demo an AI agent booking your travel or filing your Jira tickets: the agent had to authenticate somewhere to do that. It needed credentials. It had to prove—to GitHub, to Slack, to whatever tool it was wiring into—that it had the right to be there. And right now, a lot of those conversations are happening in ways that would give a security auditor a headache.

IBM's Grant Miller recently walked through five distinct patterns for connecting AI agents to external tools, framing them as a progression from "quick and dirty" to "this is how you'd actually run it in production." It's a useful map of where agentic integration currently sits—and where the real security debt is accumulating.

Pattern five: The API key era

The simplest model is the one that's been around since the early GenAI days: a direct connection between the agent and the tool, authenticated with an API key or a service ID. The agent calls the tool. The tool answers. The user gets a response. Nobody asks any hard questions.

Miller is honest about why this worked early on: "We only allowed information to be accessed that was generally public or available to the entire company." When the stakes are low and the data is non-sensitive, a blunt instrument works fine.

The problem is that this model doesn't scale to sensitive enterprise contexts. The tool has no idea who the human on the other end is. It can't enforce user-level permissions because, from its perspective, there is no user—just an agent holding a static credential. You're essentially granting the agent whatever access you granted the API key. Which, depending on how that key was scoped, could be a lot.

Pattern four: OAuth solves one problem, creates another

Adding OAuth flows is the obvious next step, and it's the model you've probably already seen in the wild. Claude does it. Copilot-style coding tools do it. The agent initiates contact with the tool; the tool authenticates the user through an identity provider; the tool issues an access token; the agent now acts on the user's behalf.

This is better. The tool now knows who the user is. GitHub, Jira, Slack—they all support this natively, so you're not building anything novel. It's an established pattern.

But Miller flags something that I think gets underplayed in most discussions of OAuth in agentic contexts: impersonation, and long-lived tokens. "As far as the tool is concerned, it's seeing the user. The agent is really impersonating the user when it's interacting with the tool. The tool has no visibility to the agent or what the agent is trying to do."

That impersonation problem matters for two reasons. First, the tool can't distinguish between the user making a careful, intentional decision and an agent running a multi-step workflow autonomously. Second, GitHub OAuth tokens can live for 90 days or longer depending on configuration. If that token is compromised—intercepted, leaked, exfiltrated—an attacker has a 90-day window on whatever the token could access. That's not a theoretical risk; that's a meaningful attack surface.

Pattern three: MCP as the abstraction layer

Pattern three keeps the OAuth flow but inserts Model Context Protocol between the agent and the tool. The security posture doesn't change dramatically here—you're still doing OAuth, still dealing with access tokens—but the architecture gets meaningfully cleaner.

The key shift is that agents no longer need tool-specific knowledge. Without MCP, every agent has to be written to understand the specific API of every tool it might interact with. That's a combinatorial problem as your tool ecosystem grows. With MCP acting as an abstraction layer, the agent only needs to know how to talk to MCP. The protocol handles the translation.

Miller frames this as adding a feature, not solving a problem. And that's right—MCP doesn't fix the impersonation issue or the long-lived credential issue from pattern four. It makes the system more maintainable and extensible. Those are real wins. They're just different wins than security hardening. For a deeper look at what MCP actually does to your attack surface, the MCP security architecture question is worth sitting with separately.

Pattern two: Finally, the agent identifies itself

This is where the framework gets genuinely interesting from a security standpoint. Pattern two drops the direct OAuth flow and replaces it with a token exchange mechanism—and critically, it requires the agent itself to authenticate.

Up through pattern four, the agent was essentially invisible to the tool. The user authenticated; the agent used that authentication. With token exchange, the system knows both who the user is and who the agent is. The agent operates explicitly on behalf of the user through a delegation model. "A user is going to say, 'I'm going to delegate to this agent work that I want it to do against the tool,'" Miller explains. "Now we know who the user is, and we also know who the agent is."

This matters for a few reasons that go beyond the obvious. Full observability means you can actually audit what happened. If an agent took an action that shouldn't have been taken, you now have a clear chain of identity—user, agent, action—rather than just a tool log showing an access token was used. You can enforce least-privilege more precisely because you know what the agent is, not just what the user is. And the zero-trust implications here are significant: this is the first pattern in the progression where you could plausibly claim the system upholds a zero-trust model at every hop.

Token propagation also adds security to the movement of tokens through the system, ensuring the flow itself isn't a vector. The architecture is more complex. The payoff is proportionate.

Pattern one: Short-lived credentials and the vault

The top pattern addresses the problem that persists even through pattern two: access tokens that live too long.

The vault model stores long-term tokens in a secured, locked-down credential store rather than handing them to the agent or MCP directly. When the agentic workflow needs to authenticate, the vault issues a short-lived credential. When that credential expires—minutes or hours later, not 90 days—it's useless. "We really want tokens to be very short-lived," Miller says. "So if they're intercepted and replayed, then they only last a short time and then there's no longer the ability to do that."

This is textbook defense-in-depth applied to a specific agentic threat model: credential interception and replay. It doesn't prevent a token from being stolen; it limits what a stolen token is worth. That's a meaningful distinction. The privilege escalation risks that come with agents holding elevated, long-lived credentials are real, and this pattern directly addresses them.

Combined with MCP as the abstraction layer and token exchange for mutual authentication, this is what a production-grade agentic security architecture looks like—at least by current thinking.

What the progression actually reveals

Miller presents these five patterns as a countdown from weakest to strongest, and that framing is useful for understanding the tradeoff curve. But it's worth being explicit about what you're trading and to whom the tradeoffs matter.

Patterns five and four are where most deployed agentic systems live right now. They're simple to implement, and they use infrastructure that already exists. The security gaps are real—no user visibility, agent impersonation, long-lived tokens—but for low-stakes internal tooling, they may be acceptable. Security is always about what's proportionate to the threat, not what's theoretically ideal.

Patterns three through one require more infrastructure investment. MCP needs to be deployed and maintained. Token exchange requires an identity architecture that many enterprises don't have fully built out. Vaults need to be managed. None of this is impossible, but it's not free, and organizations need to be honest about whether their current agentic workloads actually warrant the investment—and which ones will, soon.

The deeper issue Miller's framework surfaces is that agentic systems are being integrated into enterprise processes faster than the security tooling for those systems is maturing. The IBM security architecture work around credential replay and rogue agents speaks to exactly this: the threat model is clear, the defenses exist in principle, but the deployment gap is real.

Five patterns, each more secure than the last. The question isn't which one is best in the abstract—it's which one your current threat model actually requires, and whether you've honestly assessed that threat model yet.

---

Rachel "Rach" Kovacs covers cybersecurity and privacy for Buzzrag.