Security at ApiVault

You trust us with credentials that unlock everything else, so we publish how we protect them and make it easy to tell us when we got something wrong.

AES-256-GCM at rest

Every key value is encrypted before it is written to the database. Lists only ever show a precomputed mask.

Optional custom vault keys

In custom mode the key is derived from a vault key we never store, with a per-project salt and a memory-hard KDF.

Passkeys and 2FA

WebAuthn passkeys for sign-in or as a second factor, plus TOTP authenticator apps.

Scoped, expiring tokens

Service tokens carry scopes, an optional environment pin, IP allowlist and expiry. MCP access uses OAuth 2.1 with PKCE.

Audit trail

Reveals, exports, CLI and MCP reads, and token use are logged per project with IP and source, and can be exported.

Masked to agents by default

MCP tools return masked previews; revealing a raw value needs the separate keys:reveal scope.

The full model, including what the server can and cannot decrypt in each mode, is in the security architecture docs.

Reporting a vulnerability

If you think you have found a security issue in ApiVault, email support@apivault.tech with “Security report” in the subject. Please don't open a public GitHub issue, post about it, or share it with anyone else until we have fixed it.

A useful report includes:

  • what the issue is and what an attacker could do with it;
  • step-by-step reproduction, or a minimal proof of concept;
  • the affected URL, endpoint, CLI or MCP version, and your environment;
  • how you would like to be credited, if at all.

Our contact details are also published in machine-readable form at /.well-known/security.txt.

What happens next

  • Within 48 hours we acknowledge your report.
  • Within 5 business days we send our assessment and a timeline for the fix.
  • We keep you updated until it is fixed, and tell you when it ships.
  • Once the fix is deployed we agree a disclosure date with you, and credit you in the release notes on the changelog unless you would rather stay anonymous.

We don't run a paid bug bounty program at this time.

In scope

  • The ApiVault web app and API at https://apivault.tech, including /api, /oauth and /mcp
  • The apivault CLI and the ApiVault MCP server packages
  • The Vercel, Supabase and Cloudflare integrations

Out of scope

  • Denial of service, load testing, or anything that degrades the service for other people
  • Social engineering, phishing, or physical attacks against our staff or users
  • Spam, or attacks that need a compromised device or browser extension
  • Missing security headers or best practices without a demonstrated impact
  • Vulnerabilities in third-party services we use, which should go to that vendor
  • Reports generated by automated scanners without a verified, working issue

Safe harbor

We will not pursue legal action against anyone who researches and reports in good faith under this policy. Good faith means you:

  • only test against accounts and projects you own, or have explicit permission to test;
  • stop as soon as you reach data that isn't yours, don't keep or share it, and tell us what you saw;
  • don't degrade the service, or modify or delete anyone else's data;
  • give us reasonable time to fix the issue before disclosing it.
Something wrong with your own account? If you think your account, a token or a key has been compromised, revoke it first: sign out other sessions under Settings → Sessions, revoke CLI and MCP access, rotate the affected keys with their provider, then contact us.

Last updated October 24, 2026.