PreviewDrafts Perspective Token Boundary

Sanity Studio offers a `perspective=previewDrafts` configuration that renders draft content inside the editor for authorized reviewers, while the public API and CDN exclusively serve published documents. This setup enables internal draft preview without exposing content to unauthenticated API consumers. The choice of how to authorize these preview requests remains a design consideration for projects handling sensitive or unreleased content.

Two primary mechanisms exist for editor draft access: embedding a viewer token with `perspective: 'previewDrafts'` in the `@sanity/client` configuration, or leveraging Sanity's Presentation tool with authenticated preview URLs. The token-handling boundary and permission scope differ between these approaches, influencing how draft visibility is enforced across client and server environments. CORS configuration further complicates browser‑based preview flows, as mis‑origin rejections do not substitute for token‑based authorization.

Given these distinctions, which approach correctly limits draft access to intended editor sessions without risking accidental public exposure? How should token scope be defined for `previewDrafts` perspective in multi‑dataset projects, and what are the implications of switching between the Studio preview and Presentation tool workflows?