At a glance

gbrain.io’s architecture puts each customer’s data on dedicated, single-tenant compute: one Fly Machine and one Fly Volume per brain, on its own private network. There is no shared application database where customer data lives. The control plane (workspace, billing, membership) runs in a separate environment from any brain.

We do not hold SOC 2, ISO 27001, or comparable third-party certifications. The sections below describe what is in place today.

1. Architecture

Two planes:

• Control plane (“mothership”) — a Phoenix application that handles authentication, workspace management, billing, and brain orchestration. One Fly application per deploy target (gbrain-staging, gbrain-production), one Postgres cluster per target. The control plane never holds customer-content data; it holds workspace metadata, OAuth tokens (encrypted), and audit records.

• Tenant compute — one Fly Machine per brain, named gbrain-tenant-<target>-<brain-id>. Each tenant Machine has its own custom 6PN private network (no shared default network), no public IPv4, no public IPv6, and a private_v6 address only. The mothership reaches each brain over a flycast private endpoint. Tenants cannot reach each other.

The two planes are deliberately decoupled. Compromising the mothership does not by itself give an attacker the contents of a tenant brain; compromising a tenant brain does not give them anything outside that brain.

2. Tenant isolation

Each brain runs in a Firecracker microVM (the same isolation technology that backs AWS Lambda). Per brain:

• Its own kernel, memory, and process space. No shared user-space with any other tenant.
• Its own NVMe volume, encrypted at rest, mounted only inside its microVM.
• Its own custom Fly 6PN network, not the org-default network. Kernel-level eBPF rules block tenant ↔ tenant traffic at the platform layer.
• No public IP. No inbound internet traffic. Outbound is allowed for the agent’s calls (AI model API, the public sources it crawls).

A safety layer in the control plane (Adapters.Fly.Safety) verifies after every tenant app creation that the resulting app has only a private_v6 IP and aborts if it doesn’t. This is the layer that prevents a configuration mistake or a malicious actor with control-plane code execution from accidentally allocating a public IP to a tenant brain.

3. Encryption

• In transit (external): TLS 1.2+ enforced on all public endpoints. HSTS enabled.
• In transit (internal): Mothership ↔ tenant traffic rides Fly’s private 6PN, end-to-end inside the WireGuard mesh.
• At rest (Volumes): Each tenant Volume is encrypted at rest by Fly.
• At rest (Postgres): Managed Postgres encrypts disks at rest.
• At rest (application layer): OAuth tokens for connected channels and any other field marked sensitive are encrypted at the application layer (AES-GCM with a per-target master key) before being written to Postgres. The master key is provisioned as a Fly secret, not committed to the repo.
• Backups: Fly snapshots Volumes daily for disaster recovery. Snapshots are encrypted and tied to the originating Volume. When a brain is deleted, its snapshots age out on Fly’s schedule.

We do not offer end-to-end encryption. The agent inside each brain reads your team’s content in cleartext to summarize it; that’s intrinsic to the product. Anyone offering “end-to-end encrypted” hosted summarization is misleading you.

4. Authentication

