Security and compliance

This page is written for the person doing a security review. It describes controls that are implemented and verifiable in the running system, states plainly where each certification stands, and separates the two — because a control that works and a certification that has been audited are different things, and conflating them wastes your time and ours.

Where each framework stands

Identity and access

How the authorization boundary fails

Permission checks fail closed on every axis: an unrecognised role is denied, an unmapped resource is denied, an unrecognised method is rejected. The service refuses to start if any API entity is missing from the permission map, so a newly added table cannot ship silently unprotected — a deployment error rather than a quiet hole.

Credential-bearing resources — integrations, cloud connections, user accounts — are restricted to administrators for all writes regardless of role configuration. An ambiguous update that could create or modify requires both permissions, so a read-only user cannot route a creation through the update path.

Tenant isolation

Isolation is enforced in two independent layers, so a mistake in one does not expose data.

A query that arrives without tenant scope raises an error rather than returning an empty result. This distinction matters: silent emptiness looks like "no data" and gets shipped, while an error gets fixed. Scope is set per transaction, never on a pooled connection where it could leak between requests. Continuous integration rejects any new table that lacks a tenant column or a security policy, so the guarantee cannot quietly decay as the schema grows.

Encryption

The database is never publicly reachable. Network access is granted by security-group reference rather than by address range: the database accepts connections only from the application tier, the application only from the load balancer, and the load balancer only from the CDN.

AI processing and what leaves your environment

Thalamus uses large language models to investigate incidents. This is the part of the system most worth your scrutiny, so we describe it in full.

What is sent: incident context — telemetry, service names, log excerpts and configuration relevant to the investigation — to the model provider you configure. Supported providers are Anthropic, OpenAI, Azure OpenAI, and locally hosted models via Ollama. With a local model, no data leaves your environment at all and no sub-processor is involved.

What is stored: only a 160-character sanitized summary of each prompt is persisted. Full prompts are not retained.

The redaction gateway

Before any prompt reaches a model provider, it passes through a redaction gateway that detects personal data across eleven categories — email, phone, national ID, payment card, bank account, IP address, secrets, names, addresses, dates of birth, and patterns you define. Detection combines pattern matching with field-name classification, which catches what a regular expression cannot.

You choose how the gateway behaves, per instance:

If sanitization fails, the request fails — the system does not fall back to sending an unsanitized prompt. Detectors covering cardholder data, national identifiers, bank accounts and secrets cannot be switched off while the gateway is enforcing.

Every model call is recorded with its provider, region, model and legal basis, which is what an international-transfer register under GDPR Articles 44–49 requires.

Audit trail

Redaction and transfer events are written to an append-only table. Immutability is enforced by a database trigger that rejects updates and deletes, rather than by a permission grant — the application owns the table, and an owner can re-grant itself permissions it revoked. A trigger it cannot.

The audit log holds categories and counts, never the personal data itself; any preview is taken from the already-sanitized output. Scheduled retention is the one path permitted to delete, it must be explicitly authorized for that transaction, and it writes its own audit record before deleting anything. Retention below one year cannot be configured for audit tables. Configuration changes to the controls themselves — who changed which detector, when, and from what value — are recorded separately.

Your data: access, export, deletion

Sub-processors

Parties that may receive your data, depending on which integrations you enable. This list is derived from the routing table in the source, not from memory.

Data residency

You choose the region at signup, and the entire estate is provisioned there. There is no cross-region replication. Two exceptions to note: CDN edge caches serve static assets globally (no customer data), and your chosen model provider processes prompts in its own regions — the one place regional pinning does not hold, and another reason a locally hosted model is worth considering for strict residency requirements.

What we are working on

Published because a roadmap you can hold us to is worth more than a list of strengths.

Reporting a vulnerability

Email security@thalamusaicloud.com. We will acknowledge within two business days. Please give us reasonable time to remediate before public disclosure. We will not pursue legal action against good-faith research that respects customer data and avoids service disruption.