Scopes
A scope is a unit of disclosure. A client may request only what it is allowed, and the user sees what is being asked for.
Where to find it
Architect Panel → Integration & Connections:
- OpenID Connect Provider — the console — clients, scopes, keys and the log
Architect Panel → Integration & Connections:
- AI Tool Access (MCP) — what the mcp scopes reach
- Agent Access (A2A) — what the a2a scopes reach
The identity scopes
- openid — sign the person in. Required for any sign-in.
- profile — their basic profile.
- email — their e-mail address.
- phone — their phone number.
- groups — their security groups.
- offline_access — stay signed in, by issuing a refresh token.
Groups discloses more than it looks
It tells the application which security groups somebody belongs to — which is your internal structure, and sometimes sensitive in itself. Group names such as "Safeguarding Team" or "Redundancy Consultation" reveal something about the person.
Grant it when an application genuinely needs to make decisions from group membership, not as a matter of routine.
offline_access is a duration decision
It is what lets an application keep somebody signed in for weeks without asking again. Convenient, and it means access persists well beyond the last time they proved who they were. Consider whether that suits the application before enabling it.
The AI scopes are different
Six more exist, and they are not identity at all — they let a connected AI assistant or agent act:
- mcp:read — an AI assistant may read data through the platform's tools.
- mcp:write — adds creating and changing records.
- mcp:admin — reserved for administrative tools.
- a2a:read — another agent may ask this system to carry out read tasks.
- a2a:write — lets another agent delegate work that creates or changes things.
- a2a:admin — reserved.
Scrutinise those much harder
The identity scopes disclose facts about a person. These grant the ability to do things in your system on their behalf, at their permission level.
Read and write are a meaningful step apart, and the admin ones are reserved — nothing today requires them, so there is no reason to grant one now.
Allowed and default
A client's allowed scopes are the most it may ever ask for; its defaults are what it gets without asking. Keep defaults minimal — usually just enough to sign in — and let the client request more when it has a reason the user can see.
Grant the least that works
Start a new client with openid and whatever single scope its purpose requires, and add on evidence. It is far easier to add a scope than to explain why one was granted, and every scope appears on a consent screen your users read.
Review them
Scopes get added during commissioning to make something work and are never taken away. A periodic look at what each client may request — against what it actually does — usually finds one that has more than it needs.
Worked example
An events site is allowed openid, profile and email, with openid and profile as defaults. It requests email at sign-in, which the consent screen shows. It is not allowed groups, because it has no need to know, and none of the AI scopes.
Recommendations
- Minimal defaults — usually just sign-in.
- Treat groups as disclosure of your internal structure.
- Hold the AI scopes to a much higher bar — they grant action, not information.
- Review allowed scopes against what clients actually use.