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 the permissions it is asking for — up to six — each with a checkbox, 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

Open Dashboard → Account → Connected apps. Every app you have approved is listed there, with the address it sends you back to, when you connected it and when it last made a request. Two buttons matter:

Disconnect revokes the app's access token and refresh token on X02's side, at once, whatever the client does. It does not depend on the app being well-behaved. The app has to ask again, and you have to approve again, before it can touch your account.

Edit permissions lets you take individual scopes away from an app that stays connected. The change bites on the app's next request — X02 clips the tokens it has already issued rather than waiting for them to expire. It only removes: to give an app more than it holds, reconnect it and approve the larger set on the consent screen, so you always see the request being made.

You can also remove the connector in the app itself. What happens next depends on the client: ones that call X02's revocation endpoint on disconnect kill the token there and then, while ones that simply forget the credential leave the access token valid until it expires — at most an hour. There is no way for us to tell from the outside which kind you have, which is why the Connected apps page is the reliable route.

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.

For assistants X02 knows — starting with Claude — the screen goes one step further. When the address is that app's own callback, it says Recognised app, and the name in the heading comes from X02 rather than from the app. For anything else, including an app that merely calls itself Claude, you get the warning that X02 has not vetted it, with its real address beside it. Recognition is by address, not name, so a convincing name earns nothing.

It is also a narrower statement than it sounds. It says where the result will be sent, not who started the request. If you did not just start this connection from that app, deny it.

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.

You do not need the client's cooperation to get the narrower connection. Whatever an app asks for, X02's consent screen puts a checkbox beside each permission: untick the ones you would rather withhold and the button reads, for example, Allow 4 of 6. The app is then told exactly which permissions it received, and anything outside them is refused on every call. You can trim further later under Connected apps, but not widen — an app that wants more has to ask again.

Next Steps & Related Tutorials

Read this article on X02