GITGUARDIAN STATE OF SECRETS SPRAWL 2026

24,000+ secrets leaked
from MCP configs. Here's the fix.

MCP config files are the new .env files — same problem, new format. Every AI agent you build drops your API keys into plaintext. VaultProof protects them at the moment they're used.

Protect your first key — free See how it works ↓

SCROLL TO UNDERSTAND THE PROBLEM

The problem

Why your MCP config
is a liability.

Model Context Protocol connects your AI agents to the services they need. But MCP requires credentials — and those credentials end up in config files that behave exactly like the .env files you've been warned about for years.

How MCP configs work

An MCP config file declares which servers your AI agent can talk to, and includes the credentials for each one. One file. All your keys. Usually committed to a repo or synced across machines.

Why that's dangerous

The key exists as plaintext in the config file, in your app's memory when it reads the config, and in every process that inherits it. This is exactly what supply chain attacks target.

What secrets managers do

Vault, Doppler, and Infisical protect keys at rest — they encrypt your secrets in storage. But once your app retrieves a key, it becomes a plaintext string in memory. The protection ends exactly when the risk begins.

What VaultProof does differently

We protect the key at the moment of use. The full key never materializes in your app, your config, or your memory. A proxy reconstructs it only for the API call — then zeros it immediately after.

The fix

Three lines to close
the runtime gap.

Replace your API client import with the VaultProof SDK. Same API, same behavior, zero plaintext keys in your app.

BEFORE: Key exposed in runtime VULNERABLE

// Your MCP config or app code
import OpenAI from 'openai';

// Key lives in config as plaintext.
// In memory. In logs. Leakable.
const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY
});

const res = await client
  .chat.completions.create({...});

AFTER: Key never exists in your app PROTECTED

// Same result. No plaintext key.
import openai from 'openai';

// Point at VaultProof — done.
// Key reconstructed proxy-side only.
const client = new openai({
  apiKey: "vp_live_your_key",
  baseURL: "https://api.vaultproof.dev/v1/openai"
});

const res = await client
  .chat.completions.create({...});

npm install @vaultproof/sdk # protect your first key in 15 minutes

Architecture

How it actually works.

Three cryptographic layers. The key never exists in your application.

Shamir Secret Sharing splits your key

When you register an API key with VaultProof, it's split into two shares using Shamir's Secret Sharing over GF(256) — information-theoretically secure. Any individual share is mathematically useless. Your app only handles shares, never the key.

A proxy reconstructs it for the API call

When your agent needs to make an API call, the VaultProof proxy collects the required shares and reconstructs the key in memory — for milliseconds. It makes the API call, returns the response to your app, then zeros the key from memory immediately.

Your MCP config holds no secrets

Replace every API key in your MCP config with a VaultProof key ID. The config can be committed, synced, or shared — there's nothing for an attacker to steal. The actual key only ever exists at Cloudflare's edge for the duration of one API call.

Stop putting plaintext
keys in MCP configs.

Free to start. 15 minutes to protect your first key. Works alongside Vault, Doppler, and Infisical.

Start free — no credit card

JavaScript SDK + Python SDK + CLI. Open architecture.

24,000+ secrets leakedfrom MCP configs. Here's the fix.

Why your MCP configis a liability.