TenantIso — Multi-Tenant Isolation Audit
Audits 14 seeded multi-tenant systems against 7 isolation surfaces: row-level security, schema boundaries, K8s namespace, S3 prefix, cache-key prefix, Kafka topic ACL, search index per tenant. Catches every cross-tenant leak vector a SOC2 reviewer would find.
What it is
The 7-layer audit a SOC2 reviewer actually runs across a multi-tenant stack. For each system: do queries filter by tenant_id? does row-level security enforce it at the DB layer? does the cache prefix isolate? does the Sentry project leak across tenants?
What it catches
- 14 seeded systems spanning the realistic stack: users-db (RLS), Snowflake (row access policies), S3 user uploads (prefix isolation), Redis (key prefix), OpenSearch (document-level security), Kafka (topic ACL per tenant), Next.js web app, Celery jobs, Datadog logs, Sentry (single project — flagged), Auth0 (per-tenant org), Cloudflare CDN, EKS, cron jobs.
- 7 isolation checks per system — Row-level security · Schema/boundary separation · Tenant key on all queries · Admin access logged · Backups encrypted · Network segmented · Audit trail retained.
- State per check: ok / warn / bad / n/a. Each carries the specific configuration evidence or the gap that an auditor would flag.
- Per-system risk score weighted by gap severity. Sorted by risk first.
- Two seeded leak surfaces in the catalog match real-world patterns: the admin route bypassing middleware in Next.js (a CVE-class hole) and the single shared Sentry project (a Datadog Sentry config-cost trade-off most companies don’t audit until breach).
Why this shape
Multi-tenant data isolation is the #1 SOC2 CC6.6 audit finding. The reviewer doesn’t ask “is your system isolated” — they ask 7 questions per system. TenantIso prototypes that exact shape.
How it ships
Single HTML file, ~28KB. Zero dependencies. The 14-system catalog, 7-check audit logic, and per-system detail panel are 320 lines of vanilla JavaScript.