Protect API access without spreading raw provider keys.

Choose a setup path

Use the normal provider path when a supported provider credential already lives in one of your app’s environment files. The CLI detects supported provider shapes, replaces the application value with a VaultProof-managed runtime value, and adds provider-compatible base URL settings where the provider supports them.

• Supported provider traffic: use vaultproof-init from the application directory.
• Custom or internal HTTPS API: use vaultproof-init custom for a service not represented in the provider catalog. The CLI validates the declared upstream before setup.
• Vault-only runtime secret: use vaultproof-init secrets add for values such as database connection strings or signing material that cannot travel through a provider HTTP proxy.
• Repository scanning: use the separate, opt-in repository scanner to identify exposure in connected GitHub repositories. It is not part of the public ChatGPT MCP connection.

Quick start

Create or sign in to a VaultProof account, then run the installer from your application directory. Before changing files, inspect what the CLI would detect with a dry run.

curl -fsSL https://vaultproof.dev/install | sh
vaultproof-init --dry-run
vaultproof-init

1. Review the detected entries and confirm the setup in the CLI.
2. Restart the application with the generated environment configuration.
3. Make one normal provider request and confirm its safe operational record in Activity Logs.

Review the detected entries before confirming a rewrite, and retain a recoverable copy of any environment file you plan to modify. Do not commit original raw provider keys or plaintext runtime secrets.

How runtime protection works

For a supported provider, your application keeps using its normal SDK environment configuration. VaultProof supplies a managed runtime value and a provider-compatible route where supported, so the request passes through the VaultProof protection boundary before it reaches the provider.

Provider keys are split before storage and are reconstructed only inside the proxy request path to authenticate the outbound provider call. The application receives the provider response; normal provider-key flows do not return raw provider keys to the application.

Activity records are designed for operations: provider, route category, status, timestamp, and latency. They are not a place to store secret values or request payloads.

Provider setup

The public provider catalog identifies supported providers and supplies the detection patterns used by the CLI, with a bundled fallback for installation. If your service is not covered, use the custom API path instead of forcing an incompatible provider setup.

After setup, retain the generated provider base URL configuration alongside the managed runtime value and restart the application. Test a normal call locally before applying the same configuration to staging or production.

CLI reference

These commands are available in the current hosted CLI. Run them from the project directory that contains the files you intend to protect.

Operate from the dashboard

The signed-in workspace is the operational home for protected access. Use Protected Keys to review and manage protected provider entries, Activity Logs to check routing outcomes, and Security Alerts to configure or review alerting.

Marketplace shows supported provider setup information. Settings covers workspace controls, and Plans & Billing shows plan and usage controls. The Repository Scanner remains an opt-in GitHub workflow with its own findings and remediation process.

Respond to an access concern

If a provider credential may have been exposed, rotate or revoke it at the provider and through the applicable VaultProof workflow, then review recent activity for unexpected use. A VaultProof-managed runtime value can reduce where the original credential appears, but it does not eliminate the need to rotate a credibly exposed provider credential.

For a repository finding, use the scanner’s guided remediation and check the provider dashboard. For a security vulnerability in VaultProof, contact [email protected]. Do not include provider credentials, VaultProof values, passwords, session material, or full authorization headers in email or chat.

Troubleshooting

The CLI did not find an expected provider entry

Run vaultproof-init --dry-run from the directory that contains the relevant environment file. If the service is not in the catalog, use vaultproof-init custom.

A protected request does not appear in Activity

Confirm the application restarted with the generated configuration, make one normal provider request, and check the selected workspace and time range.

A provider request fails after setup

Use vaultproof-init doctor, verify the provider’s own service status and permissions, then compare the generated route configuration with the application environment.

You need help without sharing a secret

Check service status, then contact support with the affected feature, provider, approximate time, and visible error only.

Reference links

• Provider guides for step-by-step integration help.
• MCP security boundary: the read-only MCP connection returns non-secret metadata and server-side placement guidance. It cannot accept, retrieve, reveal, or provision provider credentials.
• Security, Privacy, and Terms for the public policy and controls reference.
• Status for shared service checks and Support for account and setup help.