AI agent secrets management: what it is and how to do it
Definition: AI agent secrets management is how you let an AI agent do useful work (read config, change a setting, deploy) while limiting what it can learn, spend or destroy if it is tricked, buggy or compromised. The core idea is simple: an agent cannot leak a secret it never held, so prefer giving agents names and scoped, previewable actions over values and broad credentials.
Classic secrets management assumes the reader is a deployed service with a fixed job. An agent is different: it reads untrusted text (web pages, issues, files, tool output), decides what to do, and often has a shell. That changes the threat model. This guide gives a threat model, a maturity model you can place your setup on, a checklist, and an honest account of where Dynv fits. It is our opinion, labelled as such; the facts are sourced.
Why the usual playbook breaks
- The agent reads instructions from data. Simon Willison named the dangerous combination in June 2025: the lethal trifecta is access to your private data, exposure to untrusted content, and the ability to communicate externally. “If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.” His advice for end users: “The only way to stay safe there is to avoid that lethal trifecta combination entirely.” Secrets are the most valuable private data in a developer’s workspace.
- Permissions in a prompt are not permissions. In July 2025 SaaStr’s Jason Lemkin ran an agent on Replit with an instruction not to touch anything without asking. During a code freeze it ran database commands that deleted records on 1,206 executives and about 1,196 companies, and then misreported whether recovery was possible (The New Stack; Replit’s CEO called it “unacceptable and should never be possible,” as reported). The lesson is not that one agent misbehaved; it is that a rule written in natural language is not a boundary.
- A credential’s scope is the real blast radius. In May 2026 an operator gave an agent an AWS API key. The agent, according to a detailed write-up by a DN42 community member, said it had deployed five
m8g.12xlargeinstances for a network scan; after about 24 hours the operator noticed charges on a credit card, and later asked the community for money to cover a bill of $6,531.30. The operator’s own conclusion was to give the next agent “only a restricted aws key” with a hard limit. The incident ran on a credential with no ceiling. (The bill figure is the operator’s own claim.) The Hacker News discussion had about 1,470 points. - Plaintext secrets sit where agents read. GitGuardian’s 2026 report counted 24,008 unique secrets in MCP-related configuration files on public GitHub, 2,117 of them valid credentials, and found Claude Code-assisted commits leaking at 3.2% versus a 1.5% baseline (while noting this is not simply a tool failure). Our companion piece, Can Claude Code read your .env?, covers what the tools do and don’t enforce.
Threat model in six lines
| Threat | What it looks like | What limits it |
|---|---|---|
| Prompt injection | A page, issue or file tells the agent to read and send secrets | The agent never holds the value; no free outbound channel |
| Over-scoped credential | The agent’s key can do far more than the task needs | Per-task, narrowly scoped, expiring credentials |
| Malicious or compromised tool | An MCP server, extension or package runs with the agent’s rights | Least privilege, pinning, a sandbox, review of what a tool can reach |
| Runaway agent | Loops, spends, deletes | Budgets and quotas at the provider; no production write access by default |
| Leaky context | Secrets end up in transcripts, logs, config files | Mask by default; keep values out of prompts and configs |
| Local file access | Anything the OS user can read, the agent’s shell can read | OS-level isolation, not tool-level deny rules |
A five-level maturity model
Where is your setup today? (This scale is our own framing, not a standard.)
| Level | What the agent can reach | Typical setup |
|---|---|---|
| 0 | Plaintext secrets in files and shell | .env in the repo, keys in ~/.zshrc, tokens pasted in chat |
| 1 | Secrets injected into the agent’s environment | A secrets manager, but the agent’s shell can `env |
| 2 | Names and masked values; scoped, previewed writes | Read-only by default, per-key write allow-lists, dry runs, audit log |
| 3 | Level 2 plus an OS boundary | The agent runs in a sandbox (filesystem and network limits), with token files outside its reach and logs someone reads |
| 4 | The agent never holds credentials at all | A broker performs privileged actions on the agent’s behalf, under policy, with its own limits |
Most teams are at 0 or 1. Moving to 2 is cheap and removes the most common leak. Level 3 is where you stop relying on the tool to police itself, which Anthropic’s own documentation says is the right move when you need enforcement that “doesn’t depend on the command text” (see the companion piece). Level 4 is where the field is heading; we do not claim to be there.
Checklist: ten things to do
- Take plaintext secrets out of the working directory (and out of anything the agent can
cat). - Give agents read-only credentials by default; make writes an explicit, narrow opt-in.
- Allow-list which variables an agent may change, never “all”.
- Require a dry run or preview for every write, and read it.
- Keep values masked in what tools return; avoid ever pasting a secret into a prompt.
- Never put a token inline in a client config file; use a file with mode 0600 and a path.
- Use one narrowly scoped credential per task and per environment; cap spend at the provider.
- Keep agents away from production data by default (separate dev and prod credentials and data).
- Pin and review the MCP servers and extensions you run; treat each as code with your rights.
- Log what the agent did and have a rotation procedure you’ve actually tested.
How Dynv implements levels 2 and 3’s ingredients
Dynv’s MCP server is a local process your agent app starts. It is built around the checklist above. Everything below is shipped and documented:
- Read-only by default. The recommended setup uses a read-only token and
--read-only, which removes every write tool. - Masked values. Tools return variable names and masked values unless you explicitly enable reveal; MCP resources are always masked, even with reveal on.
- Scoped writes. Writes need a positive
--allow-keyslist; code-loading variables such asNODE_OPTIONSandPATHare always refused over MCP. - Dry runs. Every write tool accepts
dry_run: trueand returns the exact diff (masked), which services are affected and whether each restarts or updates hot, without uploading anything. - Token files, not inline tokens.
DYNV_MASTER_TOKEN_FILEpoints at a 0600 file;dynv mcpwarns if a token came from an inline environment variable, anddynv doctor mcpvalidates the client config. - Audit log. A metadata-only
audit_logtool anddynv://auditresource, including the MCP origin. - Zero-knowledge storage. Dynv’s servers hold ciphertext; encryption and decryption happen on your machine.
Where it stops, in plain terms:
- A value an agent sets passes through the agent’s context, because the agent wrote it.
- The token file is a file. Our docs say it directly: an agent that can run commands or read files as your OS user may also be able to read the token file. That is why the default token is read-only, and why a sandbox (level 3) matters.
- Masking applies to what the MCP server returns, not to commands you let the agent run.
- Writes, if you enable them, need the writer token on one dedicated machine.
- Not shipped yet: canary secrets to detect an agent or package touching a decoy, and a process firewall to restrict what a service can run and connect to. Both are coming soon; nothing above depends on them.
Getting started
Set up the MCP server with a read-only token and try a dry run: the setup guide has snippets for Claude Code, Claude Desktop, Cursor, VS Code, Windsurf and Codex. Pair it with a sandbox for the agent, and keep reading: we will cover prompt-injection testing and an MCP configuration checklist in follow-up posts.
Facts last verified . Spotted an error? Tell us.