Security

• Connections to the edge use TLS 1.2 or above, with TLS 1.3 preferred and HSTS set. Plain HTTP redirects to HTTPS.
• Database connections enforce TLS server side with full certificate verification.
• Outbound calls to model providers verify certificates. Disabling verification is blocked at error severity by our compliance gate, so it cannot reach a branch that merges.

• AES-256 volume encryption on every datastore.
• Dedicated, non-exportable KMS keys with rotation enabled on the primary database, the support database and the support cache.
• Object storage and snapshots encrypted with KMS-managed keys.
• Automated encrypted backups with point-in-time recovery on the production database, and deletion protection on the production cluster.

• Keys we issue you are scoped, rate-capped, budgeted and revocable per environment. The secret is displayed exactly once, at creation.
• Those keys are stored as a one-way SHA-256 hash rather than as recoverable ciphertext. We cannot show you a key you have lost, because we do not hold one.
• Our own secrets are held in a managed secrets store and fetched at process start. None is written into a build artefact or a source file, and commits are scanned for secrets before they land.

• Prompt and completion bodies are not persisted. They are processed in order to serve the request and are not written to any store.
• Logging records metadata only: model, tokens, cost, latency, routing reason and error state. No code path writes request content to a log or to a table.
• Support staff cannot retrieve the text of a request, because it does not exist to retrieve.
• Secrets and personal data are never written to application logs. That is enforced by the compliance gate rather than by convention.

Which third parties receive request content, and what they may do with it, is set out at Sub-processors.

• Every tenant-scoped table enforces database row level security in FORCE mode, derived from the authenticated credential. The browser never supplies a tenant identifier.
• Cross-tenant reads are possible only through narrowly scoped definer functions, each returning a single value and unable to mutate data. No role in the system holds a bypass privilege.
• Internal staff access to the operator console requires a separate identity pool with multi-factor and step-up authentication.
• Balance adjustments require separation of duties: one operator proposes, a different operator decides.
• Production access is limited to those who need it, reviewed, and revoked on termination.

• Every privileged mutation writes an immutable audit entry in the same database transaction as the action itself. A failed audit write fails the action.
• The credit ledger is append-only, enforced by database triggers and revoked privileges rather than by application convention. Corrections are new entries, never edits.
• Operator actions against a customer tenant are recorded in a separate, hash-chained operator audit log. Our access to your workspace is audited the same way yours is.

Most of the page above is a policy somewhere else. Here it is a build failure. A compliance gate runs on every push and in the pipeline, and blocks the merge if a change logs a secret, disables TLS certificate verification, writes prompt or completion bodies to a store, or introduces a third party without updating the published sub-processor list in the same change.

Merging also requires a protected branch, code-owner approval, and both continuous integration and that gate passing. The point is not that we are careful. It is that being careless does not compile.

Every trust page on the internet is a wall of green ticks, which is why none of them is worth reading. These are the things we have not done. They are stated so the rest of the page can be checked against the system rather than taken on trust.

SOC 2 Type 2

Not held. No attestation exists, and we will not imply one does. We will publish the date the audit window opens.

ISO/IEC 42001

Not held. Alignment in progress.

Regions

One production region is deployed today, in the United States. Each workspace carries a region pin set at creation and immutable afterwards, so a workspace cannot silently drift across a border. Further regions, including the European Union, are designed and not yet live.

Customer-managed encryption keys

Not offered.

Bring your own provider keys

Not offered. Deferred rather than in progress.

Automated retention purge

Retention periods are set out in the privacy policy. Enforcement by a scheduled job rather than by policy is being confirmed, and this row will say which once it is.

Mechanised data subject export and erasure

Not implemented. Requests are handled manually, within the period the privacy policy commits to.

Multi-factor authentication for console users

Not enforced for customer accounts. Deferred and formally risk accepted. Operator accounts do have it.

Penetration test

None commissioned. There is no report to request, and we would rather say so than leave the question unanswered.

Write to hello@neuralarc.ai with "security" in the subject line and enough detail to reproduce the issue. We will acknowledge it, and we will not pursue anyone who reports a genuine finding in good faith and gives us a reasonable chance to fix it before disclosing it. The same address is published at /.well-known/security.txt.

Good faith research is welcome, and the boundaries of it are set out under Harm to systems in the Acceptable Use Policy. Tell us before you start rather than testing first.

Our contractual security commitments, including breach notification, sit in Annex B of the Data Processing Agreement.