Your AI Agent Is Not a Secret Manager

The best place for a secret is IBM (HashiCorp) Vault. The worst place is an AI agent's context window.

Vault, IBM (HashiCorp), was built for the job: identity-aware access, policy, dynamic credentials, audit trails, rotation, and revocation. An AI coding agent was built to reason over prompts, inspect files, call tools, and summarize results. Giving it an API key does not make it more useful for long. It makes it an accidental secret manager with a transcript, a tool log, local history, and potentially a path back to a model provider.

This is why I built a Vault-backed local broker for VS Code and MCP. The developer signs in with IBM Verify(any oidc provider); the broker gets a short-lived, policy-scoped Vault token; Vault resolves the references; one child process gets the values; and the agent sees only redacted command output. Access is scoped twice: per user, because Vault only answers for the person signed in with IBM Verify, and per project, because the broker resolves only what that project declares.

The challenge is not vaulting a secret. Vault already does that exceptionally well. The challenge is closing the gap between Vault and the agent without turning the agent into another place secrets live and leak.

01Why agents keep getting keys

Vault can store the secret safely. It can also do something a .env file cannot do: issue an ephemeral credential, generated for one job and expired on its own when the job is done. That is where Vault shines.

The trouble is how easy the other path is. You paste the value into the prompt and say "add this to my .env." Or you skip the instruction and let the agent add it for you.
Either way the value is now in the conversation, which means it is part of what goes to a hosted model provider and what gets saved in the transcript. Then the .env gets committed with the next change. Two places for the leak.

Let's see some common reasons, and you will admit these are all true..dont lie ;)

• "It's going in .env, and .env is in .gitignore." Until the agent writes a .env.local, a test fixture or a config file that is not on the ignore list, or stages everything with git add -A. And the ignore file does nothing for the copy that is already in the prompt.
• "The agent needs it to run the test." The process needs it. The model does not, and once the value is in the prompt, the model has it whether it needed it or not.
• "It's only a dev key." Dev keys reach real Jira projects, real LLM billing accounts, and databases loaded with copied production rows.
• "Vault is more work." It is, if using Vault means opening another console, finding a path, copying the value, and pasting it into the same chat anyway.
• "I'll rotate it later." The numbers below say how that usually goes.

A platform team can mandate Vault in policy, and an auditor can write "secrets are managed in Vault" in a control description, but neither makes Vault easier than pasting a value into a prompt. Frictionless path is what we need. This is what I built.

GitGuardian's 2026 State of Secrets Sprawl report counted 28.6 million new secrets in public GitHub commits in 2025, up 34%, the largest single-year jump they have recorded. Secrets tied to AI services rose 81%. Commits co-authored by Claude Code leaked secrets at about 3.2%, against a 1.5% baseline.

That last tile is the "I'll rotate it later" answer. The Verizon DBIR 2025 put credential abuse as the top initial access vector at 22%, with a median of 94 days to remediate a secret leaked to GitHub.

02Why an agent is a terrible secret manager

Paste a key into an agent session and you have appointed the agent your secret manager, whether you meant to or not. It is a bad one, for reasons most people miss even after they have looked at the numbers.

• Agent context can leave the device. Depending on the coding tool, model provider, configuration, and deployment, content the agent reads may be included in model requests, tool context, or locally persisted history.
• The transcript outlives the paste. Coding agents keep conversation history on disk as plain text so a session can resume. A key you pasted in March is still in a JSONL file in October.
• It reads .env without asking. Knostic documented Claude Code loading project .env files into memory without saying so. You never pasted the key, and it can still end up in a model request.
• Its commands inherit your shell. Every command the agent runs starts with your environment: GITHUB_TOKEN, cloud keys, whatever your profile exports.
• Its configs get committed. MCP server docs tell you to put a token in a file that is meant to be committed. Hush Security looked at about 82,000 public MCP configs and found a hardcoded literal in 12% of credential slots, and 243 configs where the secret had been removed but was still in Git history.
• Shared keys erase attribution. One "team dev key" used by ten people and four agents means the audit log says the same thing for all of them. When it leaks, there is nobody to ask.
• It can be talked into anything. An attacker no longer needs malware that knows where keys live. They need a sentence that persuades an agent to read a file it already has access to.

03Ultimately this is what we want: use not read

This is the responsibility model the rest of the post builds on.

The goal is not "give the agent Vault access." It is "let the agent request a narrowly scoped execution that Vault authorizes and the broker performs." That distinction determines where the secret is allowed to exist.

04Vault manages secrets. The agent runs work.

Vault already solves the storage, policy, identity, audit, and lifecycle parts of secret management.

Most easy integrations break the separation. The Vault CLI prints a value into a terminal the agent can read. A typical Vault MCP server returns a value as a tool result. A generated .env file leaves the secret where the agent can load it. Shell injection gives it to every process the agent starts.

The agent now has a credential in its context, its transcript, its tools, or its inherited environment.

I wanted a different pattern: the agent requests a command; an identity-aware broker resolves only the required Vault references; a short-lived child process receives the values; and the agent gets only the exit code and scrubbed output. The result is a VS Code extension plus a small local MCP server, called Vault dev broker.

