It is actually slightly worse than even that: while New Enemy [1] is the primary concern, caching like this can also introduce a staleness issue from the other direction: let's say a user adds a new row or document, and immediately sends the link to their coworker... who tries to load that piece of data, but the (stale) access control dataset is cached and they are not in it... they get a "no access" error. While certainly fail safe (vs fail dangerous for New Enemy), it can be a fairly important UX concern as well.

Generally, the solution is to keep a timestamp of when the data changed (Zookies as you mentioned) or you can proactively reload or recompute the cache when the underlying data changes (sometimes in very smart ways), but yeah: it adds significant complications over a "simplified" approach to Zanzibar.

Disclaimer: I'm the cofounder and CTO of AuthZed and we develop the SpiceDB [2] and Materialize [3], which have quite a bit of logic around these exact problems

[1]: https://authzed.com/blog/new-enemies#the-new-enemy-problem [2]: https://spicedb.io [3]: https://authzed.com/docs/authzed/concepts/authzed-materializ...