AI agents have quietly become one of the most privileged things in your stack. A coding assistant reads your repository and runs in your CI. An autonomous agent calls APIs, opens pull requests, and ships code. To do any of it, the agent holds secrets: an ANTHROPIC_API_KEY here, a GITHUB_TOKEN there, cloud credentials, database strings. That combination, broad access plus standing credentials, is exactly what makes AI agents a credential-theft target.
A wave of recent supply-chain attacks made the point directly. Some planted persistence in the config files AI assistants load on startup, so the agent quietly re-ran attacker code on every session. Others used prompt injection: researchers showed an AI code-review agent could be hijacked by a crafted pull request title into printing its own environment, leaking the API keys sitting in the CI runner. The agent did not need to be malicious. It just needed to be holding bearer tokens while reading untrusted input.
This piece looks at why agents have become such a target, and how to give them access to secrets without handing over an API key that turns one bad prompt into a breach.
Why AI agents are a credential-theft target
Three properties stack up to make agents attractive:
- They hold secrets at runtime. Most agents authenticate to model providers, source control, and cloud APIs with API keys loaded from environment variables.
- They process untrusted input. Issues, pull requests, web pages, and files are all attacker-controllable. An agent that reads untrusted text while holding live credentials can be talked into leaking them.
- They run in privileged places. CI runners and developer laptops carry cloud credentials, SSH keys, and publish tokens. Compromise the agent and you inherit all of it.
Prompt injection is the trigger people focus on, and it is real. But injection only pays off because there is something standing there to steal. Take away the standing credential and a successful injection has far less to carry out the door.
The real weak point: API keys in environment variables
Look at what these attacks actually exfiltrate and a single pattern repeats: long-lived bearer tokens, kept in environment variables, .env files, and config. A bearer token is a string that proves nothing about who is using it. Whoever holds it can use it, from anywhere, until someone notices and rotates it by hand.
That is why credential-stealing payloads sweep the environment and .env first. An agent's real power is its keys, and in the usual setup those keys are just text sitting in memory and on disk. The model rewards a smash-and-grab: read once, replay forever.
So the question is not only how to stop your agent from being tricked. It is what an attacker actually gets when an agent is tricked. If the answer is a fistful of portable API keys, you have a breach. If the answer is a scoped identity that cannot be replayed and leaves a signed trail, you have an incident you can contain.
What secure access for an AI agent actually requires
Whatever tool you use, secure agent access comes down to five properties any secrets management setup should give an agent:
- Scoped. The agent reaches only the exact secrets and actions its task needs, never a single token that opens everything.
- No standing bearer token. Authentication that cannot be copied out of an environment variable and replayed somewhere else.
- Revocable and attributable. You can cut the agent off in one step, and every action it took is logged to its name.
- Read-blind where it can be. An agent that manages secrets should not be able to read their plaintext values. You cannot leak what you were never able to see.
- Short-lived. Identities that expire on their own, so a stolen one is a narrow window rather than an open door.
The first four matter most for agents, and read-blind access is the one most setups skip.
How to give AI agents scoped identities instead of API keys
This is the model SikkerKey is built on, and it maps cleanly onto the list above.
Instead of handing an agent an API key, you give it an agent identity. The agent holds a private key (an Ed25519 key) that never leaves its host and signs every request it makes. SikkerKey stores only the matching public key, so there is no shared secret to steal from the server, and no bearer string for an attacker to lift from the agent's environment and reuse elsewhere.
That identity is scoped. You grant the agent only the capabilities its job requires, such as managing a project, rotating a secret, or setting a policy, and nothing more. Every call it makes is signed, timestamped, and written to an audit log under the agent's name, so you can see precisely what it did and revoke it in one click the moment something looks wrong.
The part that matters most for AI specifically: a SikkerKey agent identity is read-blind on secret values. It can create a secret, rotate one, or grant another machine access, but no operation will ever return the plaintext of an existing secret. The value goes in, gets encrypted server-side, and never comes back out through that interface. So even an agent that is fully prompt-injected, or running attacker code from a poisoned dependency, has no stored secret values to exfiltrate through its management access. There is nothing in the till.
The applications your agent builds and operates still need real secrets at runtime, and they get them under a separate machine identity, not the agent's. The runtime SDK fetches each secret into process memory at the moment it is needed, signed with the machine's own key, rather than reading it from a .env file that a stealer can scrape or that an agent can print. The credential is used at the moment of need and never left sitting in the open.
Read-blind agents still fit into your dev workflow
A fair worry at this point: if the agent cannot read a secret's value, can it still help you wire that secret into your app? It can, and this is the part teams are surprised by.
Writing the code that uses a secret only takes knowing which secret to call and how. A SikkerKey agent identity can see each secret's id, name, description, type, and, for structured secrets, its field names. That is everything it needs to generate correct, working code:
// The agent reads the metadata: a secret named DATABASE_URL, id sk_h7wrnhe9e4.
// It writes the runtime call. The value resolves inside the running app, not here.
const dbUrl = await sk.getSecret('sk_h7wrnhe9e4')
The agent scaffolds the SDK calls, points them at the right secret ids, and wires them into your configuration, the same way a developer would. The plaintext only ever materializes at runtime, in the process that actually needs it. It never enters the agent's context, which means it never lands in a chat transcript, a model provider's logs, or a commit. The agent automates the plumbing while the secret itself stays out of the conversation entirely.
What this does and does not fix
It is worth being precise, because no secrets layer is a force field.
This does not stop prompt injection, and it does not stop a malicious dependency from running on your build. Those are real problems with their own defenses (input isolation, egress controls, dependency pinning), and they sit upstream of any vault.
What it changes is the payoff. A hijacked agent holding a god-mode API key in an environment variable hands the attacker everything that key can reach, from anywhere, indefinitely. A hijacked agent with a scoped, read-blind, signed identity hands over far less: no plaintext to read, no portable token to replay, a tight set of actions, and a logged trail you can sever instantly. You are turning a breach into a contained, observable event. That is the whole goal of least privilege, applied to the newest and most over-trusted identity in your stack.
Frequently asked questions
Can a secrets manager stop prompt injection?
No. Prompt injection is an input-handling problem. What a secrets manager can do is remove the standing credential the injection is trying to steal, and limit what a compromised agent is able to reach, so a successful injection produces far less damage.
Where should AI agents store API keys?
Not in committed .env files, and ideally not as long-lived environment variables at all. Fetch secrets at runtime under a scoped identity so they live in process memory only while in use, and never sit on disk waiting to be scraped.
What is the difference between an API key and a machine identity?
An API key is a bearer token, a string that works for anyone who holds it, from any location. A machine or agent identity authenticates by signing each request with a private key that stays on the host, which means it cannot be copied out and replayed, and it can be scoped and revoked on its own.
Can an AI agent help me build if it cannot read my secrets?
Yes. An agent only needs a secret's metadata, its id, name, description, and structure, to write code that references it correctly through the SDK. The plaintext value is resolved at runtime by the running application, so the agent never needs to see it to do its job.
How do I give an AI agent least-privilege access to secrets?
Provision it a dedicated identity, grant only the scopes its task needs, prefer read-blind management access so it can operate on secrets without reading their values, and keep every action attributable in an audit log so you can revoke it instantly.
Give your agents access without the bearer token
AI agents are going to keep getting more access, not less. The safe way to grant it is to stop treating an agent like a user with a password and start treating it like a machine with an identity: scoped, signed, revocable, and unable to read what it does not need to see. SikkerKey gives AI agents exactly that kind of identity, so an agent can do its job without holding a bearer token that turns one bad prompt into a full credential leak.