Blog
Cross-tenant isolation research, the recurring failure patterns behind it, and how to measure them on your own stack.
The Red Hat OpenShift AI credential read that skipped the admin check
A published Red Hat CVE in the Open Data Hub / OpenShift AI dashboard let any authenticated user read the cluster's NVIDIA NIM credential Secret. The create and delete were admin-gated; the read wasn't. Broken access control, found by the read-sibling method.
The read that checked the wrong organization
A published Medium advisory in Zitadel let an org member in one organization enumerate which authentication methods a user in any other org had registered. The write path had been fixed; the sibling read still checked the caller's org.
The preview endpoint that handed over everyone's API keys
A published High-severity advisory in Typebot let any workspace member, including a guest, decrypt another workspace's stored API keys. It's the same cross-tenant pattern we keep finding: the live path checks membership, a sibling path trusts the client instead.
I source-reviewed 200+ self-hosted AI tools for tenant isolation. 78 leaked.
The un-retrofitted read sibling, one recurring bug, across 78 of 200+ multi-tenant AI and SaaS products. The pattern, the fixes that shipped, and how to check your own.
How n8n, PostHog, and Supabase keep tenants isolated
The same review that found 78 cross-tenant leaks also turned up products that held. Reading the ones that passed, three isolation patterns keep showing up, in code you can read yourself.
What a 95.4% Retrieval-Pivot Rate means for your stack
What the Retrieval Pivot Attack research (95.4% of benign queries leaking cross-tenant) actually says about your multi-tenant RAG stack, and how to measure it for yourself.