The security boundary your team can actually ship.
VaultProof removes raw third-party API keys from apps, agents, CI jobs, and fleet-facing services. The rollout stays practical: keep the SDK, swap the base URL, push a project identifier, and make policy visible.
- what changes
- base URL + project ID
- what disappears
- plaintext provider keys
- best first buyer
- security + platform
apps, agents, CI, device gateways
- web runtime
- copilot jobs
- github actions
- fleet control plane
policy before the upstream call
OPENAI_BASE_URL=https://init.vaultproof.dev/p/openai/v1
origin lock, logs, revoke, spend caps
- per-route policy
- per-provider routing
- fast revoke
- budget controls
The same platform lands differently for each buyer.
The handoff design leaned into a dense, buyer-ready walkthrough. This section keeps that shape, but lets security, platform, and product leaders read the same control plane through their own risk model.
Remove raw third-party keys from the highest-risk surfaces.
The pitch for security leaders is simple: secrets managers still hand plaintext keys to apps and pipelines. VaultProof keeps the key out of those environments entirely, then adds enforceable runtime policy on the calls that remain.
Make the boundary visible in one screenful.
The design bundle centered the scanner as proof. For enterprise-demo, the equivalent move is a sharp before-and-after: where the raw key used to exist, and what the app receives after VaultProof is in the path.
Plaintext secret spread across runtime surfaces.
STRIPE_SECRET_KEY=sk_live_xyz789...
.env, CI variables, agent context, or config screens.Project-scoped access plus policy, not a copied provider key.
OPENAI_BASE_URL=https://init.vaultproof.dev/p/openai/v1
Origin lock, IP rules, route restrictions, and budget caps all apply before the upstream call.
See which project, which provider, which route, and when the request happened.
Revoke or disable centrally without touching every codebase, repo, runner, or service.
Keep the provider SDK. Change the env values. Pilot in a stack the team already ships.
Different from vaults because the whole key never needs to sit there.
The original landing exploration added a comparison matrix after iteration. That belongs here too because enterprise buyers ask it fast: why this instead of Doppler, Infisical, or just another `.env` workflow?
One control model across apps, CI, and connected systems.
The design notes called out web, CI/CD, IoT, and cars explicitly. That same coverage belongs here because it widens the enterprise motion without changing the core product story.
Browser and backend share one policy-controlled path.
For SaaS teams, the cleanest motion is to replace raw provider secrets in the backend and origin-lock browser traffic. That makes leaked front-end identifiers much less dangerous and gives the security team a visible boundary around outbound API usage.
Enterprise proof points should be visible before the first demo call.
The handoff bundle kept the promise surface compact and specific. These are the claims the page should communicate within the first scroll and defend in the second.
Origin and IP policy
Lock traffic by domain, route, provider, or IP range so a leaked identifier does not become a free pass.
Audit trail and revoke
See who called what, when it failed, and how to shut it off without chasing raw keys across teams.
Spend and abuse controls
Budget caps and route restrictions help stop runaway costs and misuse before they compound.
Rollout without SDK rewrite
The fastest path still wins: keep the provider SDK, change the env values, and pilot in an existing stack.
A realistic 30-day rollout for the first shared workspace.
The buyer story should end with a pilot motion, not a vague contact form. This timeline keeps the enterprise page specific enough to be actionable.
Week 1
Pick one high-risk integration: AI provider, payment flow, or CI job that still depends on a plaintext secret.
Week 2
Route through VaultProof. Replace the provider secret with a project ID and apply origin or IP policy.
Week 3
Walk security through audit logs, alert paths, spend caps, and incident-response controls.
Week 4
Expand from one app into the next environment: browser, pipeline, or fleet gateway.
Bring one app, one provider, or one pipeline.
We will map the current plaintext secret path, route it through VaultProof, and show your team the policy and audit boundary in a live session.
No raw provider key in runtime, no SDK rewrite, revocation in one place, and a path from web apps to CI/CD to connected systems.
A buyer should leave saying: this is not another vault, it changes what our apps and agents can actually touch.