Trust Center
The technical case for trusting Brain with your data.
NitroxBrain holds OAuth access to mail, files, calendars and CRM — so IT and legal teams are right to scrutinise it. This page is written for them: the architecture, the cryptography, the data-residency map, the sub-processors, and the certifications, with no marketing varnish. For the plain-language version, see the Security page.
NitroxBrain has passed the App Defense Alliance Cloud Application Security Assessment (CASA) — Tier 2 (lab-tested, lab-verified), conducted by DEKRA, an independent authorised security laboratory, against the OWASP Application Security Verification Standard (ASVS) — authentication, access control, data protection, cryptography, communications and API security among them — and passed every category. Certification ID 276ad600, valid 23 Jun 2026 → 24 Jun 2027.
The full statement of validation is available under NDA on request. SOC 2 Type II / ISO 27001 readiness is targeted for H2 2027 — not a current claim. We target 99.5% monthly availability for the chat surface; there is no contractual SLA in V1 (enterprise SLAs available on request).
Architecture
Four independent isolation layers
There is no shared multi-tenant store for your messages, files, or memory. Each subscriber runs in their own Cloud Run service, with their own vault bucket, database, and secrets. To pivot from one user's data to another's, an attacker would have to break IAM and OAuth scoping simultaneously — the layers below are each, on their own, sufficient.
Token at rest — IAM-scoped buckets
Each user's OAuth tokens live in gs://nitroxbrain-vault-<slug>/.credentials/. Bucket IAM grants object access only to that user's runtime service account. No other container holds a credential that can read it.
Runtime filesystem — single mount
The per-user Cloud Run container mounts only that user's vault bucket (via gcsfuse) at /app/Memory. There is no cross-user bucket on the filesystem to traverse.
OAuth scope — bound by Google
Each refresh token is bound at issuance to the granting user. Google's token endpoint only ever returns access tokens for that user's own resources — the scope boundary is enforced provider-side, not just by us.
Identity routing — dispatcher
Inbound messages route by sender_id → user_routes → target_url. A message physically cannot be delivered to another user's container; the routing table is the only path in.
Deliberately shared (and safe because the boundary is enforced elsewhere): the OAuth client ID (Google scopes per-user at the token layer) and the directory service account (used only for Chat delivery and directory lookups, with a tightly controlled impersonation subject).
Cryptography
Encryption, specifically
Exact primitives, not 'bank-grade'.
At rest — AES-256 (Google-managed)
All GCS vault buckets and Lightsail block storage are encrypted at rest with Google-managed AES-256. Per-user separation is enforced by IAM, not per-user keys (no CMEK today — an option if a customer requires it).
Application-layer token encryption
Slack and Teams bot tokens are additionally encrypted at the application layer with Fernet (AES-128-CBC + HMAC-SHA256); the keys live in Google Secret Manager, separate from the database.
In transit — TLS 1.2+ (1.3 preferred)
Public traffic terminates on Caddy with Let's Encrypt certificates; the Postgres link enforces sslmode=require with a real CA-issued certificate; Cloud Run ingress is mTLS.
OAuth tokens — per-user, IAM-fenced
Each user's OAuth tokens sit in their own vault bucket, readable only by their container's service account. A token is never copied into another user's runtime.
Data residency
EU-only core, by design
Compute + memory: europe-west1 (Belgium)
Your per-user container and your vault (conversation memory + files Brain creates) run in Google Cloud europe-west1.
Routing + dispatcher: eu-west-3 (Paris)
The routing database and the message dispatcher run on AWS in Paris. Teams ingress (transient only) is Azure westeurope (Netherlands).
No US core hosting
No core infrastructure sits in the US. US exposure is limited to sub-processor APIs (LLM, payments, web search) called per-turn under DPF / SCCs — listed in full below. Voice-memo transcription is EU-resident by default (AssemblyAI, Dublin).
Third-party content stays at the source
The mail, files and events Brain reads from Gmail / Drive / OneDrive / HubSpot live wherever those vendors host them. We relay that data per-turn; we don't relocate it. Enterprise Google Workspace / Microsoft 365 can pin those to the EU.
Article 28
Sub-processor register
Every third party that may process your data, what it does, where, and the transfer basis.
| Sub-processor | Function | Location | Transfer basis |
|---|---|---|---|
| Google Cloud (Gemini) | Hosting — compute, per-user vault, Secret Manager; optional LLM/STT | EU — europe-west1 (Belgium) | EU — no transfer |
| AWS | Dispatcher, routing DB, static site, contact-form mail (SES) | EU — eu-west-3 (Paris) | EU — no transfer |
| Microsoft Azure | Microsoft Teams ingress (transient routing — no content store) | EU — westeurope (NL) | EU — no transfer |
| Mistral | LLM inference (alternative engine, opt-in) | EU — France | EU — no transfer |
| OVH | Support-mail forwarding | EU — France | EU — no transfer |
| AssemblyAI | Voice-memo transcription (default backend) | EU — eu-west-1 (Dublin) · default | EU — no transfer · US via configuration: DPF / SCCs |
| Anthropic (Claude) | LLM inference (default engine) | US | DPF / SCCs · no-training |
| OpenAI | LLM inference (alternative engine) | US | DPF / SCCs · no-training |
| Tavily | Web search (only when a search actually runs) | US | SCCs |
| Stripe | Payments / billing | US | DPF / SCCs |
| Google Analytics 4 | Website analytics (consent-gated only) | US | DPF / SCCs · consent |
Not sub-processors — user-directed independent controllers: HubSpot, Trello, Oura, and your own Google / Microsoft accounts. You connect these directly via their OAuth screens; they process your data under their own terms, on your instruction, not ours.
Data Processing Agreement (DPA): our standard GDPR Art. 28 DPA (incorporating this sub-processor register and the EU SCCs for the US transfers above) is available on request — ask via /contact and we'll send it for signature.
Retention, deletion & audit
What we keep, for how long, and how it's tamper-proof
Deletion you can verify, records you can't quietly alter
The point of a hash chain is that nobody — including us — can edit history without it showing.Tiered retention
Live operator-access audit: 18 months. Operational error logs: 90 days. Account + OAuth data: deleted within 30 days of termination. Audit log offsite: 7 years (WORM).
GDPR Art. 17 erasure
On cancellation we tear down your container, empty your vault bucket, revoke OAuth tokens on our side, and hard-delete your database rows — confirmation email when done, 30-day hard target. The 7-year audit retention is the one lawful exemption (Art. 17(3)).
Tamper-evident operator audit
Every operator access to a user resource is written to a SHA-256 hash-chained table (each row hashes the previous), with an INSERT-only writer role and a separate purger role that RLS restricts to rows older than 18 months — operators cannot rewrite or delete recent entries.
7-year WORM offsite
The audit chain is copied hourly to a Cloud Storage bucket with a 7-year object-retention lock — immutable, so even operator credentials cannot rewrite or delete it. A verifier script re-checks chain integrity across retention boundaries.
Your data is not used to train models
We do not train any model on your data, and we do not sell it. The third-party LLMs Brain calls (Anthropic Claude, OpenAI GPT, Mistral, Google Gemini) run on API tiers with no-training data-handling agreements, which each vendor publishes for their API. Third-party content is transient — it lives in a single turn and is not retained for training.
Sending this to your IT or legal team?
Happy to walk through the architecture, the CASA report, a DPA, or the sub-processor list on a call. The Enterprise Security Whitepaper (PDF) is available on request via /contact.