For most of software development history, secrets management had one job: keep credentials out of the wrong hands. Encrypt them at rest, restrict access by role, rotate them on a schedule, audit who retrieved what and when.
That model worked because the applications retrieving credentials were deterministic. They did exactly what their code said, they did not read external documents and act on them, they did not process content from the internet and change behavior based on what they found. The application was trusted by definition, you wrote it, you deployed it, you knew what it did.
That assumption has quietly stopped being true for a large and growing portion of how developers work today.
What Changed
You are probably using an AI coding assistant. Claude Code, Cursor, GitHub Copilot, or something similar. It reads your codebase to help you write better code, which means it reads your project directory, which means it has access to every file in it. Your .env file is in your project directory.
This is not a hypothetical. Open any AI coding assistant right now, ask it to help you debug an API authentication error, and watch it read your environment configuration. It is doing exactly what it was designed to do. The problem is not the tool, the problem is that the old secrets management model never anticipated a trusted collaborator that processes untrusted content and acts on what it finds.
That is the coding assistant case. The agent deployment case is more severe.
When you deploy an autonomous agent that calls external APIs, processes documents, browses the web, or handles emails, you have created something that operates in an environment specifically designed to be manipulated. Prompt injection (embedding malicious instructions in content the agent processes) is a documented, reproducible attack. And if that agent holds credential values in memory when it processes a crafted document, the attacker has a target.
The exposure is not at rest, the exposure is at the moment of use, inside the agent, in the space that every secrets manager before this era considered the job already done.
Why the Old Model Does Not Cover This
This is not a criticism of HashiCorp Vault, AWS Secrets Manager, Doppler, or any of the tools most engineering teams are already using. They are excellent at what they were built for. The issue is that they were built for a threat model that assumed the runtime was trustworthy.
Store the credential securely, the application retrieves it, the application uses it, in that model, once the credential is retrieved, it is in the application's memory but that is acceptable because the application cannot be redirected by a malicious instruction in a PDF it was asked to summarize.
An AI agent can be.
The gap is structural. Any system where the agent retrieves the credential value is a system where the credential value exists in a context that can be manipulated. Better storage, stricter access controls, and shorter rotation cycles do not close that gap. They harden the perimeter while leaving the exposure point untouched.
What the New Threat Model Actually Looks Like
The old model:
Secrets store → agent retrieves sk_live_51H... → value in agent memory
→ prompt injection reaches here
→ malicious plugin reads here
→ LLM trace captures here
The moment the value is retrieved, the protection that the secrets manager provided ends. Everything after that point is outside its scope.
The new threat model requires a different answer, one where the agent never retrieves the value at all.
OS keychain → proxy resolves value → injects at transport layer → API response returned
→ agent receives response only
→ value was never in agent context
The agent passes a key name. The proxy resolves the real value from the OS keychain and injects it directly into the outbound HTTP request. The agent sees the API response. The value existed in memory for the milliseconds required to make the call and nowhere else.
This is not a marginally better approach to the same problem, it is a different answer to where the credential lives at the moment of use.
What This Looks Like in Practice
AgentSecrets implements this model. The setup takes about five minutes.
# Install
brew install The-17/tap/agentsecrets
# Initialize and store credentials
agentsecrets init
agentsecrets secrets set STRIPE_KEY=sk_live_51H...
agentsecrets secrets set OPENAI_KEY=sk-proj-...
# Authorize the domains your agent can reach
agentsecrets workspace allowlist add api.stripe.com api.openai.com
From this point, the agent never holds credential values. It passes key names:
agentsecrets call \
--url https://api.stripe.com/v1/balance \
--bearer STRIPE_KEY
The proxy resolves the value, injects it at the transport layer, and returns the API response. Every call is logged with the key name, the endpoint, the status code, and the duration. The value never appears in the log because there is no value field in the log schema.
For AI coding assistants specifically, the credential is no longer in any file the assistant can read. Your .env file can be deleted or emptied. The assistant has full access to your codebase and zero access to your credential values.
The Adoption Gap
The tools most teams are using were not wrong for the era they were built in. The threat model genuinely changed. AI entered development workflows faster than security practices followed it, which means most teams today are using 2020-era credential security for 2026-era AI workflows.
The developers who will feel this most acutely are the ones building the most capable agents, the ones with the broadest access, the most integrations, and the most exposure to untrusted content. The more capable the agent, the more it matters where the credential lives when the agent is doing its work.
Catching up is not a large project. It is five minutes of setup and a different mental model for where credentials belong in an AI-era workflow.
The mental model is this: the credential is not something the agent retrieves and uses. It is something the agent references and the infrastructure uses on its behalf. That distinction is the entire threat model shift, and it is the one most development teams have not made yet.
The full architecture, SDK, and getting started guide is at agentsecrets.theseventeen.co. The repository is at github.com/The-17/agentsecrets.
Top comments (0)