How AI agents leak API keys
Every service handles secrets badly at some point. Agents do it differently, and worse, for reasons that follow directly from how they work.
The useful question is not “where do we store the agent's keys?” It is “how do we stop the agent ever holding one?”
Four ways agents leak that ordinary services do not
Everything can become a prompt
An agent assembles context from files, tool output and error messages. Any of those can contain a credential, and the assembled context is then sent to a model provider. No conventional service has a code path that ships its own environment to a third party as a matter of routine.
Logs are verbose by necessity
Debugging autonomous behaviour requires knowing what the agent saw and why it chose what it chose. That pressure pushes toward logging more, and more is exactly how secrets reach a log aggregator that a much wider group can read.
Agents write files, and files get committed
An agent authoring code can author a credential into it. A commit takes seconds and a public repository takes seconds more. This is the fastest path from private mistake to public one that exists.
Nobody is watching in real time
A leaked key from an unattended agent may be valid for weeks before a human looks. The absence of a person in the loop removes the fastest detection mechanism most systems actually rely on.
What actually helps, in order
Roughly in order of how much they buy you. The first is worth more than the rest combined.
Do not give the agent the key
By far the strongest control, and the only one that is structural rather than behavioural. If the agent never possesses the secret, no amount of careless logging can expose it. Give it a capability instead — a signature, a scoped token, a proxied call.
Sign, do not share
For anything cryptographic, send the payload to the key rather than the key to the agent. The requester receives a signature and never the material. This turns a permanent compromise into a temporary one: an attacker can obtain signatures while access lasts, but cannot walk away with something that outlives revocation.
Scope per agent and per task
A credential that does one job means one compromise costs one job. Broad credentials are how a small incident becomes a total one.
Rotate on a schedule and on suspicion
The control that works after the others have already failed. Rotation bounds the useful life of a leak nobody has detected.
Record every access
Who asked, for what, when, and whether it was allowed. You cannot investigate what you did not record, and “we think it was fine” is not an incident response.
Make client-side exposure a build failure
Anything a frontend framework marks as publicly exposed is public. This should fail the build, not the review — reviews are where tired people approve things.
Is an environment variable good enough?
For a conventional server process, environment variables are a reasonable baseline and most of the industry runs on them.
For an agent they are weaker than they look, for the first reason on the list above: the agent's own error handling and context assembly can surface the process environment into a prompt or a log line. The variable is not the weakness — the agent's habit of reading everything around it and forwarding it somewhere is.
Where this lands
Vault is built on the first rule: keys stay encrypted, and an agent receives access or a signature rather than the secret. More on secret management for AI agents.
Doppler and Infisical are excellent and mature at a related but different problem — syncing configuration into applications and CI. If that is what you need, they are likely the better fit, and running both is entirely reasonable.
The same principle runs through Empyre itself: each generated company has an encrypted environment vault where the agents working on the product can see key names but never values, and the platform-managed keys cannot be read or overwritten at all.
Frequently asked questions
How do AI agents securely store API keys?
The safest answer is that they do not. Keys live in a dedicated service and the agent receives a short-lived scoped token, a signature, or a proxied call. If an agent must hold a key, scope it narrowly, expire it quickly, rotate it, and keep it out of logs and prompts.
How would I know if a key leaked?
You need recorded access and an alert on unusual patterns — an agent requesting a credential it has never used, or at a rate it never has. Without a record you are relying on the provider noticing before you do.
Is this not just secret management with extra steps?
The storage part is the same. The difference is the threat model: conventional secret managers assume the consumer is a well-behaved process, while an agent is a process whose entire job is to read its surroundings and forward them to a model. That assumption change is what makes signing-instead-of-sharing worth the extra step.
Try Empyre free
Describe a business in plain words and watch eight AI agents build and deploy it. The first build is free — no card required.