ClaudeDrive assembles each person's daily update from only what they're permitted to see. The rest of this page is the handful of guarantees that make that true — written plainly first, with a "For your security team" note under each one for the people who want the precise mechanics. We've also named the one trade-off we make, because a security story you can trust is one that doesn't hide its edges.
The guarantees
What we promise, and how it holds.
Each guarantee is a property of how the system is built — not a setting an operator can switch off. Open "For your security team" on any of them for the enforcement mechanism.
Everyone sees only what they're allowed to
Each person's update is built only from what they're permitted to see. The default is to share nothing, and a Block always wins.
For your security team
Permission is enforced at retrieval, not by an app-layer post-filter. The per-person access-control list lives inside the single retrieve() SQL: an EXISTS allow-check combined with a NOT EXISTS deny-overrides check, where an empty grant set is default-deny. There is never a superuser read path and never an after-the-fact redaction step — retrieve()is the sole reader of the content pool, so content a person isn't permitted to see never enters their result at all.
Nothing is made up
Every line traces back to a real source. Anything that can't be backed up is left out, and a maybe is never reported as a done deal.
For your security team
A deterministic anti-slop validatordrops any claim whose source span isn't in the actor's permitted set — so the model can never "fill in" an unsupported line, and can never surface a span the actor wasn't allowed to retrieve. Modality is preserved (an unconfirmed item stays unconfirmed; a verbal yes is never reported as a signed contract), and gaps are computed outside the model so a missing update is shown as a gap rather than smoothed over.
We never guess who someone is
If we can't tell which person something belongs to, we ask you. We never guess and never quietly hand out access.
For your security team
An ambiguous identity is routed to a human review queuerather than resolved automatically. The system never auto-attributes content to a person and never auto-grants access on a best-guess match — until a human confirms the identity, the content stays unattributed and out of everyone's scoped view.
Removing someone is immediate and verified
Remove a person and their access is cut off at once and pulled from every future update. We verify it's gone before giving you a receipt.
For your security team
Offboarding fails closed. In one operation it deactivates the person, revokes their linked identities, writes a durable hard-deny, and then runs a synchronous render-as-zero verification — re-running retrieve() as the removed person and confirming it returns nothing — before the receipt is issued. If any step fails, the receipt is not produced; access is never left half-revoked.
Your company's data stays yours
Nothing crosses between companies.
For your security team
Every query is per-tenant scoped, and the schema carries composite tenant foreign keys so a row can only ever be joined within its own tenant. As defense-in-depth, row-level security (RLS) is available for multi-tenant deployments, so the isolation is enforced at the database layer as well as in application queries.
A full audit trail
Every update we deliver is traceable to where it came from, and you can re-check it against today's permissions.
For your security team
Each render records per-render provenance — which source spans backed which lines — and supports a logged-vs-current replay: you can re-run a past render against the current permission state and diff what would be included now versus what was included then, so a permission change is auditable after the fact.
One honest trade-off
If a permission changes faster than a connected app updates, there's a brief window where a just-changed rule might not be reflected yet — we flag every such case for you, as a count, never the content. Known removals are always immediate.
For your security team
A stale permission from an upstream connector is fail-open-with-alert by deliberate design during the current synthetic-demo phase: the affected items are surfaced to you as a count, never as content. A known revocation always fails closed (see immediate, verified offboarding above). The leak-invariant test suite — which proves no denied span can reach a scoped render — is a required CI gate, so this trade-off is the one stated exception rather than an unbounded gap.
See it hold
Watch the same pool resolve to a different view per person.
The live demo runs the exact permission-aware retrieval path production uses: two people ask the same system over the same context pool and get different scoped views — the denied content never enters the other person's result, it isn't redacted after the fact.