Sign in

OIDC authorization code with PKCE against IBM Verify, as a public client. It opens the browser, so MFA and passkeys work the way they already do for that developer. Tokens go into VS Code SecretStorage, which is the OS keychain. There is no Vault username or token to hand out: the broker presents the Verify JWT to a standard jwt auth mount and gets back a 30-minute Vault token under a policy templated on my sub.

Store a secret in Vault

So how easy? literally in vscode Cmd+Shift+P, type "store", give the secret a name, type the value into a password box. It goes straight to your personal path in Vault and the plugin puts the matching reference line on your clipboard, ready to paste into .env.vault. The value never lands in the workspace, the chat or the transcript. Adding a secret costs about the same keystrokes as pasting it into the chat, which was the whole point.

So when the agent says it needs the Jira token, type use vault_run. What the project keeps is a .env.vault file. It contains references rather than values and can usually be committed, provided the Vault paths, environment names, and other reference metadata are acceptable to expose to repository readers:

Scoped to one user and one project

Two boundaries decide what a vault_run can touch, and they are enforced in different places.

Per user, enforced by Vault. The broker logs in with the IBM Verify token of whoever is signed in, and Vault maps that token's sub to an identity. The policy is templated on it: that user can read and write under secret/dev/users/<their sub>/, read the team's shared path, and nothing else. My personal vault secret or value is invisible to anyone else, even with the same plugin, the same project and the same .env.vault. "Store a secret in Vault" always writes under the signed-in user's own path.

Per project, enforced by the broker. vault_check and vault_run resolve only the references in the open project's .env.vault, under the workspace root, and the child process receives only those values. 

The user boundary is a Vault policy; the project boundary is broker behavior. Nothing in Vault today stops a second project's .env.vault from referencing any shared path that same user may read. 

The missing piece is a developer workflow that lets an agent use Vault-backed access without ever receiving the underlying credential. One instruction in CLAUDE.md, AGENTS.md or Copilot's instructions file tells the agent how to behave:

The broker also runs outside VS Code as a plain stdio MCP server, so the same setup works in Claude Code, Cursor, Windsurf and IBM Bob, and because it discovers its endpoints from the issuer it works with any OIDC provider. I have proven it with Okta as well as IBM Verify.

05What the agent can do

The agent can do exactly four useful things:

• Request a command. vault_run takes a command line, nothing else.
• Validate references. vault_check reports which entries in the current project's .env.vault resolve for the signed-in user, as JIRA_API_TOKEN, never with a value. vault_init creates a starter file.
• Manage the session. vault_signin and vault_signout start and end the developer's sign-in; the developer finishes it in the browser.
• Receive the result. The exit status and the command's output, with any resolved value that appears in it replaced by [redacted].

A session where we are adding some new build or functionality...it needs a key/value. The agent calls vault_check, sees WHATERVER_API_TOKEN, then calls vault_run with npx tsx scripts/build-new.ts. The broker reads the references as the user signed in, spawns the command with those values plus an allowlisted environment (PATH, HOME, locale and a few others), and returns the scrubbed output. Because the policy is templated on my sub, the Vault audit log names a person for that read rather than "the dev key."

06What the agent must never do

The last line matters more than it looks. The only thing the plugin ever puts on the clipboard is a reference, the .env.vault line, never a value. 

07Operating this pattern at enterprise scale

At enterprise scale, Vault becomes more than a secure place to store values. It becomes the policy, identity, audit, and credential-lifecycle control plane for developer tools, workloads, and agents.

The question is not whether an AI agent should manage secrets. It should not. The question is whether thousands of agentic AI users (think marketing/design, development, engineering, and even executive-level users) using their agents can request narrowly scoped, short-lived Vault access without having to recreate a credential-copying workflow at every editor and terminal. Vault Enterprise is the deployment. 

Already running Vault Enterprise? This drops in.

If your platform team already operates Vault Enterprise or HCP Vault Dedicated, the broker needs no new infrastructure. It needs three things the Vault team already knows how to create: a jwt auth mount that trusts your identity provider's issuer (IBM Verify, or any OIDC provider such as Okta or Entra), a role bound to the broker's audience, and a policy templated on the user. The plugin has a namespace setting, so it lands in whichever namespace your team already uses; HCP Vault Dedicated's admin namespace works the same way. Every read then flows through the audit devices, 

On the developer side it is one broker for every harness, so the same .env.vault, the same sign-in and the same Vault policy follow the developer from tool to tool:

For a platform team that already owns Vault, the whole rollout: configure auth once on the Vault side, hand developers the extension or the broker, and every harness they use asks Vault for the signed-in user instead of asking the developer for a key.

Every team wants its own secrets, policies and identity provider mount. Namespaces give each business unit or platform team an isolated tenant inside one control plane. The plugin already has a namespace setting, so the same .env.vault grammar and the same sign-in work whichever namespace a developer's secrets live in.

Namespaces are also where the project boundary moves out of the broker and into Vault. Give each project its own path and policy, a role per project or a namespace per team, and Vault itself refuses a read from a project that has no business with that secret. Then a secret is available only to the signed-in user, only for the project it was issued to, and both answers come from Vault's policy and audit log rather than from a convention on a laptop.

