Should an AI agent hold production credentials?

Picture the failure before it happens. An AI agent is asked to clean up a staging database. It hits an access error. It searches the repository for another token, finds one in an old config file, and runs the command with it. The token belonged to production.

Nothing in that story needs a malicious model. It needs a model that is trying to finish its task, and a credential within reach. That is why we think the question “should an AI agent hold production credentials?” has a short answer: no. The rest of this piece explains why, and what to do instead. It is the core of zero-trust AI operations, an open specification: give the AI reach, and keep the keys out of its hands.

Why is a credential in the agent’s reach the real risk?

An agent decides what to do from text. Its instructions are text. So is everything it reads: tickets, logs, commit messages, web pages and the output of the last command it ran. Any of that text can push it somewhere you did not intend.

The OWASP Top 10 for LLM applications is blunt about this. On prompt injection, it says “it is unclear if there are fool-proof methods of prevention”. On what it calls excessive agency, it names excessive permissions as a root cause. Its advice is to enforce authorization in the downstream systems, instead of relying on the model to decide whether an action is allowed.

Put those two together. If you cannot fully stop an agent from being steered, then the only thing that limits the damage is what the agent can reach. A credential in its reach turns a bad instruction into a real change. When an agent does something destructive, the root cause usually sits in the access design, not in the prompt.

Isn’t a read-only, scoped token enough?

It is far better than an admin account. It is still a credential in the agent’s hands, and that brings three problems.

1. Tokens travel. A token the agent holds can end up in its logs, its scratch files, the code it writes and the context it sends to the model provider.
2. A token allows everything it allows. The agent can use it for any call the token permits, not only the call you had in mind.
3. Read access still exposes data. If any part of the agent can reach the internet, a steered run can try to send out what it read.

Scoping still matters, and you should do it. But the stronger design is one where the agent never holds the token at all.

What should the agent hold instead?

Very little. Here is the pattern we recommend, whatever tools you use.

1. Keep credentials in a server-side gate. The agent asks the gate to make a call. The gate holds the credential, checks the request against the permissions of the person who asked, and makes the call itself. The model never sees the secret.
2. Give the run an identity, not a key. If the agent must prove anything to the gate, use an identity bound to that run. The gate should be able to revoke it when the run ends. A long-lived API key in an environment variable is the opposite.
3. Run model-written code with no network. Agents often write code to filter or join what they read. Run it in a sandbox where it can work on the data it was handed and cannot call out. Then a token it stumbles on, or data it holds, has nowhere to go.
4. Release job secrets only after approval. When a change really needs a secret, read it only after a person approves the change. Deliver it only to the host that runs the job.
5. Scope reads to the person who asked. The agent should see what the requesting person may see, re-checked on every call, and nothing more.

This lines up with NIST’s zero trust architecture. It says access “should also be granted with the least privileges needed to complete the task”, and that authorization to one resource does not grant access to another. We apply that to the AI as the requester. Applying NIST SP 800-207 to AI agents goes deeper.

What about the changes the agent needs to make?

Holding no credentials does not mean the agent cannot help with changes. It means a change takes a different path. The agent writes a proposal: the exact change, the reason and the evidence. A person reviews it and approves it. Only then does the gate make the change, with credentials the agent never touched.

That path has to be enforced by the platform, not by instructions to the model. How to enforce human approval for AI changes covers what that takes.

How do you check your own setup today?

Five questions will tell you where you stand.

1. Can the agent’s process read a file or variable that contains a token, password or key?
2. Can code the agent writes open a network connection?
3. If the agent found a production credential, what would stop it from using it?
4. Can anything other than a signed-in person approve a change the agent proposed?
5. Can you show, for a past change, who approved it and exactly what ran?

If the honest answer to the third question is “its instructions”, the credential is the problem to solve first.

How GAEZLA does it

In GAEZLA the AI never holds a credential. Integration credentials stay inside GAEZLA and the platform makes every call to your systems. The model’s process holds no credential either: a bridge on the AI runner attaches a per-run token at call time. That token is bound to its run, case and operator, stored as a hash, expires on its own and is revoked when the run ends.

Calls run with the permissions of the operator who asked, checked again on every call. Code the AI writes runs in a sandbox with no network. When a job needs a secret, the AI sees only the names and labels in your password manager. After approval, the value is sealed to the one enrolled Linux host that runs the job and removed from the output. Every change the AI asks for is drafted as a proposal that an operator approves. The platform does hold the integration credentials, so give each connection a least-privilege account, read-only where you can.

If you want to see that on your own systems, bring one real incident to a 30-minute walkthrough.