Stop putting API keys in your agents

There is a step in nearly every agent tutorial that deserves more alarm than it gets: export your API key, then hand it to the model runtime.

It works. It is also the part that will eventually cost someone a weekend.

What you are actually granting

A provider API key is usually coarse. A Stripe secret key can read customers and issue refunds. A Slack bot token can read every channel it has joined. A Salesforce token inherits the permissions of the user who authorised it, which in practice is often an admin.

When that key is in an agent's environment, three things become true at once:

• The blast radius is the whole key. The agent has every permission the key has, not the subset it needs.
• The key is copied. It is in a dotfile, a CI variable, a container image and at least one laptop.
• You cannot see what it did. Provider logs show "API key ending 4f2c", not which agent, which task, or which prompt.

Prompt injection makes this concrete

An agent that reads untrusted input, whether a support ticket, a web page or a PDF, can be steered. A malicious instruction inside a document can persuade an agent to call a tool it should not have called.

If the agent's credential is scoped to the four tools it needs, the attack fails at the gateway. If the agent holds a full-permission provider key, the attack succeeds and the audit trail shows nothing unusual.

Scoping is not paranoia here. It is the control that turns a critical incident into a rejected request.

Brokered access

The alternative is that the agent never holds a provider credential at all:

1. 1Provider secrets live in a vault, encrypted, server-side.
2. 2The agent holds a gateway key, scoped to an explicit allowlist of connectors and tools.
3. 3At call time the gateway checks the scope, injects the real credential, makes the call and logs it.

vectorhub keys create support-bot \
  --connectors zendesk,stripe \
  --tools "zendesk.ticket.*,stripe.refund.create" \
  --scope read,write

That key cannot list Stripe customers. It cannot post to Slack. It cannot do anything you did not name, and if it leaks, one keys revoke ends it, with no rotation across four services and six machines.

The properties worth insisting on

Whatever you build or buy, hold it to these:

• Least privilege by default. New credentials start with nothing and are granted deliberately.
• Per-agent identity. Two agents never share a key, or your audit log cannot tell them apart.
• Instant revocation. Effective on the next request. Not on the next cache expiry.
• Call-level audit. Arguments, timing, result, and which key was used.
• Rotation without redeploy. Rotating an upstream credential should be a vault operation, not a release.

None of this is exotic. It is the access-control discipline that every other production system already gets. Agents have simply been shipping without it because the tooling made the insecure path the easy one.