Identity siloing: making a breach boring
How Veil keeps real identities unreadable even if the entire application backend is compromised.
The usual promise of 'we encrypt your data' quietly assumes the application server is trustworthy. Veil doesn't make that assumption.
In Veil, real identities — legal name, email, employee ID — live in a private.identities table. That table is reachable only by a dedicated superadmin database role. The application connects as a separate role with no USAGE on the private schema at all.
What that means concretely
A fully compromised backend — even one with SQL injection — cannot read PII. The query simply has no permission to touch the schema. The blast radius of an application bug stops at pseudonymous data.
De-anonymization is possible, but accountable
A super admin can map an alias back to a real identity — through a separate, audited endpoint that uses the superadmin connection. The everyday application path can't, so the capability exists without being a standing risk.
Add end-to-end encryption for direct messages on top, and the server is left holding ciphertext and aliases. That's the goal: make a breach boring.