Trust

Security overview

Last updated 22 October 2026

Data minimisation

• The service grades a reply after it is sent and never sits in the reply's path; it cannot block, edit or delay one.
• The text of conversations is not stored. Each record keeps findings, signals, metadata and an HMAC of the conversation (keyed with a secret held outside the database).
• Quoted spans are kept only where the customer chooses, encrypted with AES-256-GCM under a key per organisation per month, each key wrapped by a master key held outside the database. Retention destroys keys; a closed account is purged after 28 days.
• Alerts, webhooks, emails and logs never carry conversation content, request bodies, query strings or headers.

Hosting and network

• Application on Vercel in Sydney (syd1); Postgres on Supabase in Sydney; the grader on Microsoft Azure Container Apps in Australia East.
• TLS everywhere, with HSTS. The database connection is encrypted and can verify the server certificate.
• Every page carries a Content-Security-Policy with frame-ancestors none, and the usual hardening headers.
• Outbound requests to customer endpoints (webhooks) resolve the address at send time and refuse every private, link-local and special range, so they cannot reach internal networks.

Separation between customers

• Every database transaction declares whose data it acts for, and Postgres row-level security enforces it: a customer's session can read only that customer's rows. The test suite runs as the application's database role with these policies on.
• API keys belong to one system: a key sees only its own system's records.

Access

• Customers sign in through their own Microsoft tenant (developers may use GitHub or Google). Access is denied by default: only people the organisation lists get in, in one of four roles, and every action checks the role on the server.
• Our staff sign in through our own Microsoft tenant and must be on an allow-list. They see metadata only: every staff read comes back from the data layer with quotes removed. Access to content (break-glass) needs a stated reason and a second member of staff, lasts four hours, and every view is written to the customer's own audit log, where the customer can end it.
• API keys are 192-bit random secrets, shown once and stored as SHA-256 hashes; they can be rotated with a 24-hour overlap, or revoked at once.

Integrity of the record

• Each record is sealed into a per-system SHA-256 hash chain; records are insert-only, enforced by the database role's grants and a trigger.
• Every grade response carries an Ed25519-signed receipt; attestations are signed; a signed Merkle root over every chain head is published daily, and each customer can obtain the proof that its head is included. Anyone can verify these offline with the published key.
• Chains are verified incrementally every night and on request, from genesis or from a checkpoint.

Operations

• Every change is tested in CI (type checks, unit tests, database tests under row-level security, the grader and both SDKs) before it reaches production.
• Hourly health checks of the grader, the queue, directory sync and instrument errors raise alerts to the operations channel; a status page shows the live state.
• Every API response carries a request id; errors are logged without content.

Planned, and not yet done

• An independent penetration test before general availability, then annually.
• A SOC 2 Type II programme, and ISO 27001 alignment documented.
• Moving to a dedicated database project, separate from The Digital Safeguard Centre's other systems.
• Single sign-on beyond Microsoft (SAML), and SCIM provisioning.

To report a vulnerability, write through support with “security” in the subject. We do not take action against good-faith research that avoids other customers' data and service disruption.