Why raw API keys are the biggest risk in your AI stack

Open almost any agent codebase and you’ll find it within the first ten lines: an environment variable holding a long-lived API key, passed straight into the model’s tool layer. It works on the first try, which is exactly the problem. The raw key is the path of least resistance, and it’s the worst security primitive in your AI stack.

What a raw key actually is

A raw API key is a bearer token: whoever holds it is the account, with all of its powers, until someone manually rotates it. That model was tolerable when keys lived in a handful of backend services written by people. It is dangerous when the holder is an autonomous agent that:

• acts thousands of times an hour without a human in the loop,
• can be redirected by untrusted text it reads (prompt injection),
• and is often glued together by whoever needed it working by Friday.

A bearer key gives an agent all-or-nothing access. There’s no “this key can read the CRM but not delete from it.” There’s no “this key works for $40 but needs approval for $4,000.” The key is the whole account.

The four failures of the raw key

1. No scope

The key grants every action the underlying account can perform. Your support agent only needs to read tickets, but its key can also delete them, export the customer list, and change billing. The blast radius isn’t “what the agent should do” — it’s “everything the account can do.”

2. No attribution

When the audit question comes — who initiated this $9,000 transfer? — the honest answer is “a key.” Not which agent. Not which human owns that agent. Not which prompt triggered it. The provider’s logs show a successful, authenticated call. Everything looks fine, because to the API, it was a valid request.

3. No expiry, no revocation that works

Keys outlive the projects that created them. They get copied into a second service, pasted into a CI variable, screenshotted into a Slack thread. Rotating one means hunting down every copy and hoping you found them all. Meanwhile the key keeps working everywhere it leaked.

4. Catastrophic when leaked

Because a key is a bearer token with full powers, a single leak is a full compromise. And agents leak keys in ways humans don’t: a prompt injection can convince an agent to print its own environment, echo a secret into a tool call, or paste it into an email. The attack surface now includes the text the agent reads.

The most common agent breach isn’t a clever exploit. It’s an agent that did exactly what a malicious instruction told it to do, using a key that let it do anything.

”But we put the key in a vault”

A secrets manager is necessary and good — it stops keys from sitting in plaintext. But it solves storage, not use. The moment the agent fetches the key from the vault to make a call, you’re back to a bearer token with full powers acting in the path. The vault never saw the request to payments_pay $9,000; it only saw vault_get.

What you actually need is to keep the key out of the agent entirely and put a layer between the agent and the resource.

The fix: scope, broker, attribute

Replace the raw key with a brokered, scoped, attributed path:

1. The agent never holds the upstream key. The real credential lives behind a control plane. The agent authenticates to the plane with its own identity.
2. Every call is scoped. The agent’s role defines which actions it can take. crm_read, yes; crm_delete, no — and the deny path is invisible, so there’s no tool to even attempt.
3. Every call is guarded. Amount caps, domain allowlists, approval thresholds, change-freeze blocks — checked before the side effect runs.
4. Every call is attributed. The log ties the action to the agent and the human who owns it.

In practice the agent code gets simpler, not harder:

# Before: agent holds an all-powerful bearer key
client = Payments(api_key=os.environ["STRIPE_SECRET_KEY"])
client.transfer(amount=9000, to=account)   # no scope, no cap, no record

# After: agent calls through the control plane with its own identity
hivekey.call("payments_pay", amount=9000, to=account)
# → scope checked, daily cap enforced, approval required, action logged
#   the upstream Stripe key never enters the agent's process

Why this is the highest-leverage change you can make

Most AI security work is probabilistic — better prompts, better evals, better guardrail models. All worth doing. But the raw API key is a deterministic problem with a deterministic fix. You don’t have to predict every way an agent could be tricked. You only have to ensure that when it’s tricked, the action it tries simply isn’t on the table.

Take the raw keys out of your agents. It’s the one change that shrinks the blast radius of every future mistake at once.