Security & Architecture

Built for the enterprise InfoSec reviewer.

This is the technical companion to /safety. Architecture diagrams, authentication details, audit retention, compliance posture, and the security questionnaire download. If your review needs a control ID we haven't covered, ask security@showops.ai — we respond in one business day.

Request security questionnaire Data Processing Addendum →

Architecture

Tenant isolation enforced server-side, never the UI.

Every tenant boundary is enforced at the lowest layer possible. Row-Level Security on every table. Org-scoping across every query path. No UI-layer filters that can be bypassed with a URL trick.

Tenancy & data isolation

Row-Level Security (RLS) on every table across every tenant schema. RLS policies match organization_id against the caller's JWT claim via current_user_org_id(); on routes that run under the restricted database role, cross-tenant reads and writes are blocked by the database itself, and every server-side query is additionally filtered by organization_id — verified by an org-scoping CI lint across every tenant schema. The browser anon-key client returns zero rows from every multi-tenant schema. New tables require RLS in the same migration (CI guardrail).

PROOF →JWT-backed RLS via current_user_org_id() · anon SELECT revoked · org-scoping CI lint

Per-tenant learning boundary (Shape B)

Multiple independent guards. App-level scoped client wrapper (orgId is a constructor invariant). CI grep (check-learning-scope.ts) fails the build if any file outside lib/learning/ touches the schema. DB-level strict RLS with FORCE ROW LEVEL SECURITY and session-var policy. Application code reaches the Anthropic SDK through a single choke point (lib/intelligence/llm/anthropic.ts, with lib/anthropic.ts kept as a back-compat shim), and check-anthropic-choke.ts fails the build on any import outside a short, commented allowlist; check-no-training.ts asserts no fine-tuning headers. No pooled training. No cross-tenant queries. Ever.

PROOF →lib/learning/client.ts · scripts/ci/check-learning-scope.ts · learning schema FORCE RLS

Hosting & encryption

All data at rest encrypted by Supabase (AES-256). All transport TLS 1.2+, HSTS preload. CSP with per-request nonce (no unsafe-inline scripts). Sensitive financial fields (BOM cost, sourcing, lead times) and external-integration OAuth refresh tokens carry an additional application-layer AES-256-GCM encryption layer at rest. Keys are managed through GCP KMS envelope encryption on a 90-day rotation; every new write goes through KMS, and rows written before the cutover are being rewrapped by a backfill job. No customer data on Vercel edge beyond CDN-cached public marketing pages.

PROOF →Vercel (US primary) · Supabase (US East) · TLS 1.2+ everywhere

Data residency

All customer data is processed and stored in a single US region — Supabase and Vercel, both us-east-2. EU or other regional data residency is not currently offered.

PROOF →US-only today · Supabase + Vercel us-east-2

Authentication & access control

8 roles, per-venue scoping, agent RBAC.

Every access decision runs through three layers: role → module → venue scope. Agents add a fourth: role → agent access → venue scope → data filter.

Role	Access tier	Venue scope
account_owner	Full · plus billing, SSO, org lifecycle	Org-wide
admin	Full · all modules · all venues	Org-wide
executive_producer	Full · all modules	Org-wide
producer	Full · all modules	Org-wide
technical_director	Technical tier · LLD + dispatch	Org-wide
venue_manager	Scoped read + check-in	Per-venue filtered
stakeholder	Summary read · milestones + alerts	Org-wide (filtered)
viewer	Support read-only · no infra data	Org-wide (minimal)

Session management

HMAC-SHA256 signed cookies, 12-hour expiry, sliding-window renewal at 50% lifetime (6h). Service role key never leaves the server. Magic-link admin invites (72h TTL, single-use, hashed at rest) replace password-based admin onboarding entirely.

SSO — Okta / SAML 2.0

SAML 2.0 is implemented end to end on the server. Each customer domain is registered against its own identity provider, and a SAML user is provisioned on first login from an existing invite: the ShowOps.AI role is resolved from the IdP's group claims and re-checked on every re-authentication, so a group change at the IdP moves the role here. Google Workspace and Microsoft Entra ID sign-in are wired on the invite acceptance screen. Domain-based SAML redirect from the login form is built but not yet enabled, so SAML tenants are onboarded with us rather than self-serve. SCIM provisioning is on the roadmap, not shipped. Timeline shared on request.

Audit & monitoring

Before, after, when, who.

Every mutation writes an audit record with before/after snapshots. 24-month retention. CSV export on request. No "trust me" compliance posture — the log is the proof.

Retention

24 months

Every audit record kept for 24 months with before/after snapshots. CSV export available on request for export-from-retention.

Coverage

100% of mutations

Every write through the API writes an audit record. Background jobs (sync, reconcile) also audit. Read access logged at route level.

Agent runs

Fully traceable

Every AI agent invocation logged in intelligence.agent_runs with inputs, outputs, prompt version, model, token counts. Runs link back to the data they cited.

Monitoring

Sentry + BetterStack

Sentry for errors + performance (per-endpoint sampling). BetterStack external uptime + paging. Supabase security advisor runs continuously.

Compliance posture

SOC 2-aligned. Attestation on the roadmap.

SOC 2-aligned architecture with completed internal gap analysis. The bulk of Common Criteria controls met today with running-in-production evidence; remaining gaps tracked explicitly in our internal working document. Type 1 attestation on the roadmap. We'll share the gap analysis under NDA on request.

Published today: DPA, AUP, Privacy, Cookies, Terms, Security (this page), Safety. GDPR posture follows the DPA. CCPA handled via Privacy policy.

Ask for a control-by-control mapping at security@showops.ai.

/legal/privacy /legal/terms /legal/dpa /legal/aup /legal/cookies /legal/security

Incident response

How we respond when something breaks.

Published disclosure timeline, published postmortem policy, one SLA for every reporter — internal, researcher, or enterprise reviewer.

Disclosure SLA

1 business day

Every report to security@showops.ai gets a human response in one business day. Coordinated disclosure welcomed — credit given with your permission.

Incident classification

P1–P4

P1 (data exposure / outage > 15min) — immediate page. P2 (degraded service) — same-hour. P3/P4 — scheduled triage. Affected tenants notified per DPA terms.

Postmortems

Published

P1 / P2 incidents get a blameless postmortem shared with affected tenants within 7 days. Root cause, timeline, remediation, structural changes.

Security Contact

For the reviewer digging in — ask for what you need.

Control mappings (CAIQ-lite, SIG-lite, SOC 2), network diagrams, sub-processor agreements, pen-test summaries (when available), DPA terms. We'll share what we have and flag what we don't. If your review identifies a gap we haven't addressed, that's exactly what we want to hear.

security@showops.ai Trust overview: /safety →