Revoke a permission, watch it stop leaking on the next read

Verity's read path makes no authorization calls. When an agent asks for memory, there is no ReBAC check, no group expansion, no round trip to a policy engine. The permission decision was baked into the index before the read arrived. That buys you fast, predictable recall. It also raises a fair question: if you never check permissions at read time, how does a revoked permission ever stop leaking?

No read-time check, yet revokes take effect

The design rule for Verity's read path is strict. Zero LLM calls, zero live ReBAC-engine calls on recall and get. Scope filters are materialized into the index and applied as mandatory pre-filters. Enforcement lives in one shared layer above the storage adapter, so no individual adapter can quietly forget to apply it.

That keeps recall fast and its cost bounded. You are not paying for a graph expansion on every query. But it means the index is the authority at read time, not a live permission engine. A stale index is a wrong answer, and a revoked share that has not reached the index yet is a leak.

The resolution is that a revoke is a write, not a read. It gets handled on the way in, ahead of the query, so that by the time an agent recalls, the wrong answer is already gone from the candidate set.

A revoke is a write, not a read. It gets handled on the way in, ahead of the query.

Walking the path: revoke to changelog to index to miss

Start at the source. Someone is removed from a Google Group, a Salesforce sharing rule is pulled, or a Drive file stops being shared with a person. The access is gone at the source system. Verity does not know yet.

The connector picks the change up on its truth lane: a poll that runs on a cadence and does full crawls, reconciling permission drift against the source. Verity is poll-first here by design. There is room for a push lane later, taking Drive change notifications or Salesforce CDC as a latency optimization, but those are not wired up today, and permission drift is never trusted to a webhook anyway, because webhooks are lossy everywhere. The poll is the guaranteed catch.

The change lands in an append-only changelog, the single record of what changed and when. It is ordered and durable, and the serving tier tails it. For a revocation, Verity writes a fail-closed tombstone into that log synchronously and durably, so the write is on disk before the revoke is confirmed. Today the serving core is single-node, and a durable tombstone is enough on its own. The multi-replica design, where a revoke is confirmed only after every live replica acknowledges the tombstone or is fenced out of the query path, is specified for the HA build; it is not something the current single-node core ships.

From the log, the change materializes into the index. The affected chunk's visibility tokens are updated, or the chunk is tombstoned for that subject. Nothing rewrites permission logic at query time. The tokens the pre-filter reads are simply different now.

Then the next recall runs. The pre-filter is a mandatory WHERE against those visibility tokens. The revoked subject no longer matches, so the chunk is never in the candidate set. The chunk is not retrieved and then filtered out. It is absent from the search entirely. No live authz call happened, because the revoke was baked into the index before the read.

The chunk is not retrieved and then filtered out. It is absent from the search entirely.

The architectural bet: a high-availability changelog

The mechanism leans on one thing being solid: an append-only changelog as the single record of what changed and when. Content updates, ACL updates, and revocation tombstones all flow through it. In the HA design, the serving replicas are stateless above it and rebuild their hot state by replaying it on cold start.

This is a deliberate bet. Correctness at read time reduces to two questions you can reason about independently. Did the change reach the log, and did the index materialize from the log. A revoke also gets a clean durability story: the tombstone is on the log before the caller is told the revoke succeeded, so a crash cannot lose it and a fresh replica cannot come up without it.

The read path stays dumb and fast on purpose. All the permission work happens on the write and sync side, once per change, instead of once per query.

The honest part: "next read" means after propagation

Read the title again with the emphasis in the right place. It stops leaking on the next read after propagation. There is a window between the revoke happening at the source and the index reflecting it. During that window, a recall can still return the memory. It is not instantaneous at the source, and nobody should deploy it believing it is.

Two things set the size of that window. Sync cadence is the first: how quickly the connector notices the change. There is no push lane wired up today, so the guaranteed catch for permission drift is the truth-lane poll, and the honest bound is that poll interval, which defaults to five minutes. The staleness fence is the second: recall carries staleness metadata and can fence out reads it cannot vouch for, which keeps a cold or lagging replica from serving confidently wrong answers.

There is a proof gap to be straight about. The continuous directory reconcile that carries group-membership revocations is built, and nested-group ACL inheritance is proven end-to-end and fixture-verified. What is not finished is the end-to-end live proof of a revoke propagating against a real production directory at scale. The mechanism above is real and the code exists. The claim I am not making today is a measured propagation-time number against a live tenant. Treat the timing as mechanism-described, not benchmarked.

The standing limits still apply here. Permission fidelity is only as good as what each source API exposes. Where a source is weak, for example Notion, which exposes no per-page sharing, the correct move is to fail closed and over-hide rather than guess. A revoke you cannot see at the source is a revoke Verity cannot propagate, so the fail-closed floor is doing the real work in those cases.

Run it yourself and try to make a revoke leak: github.com/RunAlphaLoop/verity