At that scale somebody will leak something, and the question becomes how long it works afterward. The GitGuardian figure says the honest answer for static keys is years. A vault+dyn:// reference instead asks for a database credential generated for this command, and the lease TTL is the backstop when revocation does not happen. The best secret to leak is one that already expired.

Then there is the evidence. Vault's audit devices record every read, by whom, from which auth mount, and ship it to your SIEM for real-time action; use IBM Antenna; use IBM Identity Protection. We can combine these for true ITDR and ISPM.

The keys already pasted need a different tool. Vault Radar scans Git, CI/CD, Jira, Confluence and Slack for them, blocks new ones at pre-commit, and imports what it finds into Vault for rotation. It has an IDE extension, and HashiCorp's docs call out AI-introduced hardcoded secrets by name.

And the agents themselves. Vault 2.0 adds workload identity, OIDC federation to AWS, Azure and GCP and SPIFFE JWT-SVIDs, so workloads and agents can stop carrying static cloud keys at all. That is the road the plugin's next step runs on: an actor token for the agent, a JWT-SVID issued by Vault, so the broker acts as a named agent on my behalf instead of as me.

08Finding agents and secrets outside Vault

That is the job of IBM Identity Protection, the product formerly named IBM Verify Identity Protection, built on AuthMind's technology. It is agentless. It builds an observed picture of what human and non-human identities actually do, from network flows and identity provider events, rather than from what the configuration says they should do. IBM positions it as ITDR plus ISPM: it surfaces shadow assets, unauthorized local accounts, missing MFA, and secrets scattered across managers that nobody consolidated.

Next to Vault and the broker, these are the questions I want it to answer, each one something the first two layers cannot know:

• Who is going around Vault? An LLM provider called with a static key from a host that never authenticated to Vault is a shadow path. AuthMind describes detecting Vault authentication bypass and secrets still in use after they expired or were rotated.
• Which agents exist that nobody registered? AuthMind says its September 2026 release discovers unknown and shadow AI agents from network traffic. Those are the agents running on a pasted key.
• Who is sharing a secret? One credential used by several identities or from several machines is the OWASP NHI9 "reuse" risk, invisible from inside the vault.
• Which non-human identities have outlived their owner? Improper offboarding is NHI1 on the OWASP Non-Human Identities Top 10 and long-lived secrets are NHI7. With CyberArk counting 82 machine identities per human, nobody is reviewing these by hand.

Observation is half of it. Using IBM Identity Protection is the way to find all agents and all agentic AI usage. IBM's September 2026 Agent Identity preview describes Agent Identity receiving risk signals from IBM Identity Protection via the Shared Signals Framework, with Vault issuing short-lived credentials just in time, so a shadow-agent finding becomes a revoked session rather than a ticket in a queue. That is the kill path from Shared Signals and the Kill Switch.

09Whats next? What should you do?

• Grep your own transcripts. Search your agent history folders for sk-, ghp_, AKIA and xoxb-. Rotate whatever you find, then delete the history.
• Get keys out of mcp.json. An MCP server that needs a token should get it from your identity provider or a vault at start-up, never from a committed file.
• Write the rule into the agent's instructions. "Never ask me for a key" is one line in CLAUDE.md or AGENTS.md, and the agents I use respect it.
• Make storing a secret one command. Whatever tool you use, measure it against Cmd+V. If it loses, people will paste.
• Turn on observation before you need it. Inventory non-human identities and watch for shadow agents now, so the first time you look is not during an incident.

AI agents did not create secret sprawl. They make it easier to be more productive...to be a bit lazier: paste the sensitive value, run the task, worry about it later.

The answer is not another policy telling developers to be careful. It is a workflow that separates responsibilities. The agent requests work. Vault owns the secret. A broker resolves it for one constrained execution. Identity protection finds the people, agents, and credentials still going around the system.

Your AI agent is not a secret manager. Do not make it one.

Sources

• GitGuardian, State of Secrets Sprawl 2026 (March 2026) and 2025 (March 2025)
• Hush Security MCP credential exposure report, via Help Net Security (September 2026)
• Knostic, Claude Code and Cursor .env leakage (December 2025)
• Wiz, s1ngularity supply chain attack (August 2025); CISA, npm ecosystem compromise (September 2025)
• Invariant Labs, GitHub MCP exploited (May 2025); LiteLLM, security update (March 2026)
• Verizon DBIR 2025, as summarized by GitGuardian; CyberArk 2025 Identity Security Landscape
• OWASP Non-Human Identities Top 10 (2025)
• HashiCorp, Vault Radar GA and Radar IDE extension; Vault Enterprise namespaces, audit devices, Sentinel
• IBM, Identity Protection; IBM Community, Agent Identity public preview (September 2026); AuthMind, agentic AI and NHI protection with IBM Vault (September 2026)

The Verify Vault plugin described here is a personal prototype for testing and demonstration. It is not an IBM product and is not supported by IBM.

The source code for the VS Code plugin and the Vault dev broker is on GitHub: github.com/iamidentity-ai/vscode-verify-vault.