Secrets, keys, and why AI agents make this harder to ignore

For a long time, secret management for a solo developer or small team looked like this: a .env file in the project root, something in .gitignore, and a prayer. Maybe a shared password manager entry for the production values. Credentials lived on the machine, in CI environment variables, or in someone’s head.

This was always a bad pattern. It is now a significantly worse one.

What changed

AI agents are tools that act on your behalf. They call APIs, read from databases, write files, execute code, send messages. Every one of those actions runs on a credential: an API key, a database connection string, an OAuth token, an SMTP password.

An agent that can browse the web and call tools also needs credentials to do anything useful. Which means credentials now flow through more systems, get passed in more prompts, and exist in more log files than they did when you were the only one executing code.

The attack surface is bigger. The failure modes are weirder. Prompt injection is a real category of exploit. Malicious content in a web page or document can try to hijack what the agent does next. If the agent has a credential in its context window, prompt injection has a way to try to exfiltrate it.

This is not hypothetical. It is the kind of thing that happens when you give an AI agent more access than it needs.

Infisical as the baseline

I use Infisical across my stack: Serenity, Tutorbin, Vent Busters, and personal infrastructure. The short version of why: secrets live in one place, they are injected at runtime, and nothing that runs on my servers has credentials baked in.

Instead of an .env file that someone could read off a disk or find in a backup, each service gets its secrets from Infisical at startup. A Coolify deployment pulls the right secrets for the right environment. A development machine pulls a separate set. Nothing leaks between environments. When a key rotates, it rotates in one place.

This is the baseline I would recommend to anyone running a production service. Self-hosted Infisical is free, the setup is a few hours, and the ongoing maintenance is close to zero.

Agent Vault

Scoped tokens are the right baseline. But the Infisical team built something that goes further: Agent Vault, a separate open-source project purpose-built for AI agent credential security.

The problem it solves is specific. An AI agent that holds an API key in its context window can be tricked into leaking it. Prompt injection can come from a web page, a document, or a tool response. If the key is in the environment, the agent can read it. If the agent can be manipulated, the key can be exfiltrated.

Agent Vault removes the key from the agent entirely.

It runs as an HTTPS proxy on your infrastructure. Agents route outbound requests through it by setting HTTPS_PROXY=agent-vault:14322. Instead of real credentials, the agent uses placeholder values like __anthropic_api_key__. When the request passes through Agent Vault, the proxy substitutes the real credential before forwarding to the target API. The agent makes the call, the API gets a valid key, and the agent never saw the actual value.

The management interface handles which agents get access to which endpoints. You can restrict a coding agent to GitHub and Anthropic only. An appointment agent gets the booking API and nothing else. Egress filtering is built in. If the agent tries to reach something it has no business reaching, Agent Vault blocks it.

The request log is also more useful here than in a traditional setup. Because all authenticated traffic flows through the proxy, you can inspect exactly what each agent called and when, with the real credentials never appearing in the log.

Outside of Agent Vault, the rule is still the same: agents should get the minimum access they need. A booking agent does not need database credentials. It needs an API token scoped to the booking endpoint, expiring if unused. When that token is eventually compromised, and you should plan for that, the blast radius is one API instead of your database.

What the log tells you matters as much as what the agent does

One of the underappreciated benefits of centralized secret management is the audit log. Infisical logs every time a secret is accessed, by what, from where. When something goes wrong, and in a system with AI agents calling tools something eventually will, you want to answer one question quickly: what touched that credential and when.

A .env file has no audit log. A rotated key with no log of who used the old one before rotation is just hope.

The short version

If you are building with AI agents:

• Secrets belong in a secrets manager, not in .env files, not in prompts, not in logs.
• Agents should get scoped, expiring tokens, not master keys.
• If prompt injection exfiltration is a real concern for your setup, look at Agent Vault. Agents that never hold the real credential cannot leak it.
• Log what touches what. You will need it.

The tooling to do this correctly is not complicated or expensive. Infisical handles the baseline for any service. Agent Vault handles the specific problem of credentials in AI agent context windows.

---

I run Infisical across my entire stack. Agent Vault is a separate open-source project from the same team. It is worth reading if your agents can touch real systems. For the broader question of whether AI-written code is actually secure, see the wrong answer I gave about AI coding security.