Security Policy & Responsible Disclosure

1. Scope

This policy applies to security vulnerabilities discovered in:

• VaultMorph AI Shield desktop application — all editions (Community, Pro Trial, Enterprise)
• VaultMorph browser extension — Chrome/Edge extension for ChatGPT, Claude, Gemini, Copilot
• Security Workspace — Gitleaks/Semgrep sidecar, AI code review pipeline
• api.vaultmorph.org — the license server (Pro Trial activation, validation, rule updates)
• vaultmorph.org — the marketing and documentation website
• Rule pack signing infrastructure — Ed25519 key handling, signature verification

2. How to report a vulnerability

Email (preferred)

Send your report to contact@vaultmorph.org with the subject line:
"[SECURITY] Brief description of the issue"

Please include:

• A clear description of the vulnerability and its potential impact
• Steps to reproduce (proof-of-concept or minimal repro code preferred)
• The affected component, version, and platform (Windows/macOS/Linux)
• Whether you believe the vulnerability is already being exploited in the wild
• Your preferred form of credit (name, handle, or anonymous) for the hall of fame

GitHub Security Advisory (alternative)

You may also file a private GitHub Security Advisory for confidential disclosure without public disclosure. GitHub keeps these private until we coordinate a fix and publish the advisory together.

3. Disclosure process & timeline

Target remediation timelines by severity

We follow a coordinated disclosure model. We ask that you give us a reasonable amount of time to address the issue before any public disclosure. In return, we commit to the timelines above and will keep you informed throughout.

4. Severity classification (CVSS-inspired)

5. Safe harbor

VaultMorph will not take legal action against researchers who:

• Discover and report vulnerabilities in good faith following this policy
• Do not access, modify, or destroy data belonging to other users
• Do not perform denial-of-service attacks or degrade service quality for others
• Do not publicly disclose the vulnerability before we have had a reasonable opportunity to remediate it
• Do not demand payment or extort us in connection with their findings

We consider good-faith security research to be a valuable contribution to the safety of our users and will treat researchers accordingly.

6. Out-of-scope issues

The following are generally out of scope and will not be treated as security vulnerabilities:

• Theoretical vulnerabilities with no practical exploit path
• Self-XSS (attacks that require the victim to execute their own code)
• Issues in third-party libraries that are already publicly disclosed and not exploitable in our specific configuration
• Physical access attacks (e.g. an attacker with physical access to your device can access your OS keychain — that is expected)
• Social engineering attacks against VaultMorph staff
• Clickjacking on pages with no sensitive actions
• Missing security headers with low practical risk (e.g. X-Frame-Options on a static marketing page)
• Findings from automated scanners with no proof-of-concept exploit

7. Security architecture summary

For context when evaluating findings, here is a summary of our security design:

On-device (all editions)

• Sanitization is local-only: Raw secrets never leave the process. The sanitization engine runs in-memory; token maps are ephemeral and never written to disk as plaintext.
• Detection scope (v2.1.0 — 127 rules): API keys (79 patterns covering 70+ providers), authentication tokens (JWT, bearer), private keys (RSA/EC/DSA/OpenSSH/PGP), credentials and .env secrets, database connection strings (MongoDB, PostgreSQL, MySQL, Redis, MSSQL, Elasticsearch, Cassandra), PII (email, phone, US SSN), financial data (credit/debit cards, IBAN), India PII (PAN card, Aadhaar, UPI IDs, OTP codes), infrastructure identifiers (private IPs, MAC addresses, internal hostnames), and network addresses.
• API key storage: Encrypted with AES-256-GCM before writing to disk. The encryption key is stored in the OS keychain (Windows Credential Manager / macOS Keychain / libsecret on Linux).
• License verification: Ed25519 signature verification occurs offline. The public key is embedded in the binary. License JWTs are verified without requiring a network connection.
• Rule pack updates: Signed with Ed25519. The application verifies the signature before applying any rule update. A tampered rule pack is rejected.
• No telemetry: No usage data, error reports, or crash dumps are sent to VaultMorph from any edition.

Security Workspace (code review / SAST)

