What you can scope#
Team. A token can be limited to one team's resources rather than everything your account can reach. This is the meaningful control, and you should use it.
Expiry. Tokens can be given a lifetime. Genuinely valuable: it is the one hard limit on the blast radius of a leak you never notice.
What you cannot scope#
Capability. There is no "read-only" token. No "deployments but not environment variables". No "status but not delete".
A token scoped to a team can do essentially anything a member can do in that team, which includes reading environment variable values and deleting deployments — full list here.
This is coarser than AWS IAM, GitHub fine-grained PATs, or Stripe restricted keys, all of which let you express "read this, not that".
What that means in practice#
Since you cannot limit what a token does, limit where it reaches and how long it lives.
1. One token per app. The single most useful habit. Name it after the app. Revoking it then breaks exactly one thing, and you know which.
2. Scope to the narrowest team. If a third-party app only needs to see your side projects, do not hand it a token that reaches client work.
3. Set an expiry. Yes, you will have to re-issue it. That is the feature.
4. Consider a dedicated team. For anything genuinely sensitive, a separate Vercel team creates a real boundary — the only hard one available.
5. Keep an inventory. Tokens outlive the apps they were made for. If you granted one to Vercelios, which is now delisted, that token is still live and still valid.
Netlify, briefly#
Netlify's personal access tokens are similarly coarse and account-scoped. Netlify does offer a secrets controller for build-time secret scanning, which is a different problem — it stops secrets leaking into your build output rather than limiting what a token can reach.
The uncomfortable conclusion#
Every third-party Vercel app, including MONII, holds more capability than it needs, because the platform does not offer a way to grant less.
The realistic mitigations are the ones above — dedicated tokens, tight team scope, expiry, and knowing where the revoke button is. Nobody can engineer around a permission model that does not express the permission you want.
Questions people actually ask
Can I create a read-only Vercel token?
No. Vercel scopes tokens by team and expiry, not by capability. A token that can read your projects can generally also act on them.
Should I set an expiry on Vercel tokens?
Yes. An expiry is the one hard limit available. Set the shortest one you can live with — it means a leaked token has a deadline even if you never notice.
One token, one app
Whatever you use MONII for, issue it a dedicated token you can revoke without breaking anything else.
Get MONII for iOS ›