When an AI agent calls an external tool, the tool needs to know who’s calling and whether they’re allowed. This is authentication, and it’s more complicated for agents than for traditional software because agents act autonomously, often on behalf of a user who isn’t present when the call happens.

There are three common models for authenticating AI agents to external services: API keys, OAuth, and credits. Each has different trade-offs around simplicity, security, and user experience.

API Keys

The simplest approach. The agent (or its operator) gets an API key from the tool provider and includes it in every request. The key identifies the caller and authorizes access.

How it works:

1. Developer signs up with the tool provider and generates an API key.
2. The key is stored as an environment variable or in a secrets manager.
3. The agent includes the key in an Authorization header on every request.
4. The provider validates the key and processes the request.

Advantages:

• Simple to implement. No auth flows, no token refresh, no redirects.
• The agent can act independently. No user interaction required at call time.
• Works well for server-to-server communication.

Disadvantages:

• One key per provider. If your agent uses 10 tools from 10 providers, you manage 10 keys.
• The key grants full access. There’s no built-in scoping, so if the key leaks, everything it can access is exposed.
• No per-user identity. The key represents the developer or organization, not the end user. If your agent serves multiple users, all calls look the same to the provider.

Best for: Agents that call tools on behalf of the developer or organization, not on behalf of individual end users. Background tasks, research agents, internal automations.

OAuth

OAuth lets the agent act on behalf of a specific user. The user authorizes the agent to access their account with a particular tool provider, and the agent gets a scoped token.

How it works:

1. The user is redirected to the tool provider’s authorization page.
2. The user logs in and approves specific permissions (scopes).
3. The provider issues an access token (and sometimes a refresh token) to the agent.
4. The agent uses the access token in requests. When it expires, the agent uses the refresh token to get a new one.

Advantages:

• Per-user identity. The agent acts as the user, with the user’s permissions.
• Scoped access. The user can grant read-only access, or limit the agent to specific actions.
• Revocable. The user can revoke the agent’s access at any time from the provider’s settings.

Disadvantages:

• Complex to implement. OAuth flows involve redirects, token storage, refresh logic, and error handling for expired or revoked tokens.
• Requires user interaction. The user must complete the authorization flow before the agent can act. This breaks the “agent works autonomously” model.
• Token management at scale is hard. If your agent serves 1,000 users across 5 providers, you’re managing 5,000 token pairs with different expiration schedules.

Best for: Agents that need to act as a specific user. Sending email from the user’s account, accessing their calendar, reading their private repositories. Anything where the action should be attributed to the user, not the agent operator.

Credits (Prepaid Balance)

A credits-based system separates authentication from per-call billing. The user (or developer) prepays for a balance of credits. When the agent makes a tool call, credits are deducted. The tool platform handles authentication with downstream providers on the agent’s behalf.

How it works:

1. Developer tops up a credit balance on the platform.
2. The platform issues a single API key to the developer.
3. The agent uses that key for all tool calls through the platform.
4. Each call deducts credits based on the tool’s price. The platform authenticates with the underlying tool provider using its own credentials.

Advantages:

• Single key for many tools. The agent authenticates once with the platform and gets access to everything in the catalog.
• Micropayment-friendly. Individual tool calls might cost fractions of a cent. Credits bundle these into viable payment amounts. (A $0.005 tool call can’t be charged to a credit card directly, since the Stripe fee alone would be $0.30.)
• Built-in cost control. The agent can only spend what’s been prepaid. No surprise invoices.
• No credential sprawl. The agent doesn’t hold keys for individual providers. The platform manages downstream authentication.

Disadvantages:

• No per-user identity with the underlying provider. All calls go through the platform’s account.
• Requires trust in the platform. You’re giving one service access to all your tool calls.
• The platform becomes a single point of failure. If it goes down, all tools are unavailable.

Best for: Agents that need access to many tools without the overhead of managing individual provider relationships. Developer tools, research agents, prototyping. AgentPatch uses this model: one API key, one credit balance, and access to 50+ tools.

Comparing the Three Models

Hybrid Approaches

In practice, most production agents use a combination.

A common pattern: use a credits-based platform for commodity tools (web search, data lookups, image generation) and OAuth for tools that need user identity (Gmail, calendar, CRM). This keeps the number of OAuth integrations small while giving the agent broad tool access through the platform.

Another pattern: use API keys for internal tools (your company’s APIs) and a platform for external tools. This avoids exposing internal APIs to third parties while still giving the agent a wide toolkit.

What to Consider

When choosing an auth model for your agent, ask:

1. Does the tool need to know who the end user is? If yes, you probably need OAuth.
2. How many tools does the agent need? If many, a platform with a single key reduces overhead.
3. What’s your cost model? If tool calls are cheap and frequent, credits work better than per-call credit card charges.
4. How much complexity can you maintain? OAuth is powerful but expensive to build and operate correctly.

The right answer depends on your specific use case. But understanding the three models and their trade-offs is the first step toward getting authentication right for your AI agent.