• DLP-safe AI code review: File contents, diff hunks, finding snippets, Semgrep/Gitleaks descriptions, and even file paths all pass through the detect → tokenize → sanitize gate before being sent to the AI provider. The AI receives only tokens — it never sees raw secret values that appear in the code being reviewed.
• Static analysis is offline: Gitleaks and Semgrep are invoked as local sidecar binaries with no network calls. A tampered or missing binary causes the scan step to be skipped, never to silently degrade to an online fallback.
• Finding output is untrusted: Static analysis output (a finding's matched snippet often contains the raw secret it found) is treated as untrusted input and force-tokenized through the same gate as user-typed text before any downstream use.
• No AI-generated code execution: Document generation uses a structured JSON spec emitted by the AI; the spec is rendered by local JavaScript. No AI output is passed to eval() or executed on the device.
• Scan state is not persisted as plaintext: The in-memory token map for a review session is never written to disk. Exported HTML security reports contain token placeholders, not raw matched secret values.

MCP Server trust gate

Two transports are supported; each has distinct trust controls.

HTTP transport (loopback)

• Loopback-only: MCP server URLs are validated at registration time; any non-loopback (non-localhost) URL is rejected before a connection is attempted.
• Explicit user approval required: A server is registered only when the user clicks Add — never automatically. Previously approved servers are reconnected on startup, but no new server is added without an explicit UI action.

stdio transport (local process)

• Hard consent gate — always: Before any stdio server is spawned for the first time, the app resolves the full command line (including Windows .cmd shims for npx/npm/pnpm/yarn) and shows the user the exact, resolved command. The user must click Approve & Connect. The process is never launched automatically, not even on app restart.
• Consent drift detection: If the stored command, args, or env variables are modified after approval, the app detects that consent is stale and re-requires explicit approval before re-spawning the process.
• Process isolation: stdio child processes are managed by the Tauri Rust layer. If the app quits or crashes, the child process is terminated.

Both transports

• MCP tool output is sanitized: Tool return values from MCP servers pass through the same detect → tokenize → sanitize pipeline as anything else. A compromised local MCP server cannot exfiltrate data by embedding secrets in its tool output.

Browser Extension

• All processing is local: The extension runs entirely in the browser process. No data — neither the original text nor the tokens — leaves the browser extension to VaultMorph servers.
• Input interception only: The extension intercepts the AI site's input field before submission and the AI site's streaming response during display. It does not read page content outside those two elements.
• Same token format: The extension uses the same <<VM_TOKEN_[TYPE]_[N]_[HASH]>> format as the desktop app. A session token map is maintained in extension memory for the duration of the browser session only.
• Supported sites: ChatGPT (chatgpt.com), Claude (claude.ai), Gemini (gemini.google.com), Copilot (copilot.microsoft.com). No other domains are modified.

Artifact sandbox

• Sandboxed WebView: AI-generated HTML/JS responses are rendered in an isolated WebView frame with a dedicated sandbox bootstrap. The frame cannot access the parent app's DOM, localStorage, OS APIs, or any data outside the frame boundary.
• postMessage-only communication: The sandbox frame communicates with the host app via a typed postMessage protocol. The host validates every incoming message against an allowed message schema; arbitrary function calls from sandboxed content are not possible.
• Origin isolation: The sandbox frame uses a dedicated local scheme that browser-origin security policies prevent from reading across frame boundaries into the parent app.
• No AI-generated code execution: The sandbox is enforced at the app layer and does not depend on the AI generating safe content. Even malicious JavaScript generated by the AI cannot escape the sandbox.

Subscription providers (Claude Code & ChatGPT Codex CLI)

• Claude Code: Routes requests through the local claude CLI binary (Anthropic's own Claude Code tool). The app detects the CLI path via Tauri, shows a consent modal on first connect, and then passes sanitized prompts to the CLI. Requests go from your Claude Code subscription account — no VaultMorph servers are involved in the message path.
• No API key stored: Subscription providers authenticate via the Claude Code or Codex CLI's own credential mechanism (oauth token, subscription session). VaultMorph never stores or sees that credential.

Azure OpenAI provider

• Uses the api-key header (not Bearer) — stored AES-256-GCM encrypted in the OS keychain, same as all other API keys.
• Requests go directly from your device to your Azure OpenAI endpoint ({baseUrl}/openai/deployments/{deploymentName}/chat/completions). Traffic does not route through VaultMorph servers.
• The deployment name and api-version are user-controlled configuration; defaults follow Microsoft's recommendation (2024-10-01-preview).

Knowledge Base (RAG)

• Chunks are sanitized before storage: Document text is tokenized through the sanitization pipeline before any chunk is written to the encrypted SQLite database. Only token placeholders — never raw secrets — are persisted on disk.
• Embeddings computed on original text: Vector embeddings are computed on the original (pre-sanitization) chunk text on-device for retrieval quality, then immediately discarded. Only the resulting float vectors are stored — not the plaintext used to produce them.
• Storage is encrypted: Chunk text and embeddings are AES-256-GCM encrypted (same key as API key storage) before being written to the local database.
• Retrieval is sanitized: Chunks retrieved for a prompt are routed through the sanitization pipeline again before being prepended — a no-op for already-tokenized text, but a second-layer defence against un-tokenized content reaching the provider.

Voice Input

• Transcription is fully offline: The Whisper model runs via whisper-rs (whisper.cpp Rust bindings) entirely in-process. No audio and no transcript is sent over the network.
• Transcript is sanitized: The resulting transcript text is treated as untrusted input and passes through the standard detect → tokenize → sanitize pipeline exactly like typed text.

License server (api.vaultmorph.org)

• TLS 1.2+ enforced. Let's Encrypt certificate with auto-renewal.
• License JWTs signed with Ed25519 server-side private key. The private key is not exposed through any API endpoint.
• Database: SQLite. No personal data beyond email address and one-way device hash (Pro Trial only).
• Admin endpoints require a secret header; not publicly accessible.
• Server located in India — OCI Mumbai region.

8. Hall of fame

We are grateful to the following researchers who have responsibly disclosed security issues to us:

No submissions yet — be the first! We recognise all valid reports here (with your permission).