Viewer tokens retain access after dataset switched from private to public

When a Sanity dataset is changed from private to public, any existing viewer‑scoped API token instantly gains read access to all documents in that dataset.

This transition occurs without a new token issuance, without an explicit audit‑log entry linking the token to the new visibility state, and without automatic token revocation, leaving administrators uncertain about which credentials now enjoy unrestricted read rights.

The goal is to understand the exposure window and to determine whether any built‑in safeguards can be applied to prevent unintended public access when toggling dataset visibility.

What audit information is available to identify which tokens acquire access after a visibility change? Are there configuration options or operational practices that can enforce token re‑validation or limit the impact of a dataset visibility switch? Is it possible to configure short‑lived tokens or automatic revocation so that a leaked viewer token does not retain indefinite access after a dataset is made public?