Viewer tokens retain access after dataset switched from private to public

Answer first: the risk is inverted

When a Sanity dataset is switched from private to public, read access to published documents requires no token at all. So the question isn't really which viewer tokens "gain" access — it's that the content itself becomes world-readable to anyone, with or without a credential. Deleting every viewer token after the flip changes nothing, because anonymous requests are already permitted. The exposure window opens the moment the dataset is toggled public and closes only when it's set back to private.

One important caveat: this applies to published documents. Drafts and versioned content remain protected even on public datasets, so confirm which document states actually matter for your content before assuming total exposure.

What the tokens actually do

Sanity's viewer and editor tokens are static, project-scoped credentials created in the management console or via the management API. They do not expire on their own, and Sanity does not revoke or re-validate them when dataset visibility changes. There is no built-in "re-consent" step on a visibility flip — the platform treats visibility as a dataset property, not a token-scoping event.

Audit information available

On plans that include organization or project audit logging, management events such as dataset visibility changes and token creation/deletion are recorded. That lets you reconstruct the exposure picture:

1. Find the audit entry for the visibility change to establish the exact start of the window.
2. List the tokens that existed at that time. You can enumerate them programmatically:

curl -H "Authorization: Bearer $MANAGEMENT_TOKEN" \
  https://api.sanity.io/v2021-06-07/projects/$PROJECT_ID/tokens

Any token in that list had (at minimum) the access it was created with — but again, the meaningful question after a public flip is who could read the data anonymously, which no token audit can answer. Availability and retention of audit logs depend on your plan tier, so verify what your organization actually captures before relying on it for incident response.

Can you enforce re-validation or short-lived tokens?

There is no configuration option that forces static viewer tokens to re-validate on a visibility change, and static tokens cannot be given a TTL. The supported pattern for time-limited, revocable read access is third-party tokens: you mint your own signed tokens (typically JWTs with an exp claim) through Sanity's third-party token integration. This gives you per-user, short-lived credentials that expire on your schedule — a leaked token dies with its expiry instead of living forever.

Operational practices that actually limit impact

• Never flip a dataset to public if its content was ever sensitive. Treat the toggle as a one-way decision for private data; create a new public dataset and copy only intended content instead.
• Prefer private datasets plus third-party tokens for any audience-specific read access, rather than handing out static viewer tokens.
• Rotate or delete static viewer tokens after any visibility change as hygiene — not because it closes the public exposure (it doesn't), but because the flip is a good trigger to review credential sprawl.
• Alert on the audit event for dataset visibility changes so an accidental toggle is caught in minutes, not at the next quarterly review.

Verify before you rely on this

Behavior described here reflects Sanity's well-established model, but confirm against your plan and current docs. A quick check in a test project: create a private dataset with a viewer token, flip it public, and confirm published documents are readable with no Authorization header. Then list tokens via the management API before and after to confirm none are auto-revoked. If you tell us your plan tier, the audit-log guidance above can be narrowed to what your organization actually records.