If you're wiring an autonomous agent up to real APIs — Stripe, Supabase, GitHub, your own backend — there's a design decision most stacks get wrong, and it's the same one that turns "the agent did something weird" into "the agent moved money."

The root problem: the credential is the capability

An API key is a bearer token. Whoever holds the bytes can do everything the key permits, for as long as the key lives, with no per-call limit and usually no per-call record. When you paste that key into an agent's environment, you've handed a non-deterministic process the full blast radius of that key in one move. A prompt injection, a logging mistake, a retry loop — any of them now operates with your production credentials.

Rotating after a leak means rotating everywhere the key was ever embedded. And a leaked key is indistinguishable from a legitimate caller until you notice the bill.

The pattern: brokered egress

The fix is to make the thing the agent holds not the thing that grants access:

1. A human vaults the real provider secret once, in a broker the agent can't read.
2. The agent gets a scoped, revocable token it can present but never read.
3. A policy checkpoint sits on the outbound path. The real secret is injected server-side only after the request passes the rules — allowed host, allowed method, a spend ceiling, rate limits.
4. Every allowed/blocked call lands in an append-only audit log.

Agent ── scoped token ──▶ Broker (policy + vaulted key) ──▶ Stripe / Supabase / ...

Three properties fall out of this:

• The secret can't be exfiltrated from the agent, its prompt, or its logs — it was never there.
• Revocation is one write, not a key rotation across every system that ever touched the key.
• "The agent did something it shouldn't" becomes a synchronous 403 at the broker, not a forensic finding after the money moved.

The part people miss: injection still bites

Even with the key behind a broker, a prompt-injected agent can still drive policy-permitted actions. So the checkpoint has to do more than authenticate the caller — it has to taint requests that carry untrusted-content provenance and refuse the sensitive ones. Authentication is not the same as good intent.

And the audit log should be tamper-evident (e.g. a hash chain), because the log is exactly what a capable attacker edits first.

When you don't need this

If your provider already issues short-lived, least-privilege OAuth tokens with native audit — use those. They're a stronger primitive than proxying a static key. The brokered model earns its keep when you're stuck handing out long-lived static secrets, which, for now, is still most of them.

Disclosure: I work on Vertex, which implements exactly this pattern — vault a key once, the agent gets a scoped token it can't read, with policy + spend caps + taint-based injection blocking on egress and a tamper-evident audit trail. Writing up the architecture because it generalizes regardless of whose broker you use.