RAG Access Revocation Propagation Contract: Invalidate Stale ACLs, Caches, and In-Flight Answers Together

Applying ACL filtering before RAG queries does not mean that access revocation is reliable. After an administrator removes a member at 10:00, authorization replicas, vector filtering metadata, the query cache, assembled context, and citation pages may each retain the old decision. The end user sees that the identity store shows no access, yet stale requests continue returning content. RAG Retrieval Access Control defines where filtering occurs. This article addresses only how long stale decisions remain valid and at which boundaries they are invalidated when access changes from allow to deny.

Define the Revocation Window as a Service Contract

First, maintain a monotonically increasing aclEpoch for each tenant, while each resource has its own policyRevision. Whenever the authorization system changes a user, group, resource relationship, or policy code, it commits an event:

{
  "spec": "auth.change.v1",
  "tenant": "t_42",
  "aclEpoch": 1842,
  "resource": "doc_9",
  "policyRevision": 73,
  "effectiveAt": "2026-07-18T02:00:00Z",
  "eventId": "evt_01J..."
}

Event IDs are idempotent, and epochs never roll back. Consumers processing events out of order accept only higher watermarks. The team should commit to an observable target, such as a P99 of no more than five seconds from transaction commit until every online read path denies a high-risk revocation, rather than vaguely claiming that "permissions synchronize in real time." The index should store only the tenant, resource, and a stable policy reference. It must not copy tens of thousands of members into every chunk and then wait for a full re-embedding operation.

Bind a Decision Credential to a Single Retrieval

The query gateway obtains the subject and tenant from a trusted session and requests a short-lived decisionToken from the authorization service. At minimum, the credential binds the subject, tenant, allowed policy set, aclEpoch, policy digest, request purpose, issue time, and expiration time. It may be a signed object or an unguessable server-side handle, but the browser must not be allowed to append fields. Vector retrieval uses the allowed set for pre-filtering, and the system confirms before context assembly that the local revocation watermark has not advanced beyond the token's epoch.

This does not require remote authorization for every chunk. The gateway may cache allowed sets by decision digest, but the key must include the subject, tenant, purpose, policy digest, and epoch. As with MCP Multi-Tenant Isolation, omitting any dimension that affects authorization can cause cross-tenant leakage. Unlike an ordinary performance cache, the maximum age of an authorization cache must be shorter than the revocation SLO.

Cut Off Caches, In-Flight Generation, and Citations Together

A revocation event first advances the gateway's deny waterline, then asynchronously clears the result cache, private mappings in the embedding cache, and the historical answer cache. However, a node reporting that it has "applied 1842" does not prove that it remains fresh. During request admission, it must obtain a short lease on a linearly consistent tenant fence, or read the authoritative head offset, and prove that its local lastAppliedOffset has caught up to that fence. If the lease expires, the fence cannot be reached, the offset falls behind, or consumer readiness exceeds the SLO, the node must immediately be removed from traffic and reject protected queries. This prevents a missed invalidation message from allowing an isolated node to reuse stale allow decisions indefinitely. RFC 9111 cache directives can be used at the HTTP layer, but they cannot replace this application-level proof of freshness.

Long-running generation may continue producing output for dozens of seconds after retrieval. Having the client discard unconfirmed chunks only improves UX; it is not a confidentiality boundary. High-risk responses are buffered by semantic segment on the server. Before releasing each segment, the server obtains the current tenant fence again, confirms that the authorization lease has not expired and the local offset has caught up, and rechecks access to cited resources. If any check fails, it discards the buffer and terminates with REVOKED_DURING_RUN. Bytes that have already been released cannot be recalled, so direct streaming for low-risk responses must also expose this window explicitly. Expanding citations and downloading content always require fresh authorization. The duration and revocation epoch from Short-Lived Capability Leases can be reused, but RAG must also cover retrieval results and answer caches.

Recalculate Propagation Results Using Event Watermarks

Each component reports appliedAclEpoch{tenant, component} and its processing time, but tenant IDs must not be used directly as unbounded metric labels. They can be written to a queryable audit table and aggregated by risk bucket. After a revocation transaction returns an eventId, the acceptance harness repeatedly executes the same query, stale cache key, stale decision token, in-flight stream, and old citation URL until all are rejected, then records max(rejectedAt)-effectiveAt. Each day, it samples and compares authorization relationship snapshots with policy references in the index, preventing an event pipeline from running reliably while consistently omitting a particular resource type.

Fault injection must cover at least lost invalidation messages, an unreachable tenant fence, lease expiration, a stalled consumer offset, read-replica lag, cache-node isolation, and revocation during generation. Assert that stale nodes fail readiness, high-risk buffers release nothing, and the number of unauthorized chunks after revocation is zero. The system must not fall back to global retrieval "to preserve availability." Revocation traces record only resource IDs, reason codes, and digests. Sensitive evidence retention follows Prompt and Trace Telemetry Governance.

Neither Deployment nor Rollback Lowers the Watermark

First, run the new authorization pipeline in shadow mode and compare the old and new allowed sets. After confirming that the new policy does not unintentionally broaden access, enable mandatory epoch enforcement for internal tenants, then expand it in batches. Release gates include the full negative identity matrix and propagation P99, not only recall for normal users. If the new policy incorrectly denies access, the previous policy implementation and index reader can be restored. A committed aclEpoch must never roll back, old tokens remain invalid, and the new reader must issue new decisions using the current watermark.

If the authorization service is unreachable, protected collections deny access by default or return only explicitly public material. They must not continue using stale allow results indefinitely. Compensation and reconciliation for index event anomalies still follow RAG Incremental Indexing Consistency. A measurable completion condition for revocation is that every read path proves the stale decision has been invalidated, not that an administrative page displays "Member removed."

Further Reading

• RAG Retrieval Access Control
• MCP Multi-Tenant Isolation
• RAG Incremental Indexing Consistency
• Short-Lived Capability Leases