how-to-store-secrets-in-an-agentic-world

Someone recently asked a very good question:

How should we store secrets when agents are running the automation?

It sounds like a small implementation detail, but I think it is one of the important architecture changes in the move from traditional software to agentic software.

Until recently, the rule was relatively simple.

If your application needed a secret — an API key, a database password, a token, access to PII, or sensitive business data — you stored it somewhere outside the code. Usually as an environment variable, sometimes in a secret manager. The application loaded it when needed, used it, and that was that.

This worked because the application did not “think.”

The code executed a path written by a human. The secret was used by deterministic software. You still had to protect it, obviously, but the secret was not being handed to a reasoning system that might inspect it, summarize it, log it, copy it, or include it in context.

Agents change that.

Imagine you want to automate a simple daily task:

“Look up last week’s revenue from the database.”

The unsafe version looks something like this:

1. The agent receives the task.
2. The agent writes the SQL query.
3. The agent loads the database credentials.
4. The agent uses the credentials to query the database.
5. The workflow continues with the results.

At first glance, this looks fine. It is basically what software has always done.

But it is not the same thing.

Because now the entity touching the secret is not just an application. It is an agent with a context window, tool access, logs, intermediate steps, retries, summaries, and possibly user-provided instructions.

If the agent can read the secret, the secret can accidentally become part of the agent’s context, traces, or logs. And if any of those leak, the secret leaks with them.

This is exactly why OWASP lists prompt injection and sensitive information disclosure as core risks for LLM applications.

This becomes even worse when the agent is customer-facing, exposed to the web, or connected to untrusted input. At that point, prompt injection is not a theoretical attack. A malicious user does not need access to your infrastructure. They only need to convince the agent to use its tools in a way you did not intend.

So the problem is not only:

“Where do I store the secret?”

The better question is:

“Why does the agent have direct access to the secret at all?”

A safer pattern is to split the system into two parts:

The agent reasons.
The service executes.

The agent should decide what it wants. It should not hold the credentials required to do it.

For example:

1. Store the secret in a secret manager or in the environment of a trusted backend service.
2. Build a narrow tool or service that performs the sensitive operation.
3. Let the agent call that tool instead of calling the database directly.
4. The tool loads the secret, performs the operation, filters the result, and returns only what the agent is allowed to see.

Now the workflow looks like this:

1. The agent receives the task: “Look up last week’s revenue.”
2. The agent prepares a request.
3. The agent sends the request to db_service.
4. db_service loads the database credentials.
5. db_service queries the database.
6. db_service sanitizes the result.
7. The agent receives only the approved result.
8. The workflow continues.

This looks like a small change, but architecturally it is a big one.

The secret never enters the agent’s context.

The agent cannot print it.
It cannot summarize it.
It cannot accidentally paste it into a log.
It cannot leak it after a jailbreak.
It never had the secret in the first place.

And once you introduce this service boundary, you can do more than just protect credentials.

You can enforce read-only access.
You can block dangerous queries.
You can allowlist specific tables.
You can remove PII columns before the result reaches the agent.
You can limit the time range.
You can cap result size.
You can audit every request.
You can reject select * from sensitive tables, even if the agent asks for it very politely.

This is the part that matters most:

A secret manager protects secrets from developers and code repositories.
A service boundary protects secrets from the agent itself.

Those are not the same thing.

If the agent can call the secret manager and retrieve the key, then you have not solved the problem. You have only moved the key.

The safe design is not:

“Agent plus better secret storage.”

The safe design is:

“Agent without direct secret access.”

For simple cases, this boundary can be a function.
For more sensitive cases, it should be a separate service.
For agent ecosystems, it can be exposed as an MCP server or a credential proxy.

The principle is the same:

Don’t give the agent the key.
Give the agent a capability.

And make that capability narrow, audited, revocable, and boring.

There are already tools starting to appear around this pattern. One example is AgentVault by Infisical, which works as a credential proxy for agents. Instead of giving the agent credentials directly, the agent routes requests through the proxy, and the proxy attaches the credentials when forwarding the request.

That is the direction I think secure agent architecture is going.

Not agents with bigger permissions.

Agents with smaller, better-designed interfaces.

The agent should not be trusted just because it is very smart.

It should be useful because the system around it is constrained.