• Sign-in: Google OAuth only. We don’t store passwords. We don’t accept password sign-up.
• Session: signed cookies, secure flag, HTTP-only, SameSite=Lax. CSRF tokens enforced on all state-changing endpoints.
• Admin sign-in: Same path as everyone else. Admin status is a server-side allowlist of email addresses; non-admin emails get 404s on /admin/* routes (404, not 403, so the section’s existence isn’t disclosed).
• API keys: None today. The product surface is the web UI. A read-only programmatic API for customers will get its own auth model when it ships.

We don’t have SSO/SAML today. SCIM provisioning isn’t in the product yet. Both are on the roadmap; if your security review requires either, tell us.

5. Authorization

• A workspace owns its brains. A user belongs to one or more workspaces with role admin or member.
• Admins can create and delete brains, change workspace membership, and manage billing.
• Members can use any brain in the workspace.
• A user with no workspace membership cannot reach any brain.
• Per-brain ACLs (which member can use which brain) are not in V1. They land when a customer asks for them.

Every authorization check happens server-side. The web UI hides things you can’t access; the server also rejects requests for them.

6. Operational practices

• Deploys: Manual today. One human triggers each deploy with ./gb <target> fly deploy and watches it boot. Migrations run as a Fly release command before the new image serves traffic.
• Staging-first: Every change rolls to staging before production. Production fixes for incidents are the only exception, and they get post-hoc staging soak.
• CI gates: Every pull request runs a full test suite (820+ tests), boundary checks (compile-time enforcement that web code can’t reach into infra adapters directly), secret scanning of the diff, migration-reversibility checks, and dependency vulnerability auditing.
• Code review: Changes that touch authentication, billing, or the safety layers around tenant provisioning get a second pair of eyes before merging.
• Backups: Volume snapshots daily (Fly), Postgres point-in-time recovery (Fly Managed Postgres). Off-platform backup export is on the roadmap; until it ships, leaving Fly entirely would lose pre-migration backup history.

There is no 24/7 on-call rotation today. Production deploys are watched on push, and engineering is paged on hard outages.

7. Logging and monitoring

• Application logs: Structured logs from the mothership, retained 30 days. They include request IDs, durations, status codes, and anonymized user IDs. They do not include request bodies or response bodies.
• Audit log: Workspace-scoped log of administrative actions (sign-in, brain provisioned, brain destroyed, member added, member removed, OAuth token refreshed). Retained 1 year.
• Platform logs: Fly’s platform-level logs and metrics, retained per Fly’s terms.
• Activity bus: A tenant brain emits an internal activity stream (which crawl ran, what it found, what notifications it sent). This is visible to the workspace’s admins via the brain UI; it’s not transmitted off the brain except to render in the UI.

8. Vulnerability handling

If you find a security vulnerability in gbrain.io, please email security@overton.xyz. Include:

• A description of the issue.
• Steps to reproduce, or a proof of concept.
• Your name (so we can credit you, if you want) and how to reach you.

What you can expect:

• An acknowledgement within 2 business days.
• A fix or a written plan to fix within 30 days for high-severity issues, with status updates if it takes longer.
• Public credit, with permission, after the fix ships.

We don’t currently run a paid bug bounty. We will make exceptions for issues that are clearly serious; ask.

Please don’t:

• Run automated scans against production. Spin up a test workspace and scan that.
• Access, modify, or destroy data that isn’t yours.
• Disclose the issue publicly before we’ve shipped a fix or before 90 days have elapsed (whichever is sooner).

9. Incident response

If we have a confirmed incident affecting customer data:

1. Contain (revoke compromised credentials, isolate affected systems, halt the spread).
2. Assess (what data was affected, what actions were taken, who is impacted).
3. Notify affected workspace admins by email — target within 72 hours of confirming the incident, sooner if law requires.
4. Remediate (root-cause fix, deploy, verify).
5. Post-mortem in writing, shared with affected customers, summarized publicly if appropriate.

We have not had an incident affecting customer data to date. When we have one, we’ll publish the post-mortem.

10. Compliance status

For customers who require an attestation we don’t yet hold, contact security@overton.xyz.

11. Bring your own AI key

By default, brains call Anthropic’s Claude API using our key. Customers can opt to provide their own Anthropic key on a per-workspace basis; in that case, Anthropic bills you directly and the model traffic carries your key, not ours.

Self-hosting the AI model isn’t supported today.

12. Changes to this page

This page lives in our public git repository. Every revision is a public commit; the diff is the audit trail. Material changes (architectural changes that affect tenant isolation, certification status, encryption posture) get email notice to workspace admins at least 30 days before they take effect.

13. Inquiries

• Vulnerabilities: security@overton.xyz
• Security questionnaires, DPAs, audit requests: legal@overton.xyz
• Operational status: reply to any email from us, or check https://gbrain.io/.