offprompt vs HashiCorp Vault

Q: Does offprompt stop the agent reading the file it writes?

No. offprompt writes the key to .env.local, which is on disk, and it does not watch what the agent reads. Every result tells the agent not to open the file and lists the keys it holds, so the agent has no reason to. To enforce it, close the agent’s file tools to the file: a deny rule in Claude Code, .cursorignore in Cursor. Vault addresses this differently, by not putting the value on disk at all; the two tools make different trade-offs.

HashiCorp Vault is secrets infrastructure. A Vault server stores secrets, hands out short-lived credentials that it can revoke, and audits every access, for the services, pipelines and machines that read from it. offprompt is a small MCP server for one moment: a coding agent hits a task that needs a key the project does not have, and instead of asking for it in the chat, it asks offprompt, which opens a page in your browser for you to type the key.

One is a platform a team runs; the other is a single step a developer takes. They do not compete, and they fit together.

At a glance

Question	offprompt	HashiCorp Vault
What it is	An MCP server the agent calls to ask you for a value it lacks, which it writes into the project	Identity-based secrets infrastructure that stores secrets and issues short-lived credentials behind an API
How a value gets in	You type or paste it on a page served from `127.0.0.1`. The agent never handles it	You write it with `vault kv put`, or a secrets engine generates it on demand. An operator runs the server
Where values live	In the project's `.env`, `.env.local` or another file the agent names	In the Vault server's encrypted storage, read through its API under a policy
Dynamic, short-lived credentials	No. It writes a static value you already hold	Yes. Its secrets engines generate credentials on demand, each with a lease and revocation
How code reads a value	From the file, as `process.env.NAME`	Through Vault's API or CLI, or Vault Agent renders it to a file or environment variable
Keeps a value out of the agent's context	Yes. Results carry the key names, the file and a four-emoji fingerprint, never values	Its MCP server (beta) "may expose Vault data, including secrets, to MCP clients and LLMs"; its docs say not to use it with untrusted clients or LLMs
From a cloud sandbox	Yes. A link through a Cloudflare quick tunnel, with values encrypted in your browser to a key only the sandbox holds	The agent needs a Vault token or an auth method wherever it runs
What it needs to run	Nothing. A process the agent starts on your machine	A running Vault server, self-managed or HCP-managed, and an auth method
License and price	MIT, free	BSL 1.1 since 2023: a self-managed Community Edition, plus paid Enterprise. The OpenBao fork is MPL-2.0
Aimed at	One developer getting a key an agent needs into the project	Platforms and services needing audited, automated, short-lived secret access at scale

What each tool's own docs say, as of 9 November 2026. “Not documented” means its docs do not say.

What Vault is best at

Vault's strength is credentials that do not sit still. Rather than keep a long-lived password, a service asks Vault for one when it needs it: its secrets engines generate database, cloud or other credentials on demand, each with a lease and a way to revoke it, so access is short-lived and tracked. Its transit engine does encryption as a service, and its PKI engine issues X.509 certificates.

Around that sit many auth methods, AppRole, Kubernetes, cloud IAM and more, and Vault Agent, which authenticates a workload and renders secrets into files or environment variables. Vault is for an organisation that needs audited, automated, least-privilege access to secrets across its infrastructure. That is a different job from getting one key off a developer and into a project.

When to pick Vault

Reach for Vault, not offprompt, when:

services and pipelines, not people, need to read secrets automatically;
you want short-lived, generated credentials with leases and revocation;
you need a full audit trail of who and what read each secret;
you want encryption as a service or an internal certificate authority.

offprompt offers none of this. It issues nothing, audits nothing and revokes nothing; it writes a static value you already hold into a file, once.

Where offprompt fits

offprompt covers the key that is not in any store yet, the moment a coding agent would otherwise type it in the chat. The agent calls collect_secret with the key's name, why it needs it and the file it goes in; offprompt opens its page on 127.0.0.1, you paste the key, and it writes the file and answers the agent with the key's name and a four-emoji fingerprint. The value is never in a prompt, a tool argument or a tool result.

