Security

Protect provider keys without trusting every app surface with them.

VaultProof keeps raw provider keys out of source code, hosted env files, CI logs, and AI coding context. Your app uses VaultProof-routed credentials while the real provider key is protected, monitored, and easier to rotate.

Setup guide Report issue
Security posture
  1. 1Remove raw provider keys from app configuration.
  2. 2Route provider calls through VaultProof-compatible base URLs.
  3. 3Track usage, errors, budgets, and suspicious activity.
  4. 4Rotate or revoke exposed provider keys with clearer evidence.

Trust model

VaultProof reduces where complete provider keys can live.

The main security goal is simple: a leaked app repository, browser build, CI log, prompt transcript, or hosted environment should not expose the original provider credential.

App receives a VaultProof token

Your application uses VaultProof-managed values instead of storing the raw OpenAI, Anthropic, Stripe, or other provider key directly.

Provider route stays compatible

For supported providers, the init tool writes base URL values so normal SDK calls can route through VaultProof without a custom integration.

Operations stay observable

Activity, alerts, usage, and error views help teams see whether protected keys are being used as expected.

Plain-language boundary VaultProof is not a replacement for rotating leaked provider keys, securing customer devices, or configuring provider-side controls. It reduces plaintext key exposure and gives teams a safer operating layer around runtime provider access.

Secure setup

The hosted init handles the setup details.

Users should not need to manually wire provider SDK code for common providers. The installer fetches the hosted init bundle and provider catalog, verifies the manifest, then the init command handles detection and environment updates.

  1. 1

    Install the hosted init

    Run the installer from your app folder. The installer downloads the CLI bundle and a provider catalog fallback from /downloads and checks the manifest before installing.

  2. 2

    Run vaultproof-init

    The init scans common env files, detects supported provider keys, protects them, and writes VaultProof values back into the app environment.

  3. 3

    Deploy the generated values

    Copy the generated VaultProof token and base URL values to your hosting provider, then restart and test one provider call before wider rollout.

Provider catalog The live catalog at /providers.json is version 9 with 250 provider signatures, updated on 2026-05-21. The init downloads this catalog on each run and falls back to the installed copy if needed.

Key lifecycle

Know where key material exists during normal use.

VaultProof is designed around reducing persistent plaintext exposure. It still needs to authenticate to the provider when your application sends a real provider request.

Stage What happens Security intent
Before setup The raw provider key may exist in local env files, hosting settings, previous commits, or copied snippets. Find the key and move it behind VaultProof.
After init The app keeps VaultProof-managed values instead of the original provider credential. Reduce exposure in source code, AI tools, hosting config, and logs.
During a request VaultProof routes the request and authenticates to the upstream provider on behalf of your app. Use provider credentials only for the request path that needs them.
After a request VaultProof records request metadata such as provider, route, status, timestamp, and latency. Support incident review without storing raw provider keys or request bodies.
Important runtime reality When a provider request is made, the upstream provider receives the credential required to authenticate that request. VaultProof does not change how provider authentication works; it changes where the credential is stored and how access is routed and observed.

Controls

Security controls should be usable by operators.

The dashboard is designed to help teams understand key usage and take action when something looks wrong.

Activity review

Monitor request stream, busy endpoints, errors, latency, provider status, and usage trends from the dashboard.

Alerts and budgets

Use alerts and plan limits to catch unusual volume, failed calls, or traffic that needs investigation before it becomes spend or abuse.

Origin and environment discipline

Keep VaultProof values scoped to the app environments that need them and remove raw provider keys from old hosting settings.

Scanner follow-up

Use scanner findings to identify exposed keys, then rotate affected provider credentials and move the app through VaultProof.

Logging

Logs should help incident review without becoming another secret store.

VaultProof records operational metadata that helps you understand usage and failures. It should not become a place where raw provider secrets or request payloads are copied.

Recorded

  • Provider and route metadata.
  • Status code, timestamp, and latency.
  • Usage counters and alert state.
  • Scanner and dashboard actions.

Not for logs

  • Raw provider API keys.
  • Request and response bodies.
  • Provider secrets copied into tickets.
  • Unredacted customer credentials.
Support rule When troubleshooting, send timestamps, provider names, route names, status codes, and request IDs. Do not send raw provider keys.

Limits

Clear limitations make the system safer to use.

No security product removes the need for good provider hygiene. VaultProof is strongest when paired with rotation, provider-side restrictions, team access controls, and deployment discipline.

Protects against

  • Raw keys committed to source code.
  • Keys copied into AI coding context.
  • Plaintext keys sitting in hosted env settings.
  • Limited incident visibility after a leak.

Does not replace

  • Rotating provider keys after exposure.
  • Securing developer laptops and CI systems.
  • Provider-side allowlists and spend controls.
  • Reviewing app code that sends sensitive payloads.
If VaultProof or your app is breached Treat provider credentials as sensitive and rotate affected keys. VaultProof is built to reduce what a single surface can expose, but rotation is still the right response when there is credible exposure.

Infrastructure

Built on managed infrastructure with defense in depth.

VaultProof uses established infrastructure layers for edge routing, authentication, storage, and billing, with TLS in transit and encryption at rest from the underlying platforms.

Layer Purpose Security responsibility
Website and installer Hosts docs, installer, init bundle, manifest, and provider catalog. Serve from HTTPS, use cache-aware deployment, and verify install artifacts through the manifest.
Runtime proxy Routes app requests to supported providers. Authenticate requests, apply controls, avoid logging secrets, and expose usage metadata.
Database and auth Stores account, project, configuration, and activity data. Restrict access, encrypt at rest, and separate tenant data by account/workspace boundaries.
Billing provider Handles subscriptions and payment flow. Keep card data out of VaultProof systems.

Responsible disclosure

Report security issues directly.

If you find a vulnerability, disclosure mistake, exposed secret, install integrity issue, or dashboard access bug, contact us before public disclosure so we can protect customers quickly.

Send

  • Steps to reproduce.
  • Affected URL, route, or component.
  • Potential impact and suggested severity.
  • Redacted screenshots or logs when useful.

Do not send

  • Raw provider API keys.
  • Customer personal data.
  • Unredacted access tokens.
  • Payloads from unrelated third-party systems.
Security contact Email [email protected]. We aim to acknowledge valid security reports within 48 hours.