{*}SecureCodeHQ
Security Whitepaper

How we protect your secrets

Full transparency on our encryption, authentication, access control, and infrastructure. The technical details of how SecureCodeHQ keeps your API keys, tokens, and passwords safe.

Last updated: March 2026

Architecture Overview

Every secret follows the same secure path from creation to access.

1

Create Secret

Via dashboard, .env import (web only), or MCP/SDK (value encrypted immediately)

2

Encrypt

AES-256-GCM with unique DEK, wrapped by Google Cloud KMS

3

Store

Ciphertext + wrapped DEK in Firestore (value never stored in plaintext)

4

Access

Auth + device check + rules evaluation + audit log before delivery

Encryption at Rest

We use envelope encryption, the industry standard used by AWS, Google Cloud, and Azure. Each secret has its own encryption key, and that key is protected by Google Cloud KMS.

How envelope encryption works

Your secret: "sk_live_xxx"

→ Encrypt with DEK (AES-256-GCM, unique per secret)

→ Wrap DEK with KEK (Google Cloud KMS)

→ Store: ciphertext + wrapped DEK in Firestore (KEK never leaves KMS)

Encrypted

  • Secret values (AES-256-GCM, unique key per secret)
  • API keys (SHA-256 hashed, never stored in plaintext)
  • All data in transit (TLS 1.3)

Not encrypted (by design)

  • Secret names (needed for lookups and search)
  • Tags and descriptions (needed for filtering and MCP rules)
  • Audit logs (needed for querying and compliance)
Core Principle

Zero-Knowledge AI Access

Our core differentiator: when Claude Code uses your secrets, the AI agent never sees the actual values. The secret is injected into a temporary file that your app reads. It never enters the AI's context window.

Default flow: inject mode

Claude Code asks for DATABASE_URL

→ MCP server fetches encrypted value from API

→ Writes to ~/.securecode/.session/session.env

→ Returns: "Injected to /path. Value is NOT in this conversation."

Inject Mode (Default)

Secrets are written to a temporary session file. The AI agent receives only the file path, never the value. Your app reads the file at runtime.

Secure Import

Bulk imports from .env files always go through the web dashboard. The MCP import-env tool redirects to the browser and never accepts raw secret content from the agent.

SDK loadEnv()

In production, the SDK fetches secrets server-to-server (your app to SecureCode API). Values go directly into process.env. No AI agent involved.

Explicit Reveal (Audited)

If an agent needs to see a value (reveal mode), it's an explicit, audited action. The audit log records exactly which agent accessed which secret in reveal mode.

Two-Layer Authentication

Layer 1: API Key

Every SDK/MCP request includes an API key (sc_xxx). The key identifies the user or team and determines plan limits. Keys are SHA-256 hashed before storage. We never store your API key in plaintext.

Resolution: env var → .securecoderc → .mcp.json

Layer 2: Device Approval

Every unique combination of agent + machine + API key + IP is a "device". New devices are blocked by default and require your explicit approval from the dashboard before accessing any secret.

Fingerprint: user : hostname : agent : keyId : ip

Permission levels per device

Read Only

List and read secrets. Cannot create, update, or delete.

Read / Write

List, read, create, and update secrets. Cannot delete.

Full Access

All operations including delete. Use only for trusted devices.

Access Policies (MCP Rules)

Tag-based access policies evaluated server-side before any secret is delivered. Rules only apply to SDK/MCP/API access. Dashboard access is never restricted.

Block Always

Secret can only be accessed from the dashboard. All SDK/MCP/API access is denied.

Use case: master passwords, root credentials

Require Session

Agent must explicitly wake a session before accessing the secret. Sessions have a configurable TTL.

Use case: production database credentials

Block Models

Block access from specific AI models. The agent self-reports its model via the X-AI-Model header.

Use case: restrict to Claude only, block untrusted models

Require Confirmation

Agent must acknowledge the rule before access is granted. Acknowledgment has a 5-minute TTL.

Use case: high-value API keys (Stripe, AWS)

Notify

Sends an email notification when the secret is accessed. Non-blocking: access is still granted immediately.

Use case: audit awareness for shared team secrets

Rules are evaluated in priority order: block_always > require_session > block_models > require_confirmation > notify

Complete Audit Trail

Every secret access is logged with full context. You always know exactly who accessed what, when, how, and from where, including which AI model was used.

Example audit log entry

{
"action": "read",
"secretName": "DATABASE_URL",
"source": "mcp",
"accessMode": "inject",
"agentName": "claude-code",
"machineUser": "juani",
"ipAddress": "84.125.***.**",
"timestamp": "2026-03-19T09:14:00Z"
}

Who

User + agent + machine

What

Secret + action

How

SDK / MCP / dashboard

When

Timestamp

Where

IP + platform

API Key Security

API keys are designed for safe rotation with zero downtime. No restart required.

SHA-256 Hashing

API keys are hashed before storage. We never store your key in plaintext. Even if our database were compromised, your API keys cannot be recovered.

Graceful Rotation

When you rotate a key, the old key remains valid for 48 hours (grace period). Device approvals transfer automatically to the new key. Zero downtime.

Auto-Retry on 401

The SDK automatically re-reads the API key from its source on 401 errors. If you've rotated the key, the app picks up the new key without a restart.

Chrome Extension Security

The SecureCodeHQ Chrome Extension follows the same security principles as the SDK and MCP server.

No Local Secret Storage

The extension never stores secret values locally. It generates values client-side or fetches them from the API on demand. Nothing persists in chrome.storage.

API Authentication

All API calls use Firebase Auth tokens. The extension includes an X-Client: extension header for audit source tracking.

Audit Source Tracking

Every action from the extension is logged in the audit trail with source: 'extension', so you can distinguish extension access from SDK, MCP, or dashboard access.

TTL-Only Saves

When saving generated values to the vault, the extension always requires a TTL (time-to-live). No permanent secrets from the extension. They expire automatically.

Infrastructure & Dependencies

Google Cloud KMS

Key wrapping (KEK) handled by Google Cloud KMS. The master key never leaves Google's HSM infrastructure. We don't implement our own cryptography.

Cloud Firestore

Metadata, encrypted ciphertext, and audit logs stored in Firestore with security rules that enforce user/team isolation. Google manages replication and backups.

Vercel Edge Network

The web dashboard and API routes deploy to Vercel's edge network. All traffic is HTTPS with TLS 1.3. Automatic DDoS protection and CDN caching for static assets.

Open Source SDK & MCP

The SDK (@securecode/sdk) and MCP server (@securecode/mcp-server) are published on npm under MIT license. You can inspect every line of code that runs on your machine.

What We're Honest About

We believe transparency builds more trust than marketing claims. Here's where we are today and where we're headed.

No SOC 2 certification (yet). We're a new product. SOC 2 Type II costs $30-50K/year and requires 3-12 months of observation. We'll pursue it when our customer base justifies the investment. Until then, this page is our commitment to transparency.
No formal pentest (yet). We plan to commission an independent security audit when we reach meaningful revenue. We'll publish the results publicly.
We don't roll our own crypto. AES-256-GCM via Google Cloud KMS. Key wrapping via Cloud KMS HSMs. We use proven, audited libraries, not custom implementations.
Our client-side code is open source. The SDK and MCP server are MIT-licensed on npm. You can audit exactly what runs on your machine. The server-side code is proprietary but follows the architecture described on this page.
Security is iterative. We're building in public. As we grow, we'll add penetration testing, SOC 2 certification, and third-party audits. This page will always reflect our current state, not aspirations.

Questions about our security?

Read the docs, inspect the source code, or reach out directly. We're happy to discuss our security model in detail.