The system underneath the decision.

// 1. Ingestion: ACL stamped into vector metadata
INSERT INTO vector_chunks (embedding, metadata_acl)
VALUES ([...], '{"allowed_users":["u123","u456"]}');

// 2. Revocation happens in the core database
// u123 is offboarded — the vector store isn't told

// 3. Drift window: still queryable
SELECT chunk FROM vector_chunks
WHERE metadata_acl @> '{"allowed_users":"u123"}'; -- leak

The window can run minutes to hours depending on re-index cost. During it, revoked access is still fluently synthesized into answers.

-- Executed BEFORE vector search, every request
SELECT c.id FROM tenants t
JOIN families f ON f.tenant_id = t.id
  AND f.quarantine_status = FALSE
JOIN children c ON c.family_id = f.id
JOIN user_assignments ua ON ua.child_id = c.id
WHERE t.id = :tenant_id
  AND ua.user_id = :user_id
  AND NOW() BETWEEN ua.effective_from
                AND ua.effective_to;

Revocation, suspension, or quarantine take effect in under a millisecond — there's no index to catch up, because permission was never stamped onto the vector.