Security & Compliance

Security built into the architecture.

FORG's privacy model is enforced structurally. The Iron Rule — no prompt or completion content ever stored — is a schema constraint, not a policy that can be misconfigured away.

The Iron Rule

FORG never stores, transmits, or processes the content of your prompts or AI completions. The behavioral signal schema is defined to make this physically impossible — there is no field in the schema that accepts content. This is an architectural guarantee, not a policy that can be overridden by configuration.

Compliance status

Current status for all major compliance frameworks and certifications.

GDPRActiveTarget: In compliance

DPA available. SCCs for EU/US data transfers.

SOC 2 Type IIn progressTarget: Q3 2026

Manual control mapping underway. Compliance platform selection in progress.

SOC 2 Type IIPlannedTarget: Q3 2027

6-month observation period begins after Type I completion.

ISO 27001PlannedTarget: 2027

Concurrent with SOC 2 Type II observation period.

HIPAA BAAPlannedTarget: Enterprise Scale

Available on Enterprise Scale tier. Contact sales.

Penetration testIn progressTarget: Pre-launch

Scoped to agent↔engine trust boundary, HMAC chain, kill-switch path.

Security principles

Metadata-only processing (The Iron Rule)

FORG signal schema v3 captures token counts, latency, model, adapter, cost, and dimension tags. Prompt text, completion content, and user input are never collected, transmitted, or stored. This is enforced at the agent level — the binary has no code path that reads or transmits content.

HMAC-authenticated hooks

Claude Code hooks are authenticated via HMAC-SHA256 with a session key derived from the license bundle using HKDF-SHA256. Each hook call includes a timestamp and signature. The Rule Engine verifies both before processing. Replayed or forged hook payloads are rejected.

License bundle security

License bundles are stored in the OS-native keystore: macOS Security.framework, Linux libsecret, Windows DPAPI. The bundle is never written to disk in plaintext. On revocation or ban, the local wipe procedure calls keychain.Delete() before wiping all data files.

TLS everywhere — single surface

All FORG traffic terminates at forg.pro only. Cloudflare Universal SSL provides TLS 1.3 minimum. We use CA + SAN pinning (never leaf or SPKI pinning — CF rotates automatically). Internal CF Worker subroutes are never exposed to the public internet.

k-anonymity threshold

Aggregated query responses enforce a minimum cohort size of k ≥ 5. Queries that would reveal data about fewer than 5 individuals are blocked. This applies to all dashboard views, API responses, and FORG Atlas answers.

Audit chain

All license operations (issue, verify, revoke, ban) are recorded to an append-only audit_chain table in D1. Each entry includes the previous entry's hash, creating a tamper-evident chain. Audit logs are retained for the lifetime of the account.

Infrastructure security

Cloudflare Workers.The Rule Engine Worker and License Worker run on Cloudflare's global network. All Worker code is isolated using V8 isolates. Workers have no persistent compute — each invocation runs in a fresh isolate.

Supabase (PostgreSQL + pgvector). Behavioral signal data is stored in Supabase with Row-Level Security (RLS) enabled on every table. Service role keys are scoped to specific operations and rotated quarterly. Direct database connections from the public internet are not permitted.

Cloudflare D1 (SQLite). License and identity data lives in D1, bound directly to the License Worker. D1 is not reachable from external networks — only the bound Worker can query it.

Secrets management.No secrets are hardcoded in source code. All Worker secrets are injected at deploy time via Wrangler's encrypted secrets store. Secrets are never logged.

Dependency management. We run automated dependency audits on every PR. Dependabot is active on all repositories. Critical CVEs block deployment.

Vulnerability disclosure policy

We welcome responsible disclosure from security researchers. We are committed to resolving verified vulnerabilities promptly and to crediting researchers who follow this process.

1

Report

Email security@forg.pro with details. PGP key available on request. We acknowledge within 24 hours.

2

Triage

We assess severity, reproduce the issue, and confirm the scope. We'll keep you updated every 48 hours.

3

Fix

We patch and deploy. Timeline: critical = same-day, high = 7 days, medium = 30 days.

4

Disclosure

Coordinated disclosure after patch deployment. We credit researchers who follow responsible disclosure.

Report vulnerabilities to security@forg.pro. Please do not file public GitHub issues for security vulnerabilities.

Security contact

For security questions, vulnerability reports, or compliance documentation requests, contact the security team directly.