Security · engineered, not promised
Every project XXI ships — the studio’s own infrastructure, every client engagement — runs on the same operational stack. The same encryption, the same access controls, the same backup cadence. We engineer once. The posture is uniform.
Posture
All traffic to every system XXI operates rides over TLS 1.3 with HSTS preloaded. All data lives in Postgres with AES-256 encryption at rest, managed in Sydney via Supabase. Embeddings, customer records, configuration, audit trails — encrypted columns where the application requires it, full-disk encryption everywhere else.
The encryption is not a checkbox. It is the floor. Below TLS 1.3, no system ships. Below at-rest encryption, no customer data persists.
Access
Service-role keys live server-side. Every privileged Supabase operation runs from a Vercel serverless function with the service-role key in encrypted environment storage. Client bundles ship with the anon key only — the same key that’s safe to publish on a static page.
Postgres row-level security on every customer table. Reads and writes are gated by auth.uid() — a customer queries only what their own session owns. Service-role bypass is reserved for server code; never invoked from a browser.
Admin surfaces gated by HTTP basic auth + non-discoverable routes. Operator dashboards live under /admin/* with noindex/nofollow headers and a credential pair that rotates per engagement. Vercel deploy protection covers preview branches.
Passwordless authentication via Supabase magic link by default. No password to leak, no password to hash, no password to forget. Password + TOTP available for engagements that require it.
AES-256-GCM application-layer encryption on PII fields. Email, phone, ABN, and free-text intake answers are encrypted with a per-write nonce before they ever touch the database — the service-role key alone is not enough to read raw contact details. Service-role key and encryption key together required. Defense in depth beyond Supabase’s at-rest disk encryption.
Hardening
Webhook signatures verified on every inbound payload — payment events, automation triggers, scheduled jobs. A spoofed webhook is rejected at the edge before it reaches application code.
Rate limits on every public endpoint. Burst limits for the highest-volume surfaces (capture, recall, key validation) plus IP-level circuit breakers. The endpoints that take traffic are the endpoints that survive traffic.
Cron routes fail closed. Missing or malformed authentication on a scheduled task halts the request, never silently bypasses. The default state of every scheduled job is unreachable until proven authorized.
Inputs sanitized across every surface that mounts to the public web. Stored XSS, SSRF via private-IP fetches, prompt-injection — reviewed against the OWASP 2026 catalogue and the specific failure modes of LLM-generated content.
Backups
Point-in-time recovery for every production database, retained 7 days on baseline plans and 30 days on extended plans. A misplaced delete at 11pm is recoverable to 10:59pm.
Australian data residency. Every Postgres instance runs in ap-southeast-2 (Sydney) on Supabase’s AU region. Vercel serverless functions for engagement projects are pinned to syd1. No customer data leaves the country in normal operation. International providers (LLM inference, transactional email) are documented exceptions, named per engagement.
Backup tests are part of the release process. Every quarter we restore a randomized point-in-time snapshot to a staging environment. A backup that has never been restored is not a backup.
Compliance
OWASP 2026 Top 10 reviewed at engagement start and again before every public deployment. Findings triaged into the engagement’s P0 list; nothing ships with an open P0.
GDPR-grade data handling by architecture. Export to JSON in one request, delete on confirmation. Consent recorded where applicable. Right to be forgotten is a query, not a project.
Manual security review before every customer launch. The same engineer who built the system audits the system. Reports filed under the engagement’s /security/ directory, retained for the life of the engagement plus seven years.
In practice
XXI’s own infrastructure runs on the posture above. Spine, Engine, the agency operating layer — same TLS, same RLS, same service-role isolation, same OWASP review cadence. The architecture we deploy for clients is the architecture we sleep behind.
Every quarter, an independent security engineer reviews the studio’s own infrastructure. The findings inform the next quarter’s engagement defaults. Nothing we ship sits below what we run on ourselves.
Resilience
Our infrastructure is engineered to fail safely. If a provider we depend on is breached — Vercel, Supabase, or any third party — your data does not become readable to attackers. The keys that grant database access and the keys that decrypt customer PII live in separate environments and rotate independently. A compromise of one is not a compromise of the other.
The specific layers between an attacker and a single client record:
auth.uid() on every customer table. Even with a leaked anon key, no client can read another client’s rows.Defense in depth means at least three independent failures must occur before a single client record is exposed. We engineer for that. We disclose if it happens.
A 30-minute call covers your data sensitivity, regulatory surface, and the specific posture the engagement will run on. A written summary lands the same week.