X02 MCP Permissions: What You Are Actually Approving

A close read of the consent screen. Which scope governs which tool, how enforcement works on every call, how long tokens live, what revocation really does, and which permissions to withhold.

By X02 Team · 2026-09-22 · MCP, Security, OAuth, AI, Developer Tools

When you connect an AI assistant to X02, a consent screen lists six permissions and asks you to approve. Most people skim it. This page is the long version — what each scope governs, where it is enforced, and what is left standing if a token leaks.

[!TIP] Quick Navigation:

• The six scopes
• Which scope governs which tool
• Where scopes are enforced
• How long a connection lasts
• What a stolen token can and cannot do
• Revoking access
• What to withhold
• Next Steps & Related Tutorials

The six scopes

That is the entire vocabulary. Anything an app asks for outside this list is rejected before you ever see a consent screen.

You can check what any connected app actually holds without leaving the chat. Ask it:

"What X02 permissions do you have?"

get_account returns the granted scope list alongside your plan and usage, so the answer comes from the token itself rather than from the app's memory of what it asked for.

Which scope governs which tool

The mapping is one-to-one and fixed. No tool consults more than one scope, and none is ungoverned.

Three of these pairings surprise people.

Receiving a file needs files:write. request_file_from_user and check_file_handoff are how an attachment reaches X02 — the assistant asks, you drop the file, it collects the result. That is an upload, so it sits under the same scope as one.

Deleting a folder is folders:write, not files:delete. Creating, deleting and sharing folders are a single permission. An app you deliberately denied files:delete can still delete a folder if it holds folders:write. Nothing inside is destroyed — the files return to your root library — but the folder and its share link are gone.

Sharing a folder is also folders:write. share_folder publishes an album at a public link that anyone holding it can open. If you would rather an assistant never be able to publish anything, that is the scope to withhold.

Where scopes are enforced

Not at sign-in. On every call.

The bearer check that guards the /mcp endpoint can only see that a token is valid — it cannot know which tool a JSON-RPC body is about to invoke. So each tool asserts its own scope before it does anything, and refuses with a message naming the missing permission:

This app was not granted the "files:delete" permission.
Reconnect it and approve that scope to continue.

This matters because of what sits behind the server. X02's MCP server talks to the same REST API your API key does, and an API key has no concept of scopes — it can do everything. The per-call assertion is the only thing standing between a narrowly-scoped token and full account access. It is the first thing that runs in every tool, before any request leaves the server.

How long a connection lasts

The refresh token rotates: each use issues a new one and retires the old. If a retired refresh token is ever presented again, X02 treats it as a sign the token was copied and revokes the entire grant — that app is disconnected outright and has to be re-approved. It is a blunt response, deliberately, because the alternative is quietly letting two parties share one connection.

Scope cannot grow on refresh either. An app that was granted files:read cannot ask for files:delete at renewal time; the request is refused rather than silently downgraded. Widening permissions always means a new consent screen with your name on it.

What a stolen token can and cannot do

Worth being concrete, because "OAuth is safer than an API key" is easy to assert and harder to justify.

Your API key never reaches the app. The server resolves your account from the app's token internally, server-side. There is no call an app can make that returns your key, and a leaked token cannot be exchanged for one.

Tokens are bound to one resource. They are minted for https://up.x02.me/mcp specifically. Present one anywhere else and it is refused — a token lifted from one service cannot be replayed against another.

Tokens are bound to one app. Approving Claude does not produce a credential Cursor can use. Each connection is its own grant with its own scopes.

The blast radius is the scopes you approved, for at most an hour. Compare that to an API key: full account access, no expiry, and revoking it means rotating the key and breaking every other integration you own.

What it can do, within its scopes, is everything you can. A token with files:delete deletes files for real; X02 has no trash can. Scopes limit reach, not judgement.

Revoking access

Remove the connector in the client. What happens next depends on the client.

Clients that call X02's revocation endpoint on disconnect kill the token there and then. Clients that simply forget the credential leave the access token valid until it expires — at most an hour — with the refresh token unused and expiring on its own schedule. There is no way for us to tell from the outside which kind you have.

[!NOTE] X02 does not yet have a page listing your connected apps, so revocation is currently driven by the client rather than by you. If you need a connection dead immediately, email [email protected] or ask in our Discord and we will revoke the grant server-side. A connected-apps screen is on the roadmap.

What is guaranteed either way: revoking one app touches nothing else. Your API key, your folder keys and every other connected assistant carry on unaffected. That is the property an API key cannot give you, and it is the real argument for MCP.

Reading the consent screen

Two things on that page are worth a second of attention.

The app's name is self-declared. Any developer can register a client and call it whatever they like, "X02 Official" included. Registration is open by design — it is what lets a client connect with nothing but a URL — so the name proves nothing.

The redirect host is not. The consent screen shows the host you will be sent back to after approving. That one is checked. If it is not the app you just clicked in, deny it and find out why.

What to withhold

A rough guide, from least to most trusting:

Most people want the middle row. It covers every ordinary request — upload this, find that, make a folder, move these into it, share the album — and the only thing it cannot do is destroy a file.

Whether you can pick and choose depends on the client: some let you deselect individual permissions on the consent screen, others request the full set and leave you with approve-or-deny. If yours is the second kind and you want a narrower connection, that is a reasonable thing to ask its developers for.

Next Steps & Related Tutorials

Read this article on X02