Five Reasons Your AI Agent Should Never Hold an API Key

The fastest way to give your AI agent access to an external service is to paste an API key into its environment variables. I've done it. You've probably done it. It is also one of the most dangerous patterns in modern AI system design — here's why.

1. API keys are all-or-nothing

A Stripe secret key lets the holder create charges, issue refunds, update customer records, and delete payment methods. When you give that key to your AI agent, you are giving it all of those permissions simultaneously — whether it needs them or not. There is no standard way to say “this agent can only create charges up to $50”.

The principle of least privilege has existed in security since 1975. API keys systematically violate it.

2. They never expire unless you rotate them manually

Most API keys live indefinitely. The agent you built today, with the key you provisioned today, might still be running that key in 18 months. If the agent is compromised, decommissioned, or just forgotten, the key keeps working. Spending mandates expire — they carry an exp timestamp, and they cannot be renewed without human re-approval.

3. You have no idea what they were used for

Most API key systems log request metadata at best. They do not log why a request was made, which agent made it, or what delegation chain authorized it. If your AI agent makes 400 API calls in a loop, you will see 400 requests in the log. You will not see which LLM decision triggered the first call.

Every Aroha request carries a correlationId, an issuer DID, and a mandate reference. You can trace any action back to the human approval that authorized it.

4. They do not survive multi-agent delegation

When your orchestrator delegates to a sub-agent, what does that sub-agent use to call external APIs? If the answer is “the same API key as the orchestrator”, you have given a sub-agent full orchestrator-level access. If the answer is “a different key I provisioned for it”, you have doubled your key management burden — and still have no spend limits.

5. Leaking one key leaks everything

Prompt injection, compromised dependencies, and LLM jailbreaks are real threat vectors for AI agents. If an attacker can extract the API key from an agent's context — through any of these vectors — they have indefinite, full-permission access to your account.

Spending mandates are short-lived, single-use tokens. A leaked mandate gives an attacker access to one specific action, within the spend limit, until the mandate expires (typically minutes to hours). The blast radius is bounded by the mandate itself.

What to do instead

Keep your API keys in your orchestrator — not in your sub-agents. Issue spending mandates from the orchestrator to sub-agents. Let sub-agents call your own validated endpoints (which hold the keys), rather than calling external APIs directly.

For external services that support OAuth, use OAuth flows to get short-lived access tokens and wrap them in mandates. For services that only support API keys, build a thin proxy that accepts mandate-authenticated requests and translates them to API key calls internally.