What a Credential Vault Needs to Do for AI Agents

A credential vault for an AI agent has to do two separate jobs, and most of the category is only built for the first one. Storing a secret safely, encrypted at rest, rotated on a schedule, access-logged, is the easy half, and plenty of mature products already handle it well. The hard half is getting that secret into an outbound API call without it ever passing through anything the model reads or writes. Get the second half wrong and the first half's encryption doesn't matter, because the secret already left the vault in a form the model could repeat back.

The easy half: storage

Encryption at rest, a key held somewhere other than next to the ciphertext, rotation, and an access log are table stakes, and tools built for this before agents existed, HashiCorp Vault, AWS Secrets Manager, the OS keychain, all do it competently. None of them were designed around the specific failure mode an LLM introduces: a caller that can be talked into repeating back whatever is in its own context window.

The hard half: injection without exposure

Anything in a model's context can come back out. An agent that reads an email, a web page, or a support ticket can meet instructions planted by an attacker asking it to include a key in its reply, and if the key is sitting in a tool argument or a system prompt, the model can comply. A vault built for agents has to resolve the credential after the model has already decided which action to take, and attach it directly to the request on the way out, so there is never a point where the model holds the value at all.

What an agent-ready credential vault actually needs

• No credential arguments in the tool schema. If an API's schema lists the token as an input, that field has to be filled in after the model responds, never by the model itself.
• Resolution after policy, not before. A blocked call should never load the secret it would have needed. Checking policy first means a denied action never touches the vault at all.
• Redaction everywhere, not just in the happy path. Error messages, verbose output, dry runs, traces, and audit logs all need the same redaction as the real request, including credentials sent as query parameters rather than headers.
• Storage outside the repository. Coding agents such as Claude Code and Cursor read the files in a project to understand it. A .env file sitting in the working tree is one more file for them to read.
• Per-tenant selection, not one shared secret. A multi-tenant agent needs the vault to pick the right customer's credential for the right request. Using the wrong one isn't an error the system throws, it's a correct-looking call against the wrong account.
• OAuth refresh without model involvement. A token that expires mid-run should refresh transparently. The model should never see the refresh happen, let alone be asked to help with it.
• An outbound secret scanner as a second layer. Even with everything above in place, a pattern-based check on outgoing messages catches the case where a secret ends up somewhere unexpected, such as an agent pasting what looks like a key into a Slack message.

Generic secrets manager versus agent-ready vault

How Swytchcode's vault works

Connecting a provider, swy auth connect stripe, opens an OAuth flow or prompts for an API key depending on what that provider supports. The credential is written to a local SQLite file in the home directory, outside the project folder, so cloning the repository never exposes it. Resolution order is predictable: environment variables first, then the managed store, then a project-level override, so a production server can take precedence over a local developer setup without a code change. The credential is attached to the outbound request only after schema validation and policy evaluation have already passed, and it never appears in the model's context, a tool argument, or an unredacted log.

# Connect once; Swytchcode decides OAuth or API key per provider
swy auth connect stripe

# Confirm what's connected and how it's authenticated
swy auth status

# Remove a provider from this project only, credential stays in the store
swy auth disconnect stripe --local

FAQ

Isn't a secrets manager like Vault or AWS Secrets Manager already a credential vault?
For storage, yes, and there's no reason to replace that. What it doesn't provide out of the box is the logic that resolves which credential goes with which call, attaches it after policy passes, and keeps it out of everything the model can read along the way. Many production setups keep the secrets manager as the source of truth and add an execution-time layer on top for that part.

Can a prompt injection actually steal a credential from a vault?
Only if the credential is somewhere the model can read it first. A vault that injects the secret directly into the outbound request, after the model has already decided what to call, removes that path entirely, since there's no copy of the secret in context for an injected instruction to repeat back.

Does Swytchcode store credentials in the cloud?
No. Managed credentials live locally in a SQLite file on the machine running Swytchcode. Cloud Sync, which is off by default, uploads audit summaries when enabled and never uploads credentials.

Related reading

• Keep API keys out of the LLM: credential brokering for AI agents: swytchcode.com/content/ai-agent-credential-brokering
• API access control for AI agents: swytchcode.com/content/api-access-control-ai-agents
• Your API, your OAuth app, your rules: swytchcode.com/blogs/your-api-your-oauth-app-your-rules