Security & data posture

• At rest: all customer data is stored in Supabase Postgres + Supabase Storage with encryption at rest enabled by default (AES-256). Encryption is enforced by the underlying storage layer; no customer data sits unencrypted on disk.
• In transit: all API + storage traffic is TLS 1.2+ enforced. HTTP requests are rejected.

Every customer-data table is protected by Postgres Row-Level Security (RLS) policies that org-scope reads + writes. A cross-tenant read is structurally impossible — RLS is enforced by the database itself, not by application code.

• Project records, action items, comments, attachments, planning sessions: org-scoped via get_user_organization_id() RLS function
• Document-import tables (jobs, items, storage bucket): org-scoped reads; service-role-only writes from the extraction worker (prevents UI-side data poisoning)
• Telemetry + audit log: org-scoped, append-only (no UPDATE or DELETE policies for authenticated callers)

When you import past operational documents (Word, Excel, PDF) via/import, we apply the same posture as the rest of the platform — with two additional commitments specific to imported content:

Every agent and MCP action-layer call — document import, extraction approval and re-extraction, and any change an agent applies through MCP — writes a row to agent_action_log. That table is append-only at the database level: there are no UPDATE or DELETE policies for authenticated callers, so once a row is written, you (and we) cannot alter or remove it through the application. (Day-to-day in-app changes — status updates, comments — are recorded separately in organization_change_log.) Authenticated users can read their own org's audit history. This append-only trail is the substrate behind the auditor-friendly PDF export available on every project.

On top of that, the highest-stakes project mutations — a project's status change, a project deletion, a task import, and any change an agent applies through the MCP action layer — are additionally recorded in a tamper-evident, hash-chained immutable trail (audit_log_immutable). Each entry is keyed-HMAC (SHA-256) hashed over its own contents and linked to the hash of the entry before it, so the rows form a chain: editing any entry's payload, or inserting / deleting / reordering rows, breaks the chain and is detectable. Entries can only be written by our server (INSERT is restricted to the service role at the database level — no signed-in user can forge a row), and there are no UPDATE or DELETE policies, so once written an entry cannot be altered or removed. An auditor can re-verify the chain independently: we recompute every entry's hash from its stored contents and confirm every link, not just the endpoints. The HMAC key is held server-side, so a chain that verifies could only have been produced by our server. The chain is built as these mutations occur, so a new organization's trail starts empty and grows from its first audited action — the verification applies to whatever entries exist, not to a backfilled history.

We scope this honestly: the hash-chained trail records those load-bearing project mutations — project status changes, deletions, imports, and agent actions — going forward, as they occur. Broader day-to-day events — comments, individual file uploads, every read — live in the append-only agent_action_log above, not the hash-chained trail.

• Supabase — Postgres database + storage + auth (US-East region, SOC 2 Type II certified by the provider)
• Vercel — application hosting (SOC 2 Type II certified by the provider)
• Google Gemini API — LLM inference for planner and document extraction. API submissions are excluded from Google's training corpus per their API terms.
• Sentry — error monitoring. PII scrubbing is applied client-side and server-side before any error is transmitted.

We do not share customer data with any other third party.

ChangePilot is not currently SOC 2, ISO 27001, or HIPAA-BAA attested. We chose to ship the product to early customers before committing to a formal audit cycle so the controls we attest to reflect how the product actually behaves under real use, not a snapshot taken in advance.

Our underlying infrastructure providers — Supabase (Postgres + storage + auth) and Vercel (application hosting) — both hold SOC 2 Type II attestations covering the storage, compute, and network layers we build on. The encryption, access-logging, and isolation guarantees described on this page are enforced by those providers' attested systems.

If your procurement process needs a data processing addendum (DPA), a vendor security questionnaire response, or a discussion about future attestation timing, email security@deltamarksystems.com. We respond within two business days.

Found a security issue? Email security@deltamarksystems.com with a description and reproduction steps. We acknowledge within two business days and update you weekly until resolution. Our security.txt file follows RFC 9116.