How Should an AI Agent Log In to the Tools It Calls?

TL;DR: An AI agent shouldn't hold a long-lived key to its tools. It should log in with a short-lived token, issued at runtime for one tool and one job. A stolen key works until someone notices; a stolen token works for minutes. Token exchange (RFC 8693) sits at the top of a four-rung ladder most teams haven't climbed.

Last updated October 5, 2026. Rebuilt for verifiedagents.ai as the four-rung ladder plus the per-tool lookup and this month's first move.

How should an AI agent log in to its tools?

With credentials that expire fast and name who's acting. Most agent security talk covers inbound access: who can reach the agent. The keys live on the outbound side: how the agent proves itself to the CRM, the ticketing system, the storage bucket, the MCP server (Model Context Protocol, the standard connector between agents and tools).

This question came up on ten client calls between May 27 and August 28, 2026, across eight organizations, from a direct-sales company to a life insurer to a large retailer. The details varied every time. The question never did.

What are the four rungs of the credential ladder?

Each rung leaves less standing power in the agent's hands. Rung four stores no downstream key anywhere.

Why is a vault only halfway up?

Because a vault protects the key at rest, not after checkout. Once the agent holds the key, anything that can read the agent's memory or logs can read it too.

A travel company walked me through the common version on August 17, 2026: their agent platform used a service account to get a cloud token, took on a cloud role, then pulled static API keys for its tools from a secrets manager. The team's own words: something they "want to get away from, but is what it is." That's where most programs stand today. Better than keys in config files, and still an agent holding keys to downstream systems.

Rung three is the answer when a tool only accepts an API key. The gateway keeps the key, so the agent can't leak it or hand it to a prompt that asks nicely.

What does token exchange do that a key can't?

It names who's acting. RFC 8693, published in January 2020, defines the trade: the agent presents proof of identity and receives a short-lived token aimed at one service, with the audience and scope spelled out. The token can carry both the person the agent acts for and the agent doing the acting. A stored key carries neither.

The standard separates delegation, where the agent keeps its own identity while acting for someone, from impersonation, where it becomes indistinguishable from that person. For agents, you want delegation, because the logs show both names. Google's Workload Identity Federation applies the same idea to cloud workloads: the hosting platform proves the workload's identity, and short-lived tokens replace stored service account keys, which then get deleted.

There's a hard rule driving this. The MCP security guidance forbids token passthrough: a server must not accept tokens that weren't issued to it, and shouldn't forward a caller's token downstream. Passing tokens along scrambles the audit trail and lets callers bypass controls. So each hop needs a token of its own, with the right audience and a narrow scope. Token exchange is how you mint one.

Which rung should each tool get?

You don't pick one rung for the company. You pick one per tool, by what its login accepts.

1. Modern sign-in (OAuth or SAML): token exchange.

2. API key only: gateway-held key.

3. Username and password only: a broker that logs in for the agent and keeps the password away from it.

4. None of the above: a retirement plan, with the limit written into the contract and a replacement date.

I handed a large retailer this four-branch tree on August 19, 2026, as the standard for new integrations. It works because it turns a security argument into a lookup. Nobody debates. They read what the tool's login accepts.

What should you do this month?

1. Inventory every key your agents hold, with its owner and reach.

2. Replace the widest key first. At minimum, give each agent its own key instead of a shared one. The why is in

   the AI agent identity problem

   .

3. Put a gateway in front of every API-key-only tool.

4. Test token exchange on one high-risk flow before promising it everywhere. Start with agents that touch customer data, and scope them with

   least privilege

   while you're in there.

Frequently asked questions

Is a vault enough for agent credentials?

It's a good rung two and a poor finish line. Pair it with a gateway that injects the key, or move to short-lived tokens, so the agent never holds a downstream secret.

What's the difference between workload identity federation and token exchange?

Federation is the setup: the platform proves the workload's identity, configured once. Token exchange is the call that trades that proof for a short-lived token.

Does the agent need its own identity first?

Yes. Every rung assumes the agent has its own account and owner. A shared key makes the logs useless, since you can't tell which agent used it.

What about coding agents on laptops?

A real limit. Desktop agents run as the human user, so per-agent identity doesn't exist at that layer yet. Climb the ladder server-side first, and lean on the user's own scope limits and logging for laptops.

Key takeaways

• Outbound credentials are where the keys live, and most posts never mention them.

• Four rungs: static key, vaulted key, gateway-injected key, token exchange.

• MCP forbids token passthrough, so every hop needs its own token.

• Pick the rung per tool by what its login accepts. It's a lookup, not a debate.

• Replace the widest key first.

Check your rungs

The free ATF assessment scores your Identity Management posture, credentials included, in about ten minutes.

The best key for an AI agent to hold is none. The ladder gets you there one rung at a time.