This matters next to Vault's MCP server in particular. HashiCorp's own docs warn that server, in beta, “may expose Vault data, including secrets, to MCP clients and LLMs,” and say not to point it at untrusted clients or models. offprompt is built so the value cannot reach the model at all.

Its limit is plain: offprompt writes the key to .env.local, and it does not stop an agent that can read files from opening it. Every result tells the agent not to and lists the keys the file holds; to be sure, close the agent's file tools to it with a deny rule in Claude Code or .cursorignore in Cursor.

Using them together

Capture a new key with offprompt so its value never touches the chat, then store it in Vault for the team to read under a policy:

Once offprompt has written the key, on your machine

vault kv put secret/acme-support RESEND_API_KEY=@.env.local   # move it into Vault, then rotate it there

Or start from Vault: Vault Agent can render the secrets a service needs to a file on your machine, which you drop on offprompt's page; offprompt keeps only the keys the agent asked for, so the sandbox holds no Vault token. See Values you already keep.

Sources

What HashiCorp Vault's own docs say, as of 9 November 2026.

Something here out of date? Open an issue on GitHub.

FAQ

Is offprompt an alternative to HashiCorp Vault?

No, and it would be a poor one. Vault is secrets infrastructure: a server that stores secrets, generates short-lived credentials, and audits every access for the services and pipelines that use it. offprompt stores nothing and generates nothing. It covers one moment a coding agent reaches: a task needs a key the project does not have, and rather than paste it into the chat, the agent asks offprompt, you type the key on a page in your browser, and it is written to the file.

Can an AI coding agent use Vault without seeing the secret?

It depends how you connect it. HashiCorp ships an official Vault MCP server, which it marks beta, and its own docs warn it “may expose Vault data, including secrets, to MCP clients and LLMs” and say not to use it with untrusted clients or LLMs. Reading a secret through that path puts the value into the agent’s context. offprompt is built for the opposite: the agent never receives the value, only the key’s name, the file and a fingerprint. Vault’s own answer to an agent using a credential without holding it is Vault Agent, which can inject or template a secret into a process outside the model’s view.

Can I use offprompt and Vault together?

Yes. Use offprompt when a brand-new key first appears, so its value never enters the chat, then store it in Vault with vault kv put for the team to read under a policy. Going the other way, Vault Agent can render the secrets a service needs to a file on your machine, and you can drop that file on offprompt’s page, which keeps only the keys the agent asked for — so a sandbox never holds a Vault token.

Why would I use offprompt if I already run Vault?

For the key that is not in Vault yet. When you are prototyping with a coding agent and it needs, say, a Stripe test key or a Resend key you just created, going through Vault to store it first is a detour; pasting it into the chat exposes it. offprompt is the short path: the agent asks, you type it, it lands in .env.local, and the value never touches the conversation. Later, move it into Vault for the team.

Does offprompt stop the agent reading the file it writes?

No. offprompt writes the key to .env.local, which is on disk, and it does not watch what the agent reads. Every result tells the agent not to open the file and lists the keys it holds, so the agent has no reason to. To enforce it, close the agent’s file tools to the file: a deny rule in Claude Code, .cursorignore in Cursor. Vault addresses this differently, by not putting the value on disk at all; the two tools make different trade-offs.

Try it

In a project's folder, run the command below, then ask the agent for something that needs a key. The agent calls offprompt when it reaches the step that needs one.

$npx offprompt init

Other comparisons

offprompt vs DopplerDoppler is a hosted secrets manager that syncs one source of truth to every environment and injects it with doppler run. offprompt captures a new key an agent needs without the value reaching the chat.
offprompt vs InfisicalInfisical is an open-source secrets platform with a dashboard, a CLI and an MCP server. offprompt keeps no store; it gets a key the agent lacks into the project’s file without the value entering the chat.
offprompt vs 1Password1Password keeps your team’s secrets in a vault and injects them into commands with op run, never writing them to disk. offprompt captures a new key an agent needs without the value reaching the chat.

Or the three-way look at the MCP servers: offprompt vs 1Password Environments MCP vs Infisical MCP.