Gareth MorgansSecurity
Secrets sprawl in AI teams
Secrets sprawl is what happens when API keys and tokens land everywhere an AI team works: chat threads, local env files, shared docs, individual agent configs. Nobody meant to scatter them. The work just moved faster than the inventory.
That is not a vault. That is copies.
Start free beta · Secrets vault
Related: agent credentials without pasting keys · stop pasting API keys into AI chat · add and use secrets
What secrets sprawl looks like
A key pasted “just for this run” sits in chat history. Another lives in a .env on someone’s laptop. A third sits in a shared Notion page. A fourth is hard-coded in an agent package someone exported last month.
Each copy feels temporary. Together they are secrets sprawl: the same credential in more places than security can name.
If you cannot list where a key lives, you do not control it.
The cost of sprawl
Leak risk. Every copy is another place a screenshot, export or shared thread can expose the value.
No inventory. When finance or security asks which keys the AI team uses, the honest answer is a guess.
Hard rotation. Changing one vault entry is easy. Hunting every chat paste, env file and package copy is not.
Shadow copies. People keep personal backups “in case the shared one breaks.” Those backups outlive the original.
Secrets sprawl turns a single credential into a scavenger hunt.
One vault, refer by name
Put working credentials in a secrets vault. Refer to them by name in skills, prompts and workflows.
Secrets are private by default. Share with a group or the organisation when you choose to. Being able to use a secret is separate from being able to view or manage it.
This vault is for AI work: keys used by skills, agents and MCP workflows. It sits alongside infrastructure tools. It does not replace them. For the comparison angle, read secrets management tools for AI agents.
Practical steps: add and use secrets.
Packages and configs without values
Agent packages and shared configs should carry secret name hints. Never the credentials themselves.
The package says which named secrets the setup expects. The vault holds the values. Someone with the right rights can update a value without rewriting every copy of the package.
The same rule applies to MCP connections: link catalogue endpoints, never tokens. Authentication for live tool calls stays with the host client and the vault.
See agent credentials without pasting keys and the agents overview.
Controlled substitution at use time
Storage alone does not end secrets sprawl. The value still has to reach an HTTP call or tool without landing in the chat the model sees.
Controlled substitution is designed to inject vault values on the server at use time. The workflow refers to the secret by name. The raw key is designed to stay out of model context.
That is a design goal, not a promise that no system anywhere can ever observe a value.
Audit on connect, publish and change
When someone connects a server, publishes a package or changes a secret, record it.
Audit on connect, publish and change gives security teams a trail of who altered the catalogue. It is not a log of every tool call at runtime. There is no runtime gateway proxying live third-party MCP calls today.
For build-time controls around agents, see AI agent security.
Soft path out of sprawl
If credentials are already scattered:
Stop pasting new keys into chats, docs and package text.
Inventory the keys your AI workflows actually need.
Move those values into the vault.
Rewrite packages and configs so they use name hints only.
Rotate anything that lived in a shared thread or export.
Next steps: secrets vault, controlled substitution, API key best practices and stop pasting API keys into AI chat.
FAQ
What is secrets sprawl?
Secrets sprawl is when API keys and tokens are copied across chats, local env files, shared docs and agent configs, so no one has a single inventory of where they live.
Does a vault stop secrets sprawl on its own?
No. You also need name-based references, packages that never carry values, and the discipline to stop creating new copies. The vault is the store; the references are the habit.
Is this the same as infrastructure secrets management?
No. Infrastructure tools protect production systems. A vault for AI workflows holds the credentials agents and tools use day to day, with private-by-default sharing and name-based references.
Does this block unapproved tools at runtime?
No. There is no runtime gateway that filters live tool calls. Controls sit at build time: vault references, catalogue links, permissions and audit on change.