5 Patterns for Connecting AI Agents to Tools: From Direct API Calls to MCP + Vault Security Architecture

As agentic systems become increasingly common in enterprise workflows, how to securely and efficiently connect AI agents to external tools has become a central architectural challenge. In a technical session, IBM systematically outlined five mainstream patterns for connecting agents to tools — from the simplest direct connection all the way to a Vault-based short-lived credential solution — with each step building on the previous one to strengthen security.

This article breaks down the implementation principles, advantages, and limitations of each pattern to help you choose the right connection architecture for your enterprise-grade AI agent system.

Pattern 5: Direct API Connection

This is the earliest and most straightforward connection approach. A user interacts with an agent, which directly accesses tools using existing credentials like API keys or service IDs, retrieves information, has the LLM process the prompt and response, and returns the result to the user.

This pattern was common in early generative AI systems, RAG pipelines, and some first-generation agent systems, since it reuses existing agent-to-tool connection methods.

Advantages are obvious: the connection is direct and simple, requiring almost no investment beyond existing capabilities. Stand up an agent, connect it to a tool, and you're good to go.

But the drawbacks are equally significant — the tool has zero visibility into the user. The agent uses its own credentials to access the tool, and the tool has no idea who is actually behind the request or whether that user is authorized. Early workarounds typically limited agents to accessing only public or company-wide information to sidestep permission issues.

Pattern 4: Direct Connection + OAuth Flow

Pattern 4 is still a direct connection, but introduces an OAuth flow. The key change is the addition of an Identity Provider to authenticate the user — we finally know "who the user is," and this authentication process is primarily handled on the tool side.

Tools like GitHub, Jira, and Slack have built-in OAuth capabilities. The flow works like this: the agent communicates with the tool, the tool asks "who is this user," authentication is completed, the tool issues an Access Token, and the agent then uses that token to connect to the tool. We've seen this pattern in many development tools — for example, when using Claude for Vibe Coding, it interacts with tools, obtains an access token, and stores it locally.

Advantages include leveraging OAuth, a mature and widely recognized pattern, and beginning to establish real user identity authentication.

However, compared to Pattern 5, it introduces new security concerns:

• Impersonation: While the "invisible user" problem is solved, the tool actually sees the user — the agent is "impersonating" the user when interacting with the tool. The tool knows nothing about the agent itself, what it intends to do, or what it's permitted to do.
• Long-lived credential risk: OAuth flows (especially on tools like GitHub) can generate access tokens that live for 90 days or longer. Agents store these tokens for extended periods, and such long-lived credentials are a security liability.

Pattern 3: Introducing MCP as an Abstraction Layer

Pattern 3 removes the direct connection and formally introduces MCP (Model Context Protocol), placing it between the agent and the tools.

Interestingly, everything else remains largely the same: the agent still communicates with tools, still uses OAuth, still authenticates applications, and still works with access tokens. The real change is the abstraction capability that MCP introduces.

Previously, an agent had to know exactly how to interact with each tool, and integrating a new tool meant learning its interface details from scratch. With MCP, the agent only needs to understand "how to interact with MCP" — it doesn't need to care about the underlying tool implementation.

This is a critical architectural upgrade: it frees agents from tedious per-tool adaptation and dramatically reduces the complexity of multi-tool integration, laying the groundwork for more granular security controls down the line.

Key Advantages of MCP Over Direct API Calls

• Agents don't need to write bespoke connection logic for each tool
• Adding a new tool only requires implementing the MCP interface — no changes needed on the agent side
• A unified protocol layer makes centralized security policy management possible

MCP Background: MCP (Model Context Protocol) is an open standard proposed by Anthropic in late 2024, designed to provide a unified communication specification for interactions between AI models and external tools and data sources. Think of MCP for AI agents the way USB is for peripherals — without a standard, every device needs a custom driver; with a standard interface, any compliant device is plug-and-play. MCP uses a client-server architecture: the agent acts as an MCP Client, and various tools (code execution environments, databases, web search, file systems, etc.) act as MCP Servers. Both sides communicate via standardized JSON-RPC messages for tool calls, resource reads, and prompt injection. Leading models including Claude, OpenAI, and Gemini have added MCP support, and platforms like GitHub, Slack, and Notion are rolling out official MCP Servers as the ecosystem rapidly expands. Understanding MCP's abstraction value is foundational for understanding the architectural evolution in subsequent patterns.

Pattern 2: Token Exchange and "On Behalf Of" Delegation

Pattern 2 removes the application-level OAuth flow and instead introduces Token Exchange and an "On Behalf Of" delegation mechanism.

The core of this pattern is: requiring the agent to authenticate itself. The system now knows both "who the user is" and "who the agent is," with the agent explicitly acting "on behalf of the user" — meaning the user is delegating to the agent the work they would otherwise do directly with the tool.

