Your secrets are visible
to every AI tool.

Lockbox stores secrets in a binary format that AI coding assistants, grep, cat, and ripgrep cannot read. Your API keys stay on your machine but become invisible to anything that reads text.

The problem

Your .env file is plaintext. You know to add it to .gitignore, so it never reaches GitHub. Good. But that does not protect you from AI tools.

When you open a project with an AI coding assistant, the assistant reads your workspace files to build context. That includes .env. Your database password, your Stripe secret key, your AWS credentials: they all land in the AI's context window. Every tool that can read text can read your secrets.

STRIPE_SECRET=sk_live_4eC39HqLyjWDarjtT1zdp7dc
DATABASE_URL=postgres://admin:s3cret@db.example.com:5432/prod
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

(binary data: not text, not base64, not readable by any text tool)

The .env file is gone. The secrets still exist on your machine, inside a binary lockbox that text-based tools skip entirely. When you need the secrets (to run your app, deploy, or test), Lockbox injects them as environment variables at runtime.

How it works

Lockbox is not encryption alone. Encrypted text is still text. A base64-encoded secret is still readable by grep. Lockbox stores your secrets in a binary format that tools designed to read text (including AI context engines) will not attempt to parse. The secrets are also encrypted with nonce-unique AEAD, so even if something did read the raw bytes, the data is meaningless without your key.

Two layers of protection:

• Invisibility. Binary storage that text tools skip. AI assistants, grep, cat, ripgrep, and code search all ignore it.
• Encryption. Nonce-unique AEAD (AES-256-GCM). Even if a tool somehow reads the bytes, the content is encrypted. Your key never leaves your machine.

The workflow

$ devsafe lockbox import .env
✓ imported 12 secrets from .env
✓ stored in .devsafe/lockbox (binary, AI-invisible)
  tip: run `devsafe lockbox proof` to verify invisibility

$ devsafe lockbox run npm start
✓ injected 12 secrets into environment
  server listening on :3000

# secrets are in memory only, never written to a file

$ devsafe lockbox proof

Testing AI visibility of .devsafe/lockbox...

  grep "STRIPE"          ✓ not found
  cat .devsafe/lockbox    ✓ binary, no text output
  ripgrep "SECRET"        ✓ not found
  strings .devsafe/lockbox ✓ no recognizable strings
  file .devsafe/lockbox   ✓ identified as "data" (not text)

✓ lockbox is invisible to all text tools
✓ 12 secrets stored, 0 secrets exposed

{
  "database": "{{LOCKBOX:DATABASE_URL}}",
  "stripe": "{{LOCKBOX:STRIPE_SECRET}}"
}

$ devsafe lockbox inject config.template.json --out config.json
✓ replaced 2 placeholders
✓ wrote config.json

$ devsafe lockbox wrap-mcp
  scanning MCP configs...
✓ found 3 configs with plaintext credentials
✓ imported 5 secrets to lockbox
✓ rewrote configs to use lockbox references

Lockbox vs. Vault

DevSafe has two tools for secrets. They solve different problems and work together.

Lockbox (devsafe lockbox) makes secrets invisible to AI tools on your local machine. It stores them in binary format so nothing that reads text can find them. This is for your daily workflow: developing, testing, and running code without exposing secrets to AI assistants.

Vault (devsafe vault) is encrypted credential storage for sharing across machines or with team members. It uses nonce-unique AEAD to encrypt secrets and stores them in user-owned storage. This is for credential management: syncing secrets between your laptop and your CI server, or sharing a staging database password with a teammate.

They work together naturally. Vault stores and syncs your secrets across machines. Lockbox hides them from AI on each machine. Import from Vault into Lockbox with a single command:

$ devsafe lockbox import --from-vault my-project
✓ imported 8 secrets from vault "my-project" into lockbox

Free, no account required

Lockbox works entirely on your machine. No account. No server. No subscription. Install DevSafe and start using it immediately.

For agencies and freelancers

When you manage secrets for multiple clients, Lockbox keeps them separated and controlled.

Scope secrets per client

The --project flag creates isolated lockboxes. Each client's secrets live in their own binary store, completely separate from every other client.

$ devsafe lockbox import .env --project acme-corp
✓ imported 6 secrets into project "acme-corp"

$ devsafe lockbox run --project acme-corp npm start
✓ injected 6 secrets (project: acme-corp)

Share credentials safely

Need to give a subcontractor temporary access to a client's staging API? lockbox grant creates a time-limited, single-use credential share. The recipient gets the secrets once. After the time window closes, the grant expires automatically.

$ devsafe lockbox grant --project acme-corp --expires 24h --keys STAGING_API_KEY,STAGING_DB_URL
✓ grant created (expires in 24 hours, single use)
  share this link: https://lockbox.devsafe.com/g/abc123

Clean up when a project ends

When a client engagement is over, revoke all credentials at once. No hunting through config files. No "did I remember to rotate that key?"

$ devsafe lockbox revoke --project acme-corp
  revoking all grants for project "acme-corp"...
✓ 2 active grants revoked
✓ project lockbox wiped

Collect credentials from clients

Instead of asking clients to paste API keys into Slack or email, send them an intake link. They enter their credentials into a secure form, and the secrets land directly in your project lockbox.

$ devsafe lockbox intake --project acme-corp --keys STRIPE_SECRET,DB_PASSWORD,SENDGRID_KEY
✓ intake form created (expires in 7 days)
  send this to your client: https://lockbox.devsafe.com/intake/xyz789