OAuth ScopeCopy link to this section

A scope is a named permission carried by an authorization. When a person connects an application to a service, the scopes are what the consent screen is asking about: not "may this app act as you", but "may it do these specific things as you".

Scopes bound the authorization, not the person. A user with full administrative rights can grant a read-only connection, and that connection stays read-only — which is what makes scoping useful rather than decorative.

What a good scope looks likeCopy link to this section

It is named after something the user recognizes. A scope called view_conversations on a consent screen means something to somebody who has seen "Conversations" in the product's navigation. A scope called sc:rw:2 means nothing to anybody, and a consent screen nobody can read is not consent.

It maps to a real boundary. A scope that grants "everything" is a scope that will be requested by everything.

It is capped by the granting user's own permissions. This is the rule that gets skipped most often. If a scope can be granted by somebody who does not themselves hold the underlying permission, the scope system is a privilege escalation path.

It is enforced where the work happens. Filtering a tool list by scope is useful for the interface — it stops an assistant trying things it cannot do — but it is not a security boundary. A caller that names a hidden tool directly must still be refused.

Scope driftCopy link to this section

The failure mode to watch for is scopes and permissions drifting apart. An application asks for the scopes it needed when it was written; the product's permission model changes underneath. Now a scope grants slightly more or slightly less than its name suggests, and nobody notices because nothing errors.

The defense is to derive scopes from the permission model rather than maintaining a parallel list, and to re-check the user's current role at request time rather than trusting what was true at consent time.

At FloeCopy link to this section

Floe's MCP scopes are spelled exactly like the dashboard permissions they mirror — view_sites, update_sites, view_content, manage_content, view_plans, manage_plans, view_conversations — so a scope on the consent screen is recognizable from the members page.

The set a person can grant is derived from their role at approval time and re-derived server-side, so the list a tool asks for can only narrow what is granted, never widen it. Every request re-reads the member's current role, so a demotion takes effect on their existing connections rather than at token expiry.