Token Exchange also adds a layer of security to the token flow, ensuring access tokens are passed securely and correctly throughout the entire chain.

Core advantages:

• The agent's identity is authenticated, moving beyond reliance on application-level OAuth alone
• Both an authenticated user and an authenticated agent are present, with a clear understanding that the agent is operating "on behalf of" the user
• Introduces token propagation

More importantly, it completely eliminates the impersonation problem from Pattern 4. The system now has full visibility into the user, the agent, and what each is permitted to do — achieving true observability and transparency.

Token Exchange Background: Token Exchange is an OAuth 2.0 extension specification (RFC 8693) that allows one security token to be "exchanged" for another while attaching additional context to the new token. In an agent scenario, the typical flow works like this: after the user logs in and receives an ID Token, the agent submits that token along with its own client credentials to the authorization server. The server verifies both identities and issues a new access token that encodes both "who the user is" (the act claim) and "who is acting on behalf of the user" (the actor claim). When a tool service receives this token, it can parse out the complete call chain — a specific user authorized a specific agent to perform a specific action — enabling fine-grained access control and audit trails. "On Behalf Of" is Microsoft Azure AD's specific implementation name for this pattern, commonly seen in enterprise system integration scenarios. This mechanism fundamentally solves the agent impersonation problem and is a critical step toward building auditable, trustworthy enterprise agent systems.

Pattern 1: Vault-Managed Short-Lived Credentials (Most Secure)

As the most secure pattern, Pattern 1 adds a Vault to the previous foundation and has it interact with MCP.

The pain point it addresses: both the OAuth flow and Pattern 2 require obtaining and storing user access tokens for extended periods. What we actually want is for tokens to be as short-lived as possible — so that even if a token is intercepted and replayed, the window of opportunity for an attacker is extremely limited.

Pattern 1's approach: instead of carrying long-lived access tokens through the entire flow, long-lived tokens are stored in a Vault that can be strictly locked down and controlled. The Vault then issues short-lived credentials to MCP on the user's behalf. This means only short-lived credentials are used throughout the entire agent workflow.

This is Pattern 1's greatest strength: short-lived credentials throughout, fundamentally eliminating the risk of long-lived token abuse.

Vault Background: The most well-known Vault implementation is HashiCorp Vault, an open-source tool designed for secrets management, dynamic credential generation, and access control. Cloud providers offer equivalent services (e.g., AWS Secrets Manager, Azure Key Vault). Its core capability — Dynamic Secrets — is exactly the mechanism Pattern 1 relies on: rather than simply storing static API keys, Vault requests a temporary credential from the target system (such as a database or cloud service) on demand. This credential has a very short TTL (Time To Live, such as 15 minutes) and is automatically revoked by Vault when it expires. This means that even if a credential is intercepted in transit, the attacker's usable window is extremely limited, and once expired, the credential is completely invalid. By contrast, the traditional approach of hardcoding long-lived API keys in config files means a single leak can be exploited indefinitely. In an agent context, every task execution requests a fresh short-lived credential from Vault that automatically expires when the task ends — compressing the blast radius of any credential leak to an absolute minimum.

Summary: The Evolution of Five Agent Connection Patterns

Looking across these five patterns, a clear thread of progressive security improvement emerges:

Pattern	Core Characteristic	Problem Solved	Remaining Risk
Pattern 5	Direct API connection	Fast time to launch	User invisible to tool
Pattern 4	OAuth authentication	User identity known	Impersonation, long-lived credentials
Pattern 3	MCP abstraction layer	Tool decoupling	Still relies on long-lived OAuth tokens
Pattern 2	Token Exchange	Dual auth: agent + user	Credential lifetime too long
Pattern 1	Vault short-lived credentials	Short-lived credentials end-to-end	Higher architectural complexity

Each pattern provides stronger security guarantees than the one before it. For teams building enterprise-grade agent systems, understanding this evolution is essential — it's not just a technical selection guide, but a window into the trajectory of AI agent security architecture: moving from "functional" toward "controllable, observable, and trustworthy."

Choosing the Right Connection Pattern

• Prototype / proof-of-concept stage: Pattern 5's direct connection offers fast startup
• Internal-user applications: Pattern 4 or Pattern 3 can meet basic security needs
• Enterprise production systems: At minimum, adopt Pattern 2 to ensure both agent and user are authenticated
• High-security scenarios: The Pattern 1 combination of MCP + Token Exchange + Vault is the recommended best practice

As MCP gradually becomes the de facto standard for agent-to-tool connectivity, combining it with Token Exchange and Vault is likely to become the dominant paradigm for enterprise-grade AI agent security architecture.