When an M2M application calls IntelliAuth's management surface, it can do exactly what you have checked in the capability picker — and nothing else. Capabilities are how you say "this integration can read users but not delete them," without exposing the underlying protocol details.
What you see in the picker
Section titled “What you see in the picker”/screenshots/admin.applications.capabilities/picker.png The picker has three zones.
Left rail — resource categories. Each row is a resource type: Users, Applications, Tokens, Sessions, Audit, and so on. A small badge next to each category shows how many capabilities you have already selected inside it. Click a category to load its actions in the right pane.
Right pane — actions. Each action appears as a labelled checkbox with a one-line description of exactly what it permits. "Read" lets the integration list and fetch records. "Create" lets it register new ones. "Delete" lets it remove them. The descriptions are written for the person configuring the integration, not for a protocol implementer.
Selection summary — chips at the top. Every capability you have checked appears as a chip in the format Resource · Action — for example, "Users · Read" or "Applications · Delete". Click any chip to remove that capability immediately. The summary is how you audit the full picture at a glance without scrolling through every category.
The mental model
Section titled “The mental model”A capability is a (resource, action) pair. "Users · Read" means this integration can list users and fetch individual user records. "Applications · Create" means it can register new applications on behalf of your organisation. The picker takes care of the protocol encoding — the wire format that carries these permissions is managed for you, and nothing in this interface exposes it.
Think of the picker as a permission checklist, not a configuration form. Every box you check is a door you are deliberately opening. Every unchecked box is a door that stays closed, regardless of what the integration requests.
Least-privilege discipline
Section titled “Least-privilege discipline”Start with the minimum your integration actually needs today. You can always return to this picker and add more later. Here is a pattern that works well for most integrations at Cymmetri:
- A user-provisioning integration only needs Users · Read and Users · Create.
- An audit-export integration only needs Audit · Read.
- An application registration tool only needs Applications · Create.
Removing a capability takes effect on the integration's next token request. Tokens already issued to the application carry their original capabilities until they expire. If you need an immediate effect, rotate the application's client secret from Credentials → Client secret → Rotate — that invalidates existing tokens.
Every capability grant and every capability revocation is recorded in the tenant audit log: who changed it, when, and what changed.
Existing tokens remain valid until their expiry time. If you need to close access immediately, rotate the client secret after removing the capability.
What capabilities are not
Section titled “What capabilities are not”They are not user roles. Users have their own role model — Owner, Admin, Viewer — managed in a separate part of the console. Capabilities only apply to M2M applications calling the management surface.
They are not MFA or login policies. Those live on the Access tab and on the tenant-wide Flow settings. Capabilities say nothing about how a human authenticates.
They are not data-access controls inside your own application. Capabilities only gate calls to IntelliAuth's own management surface. Your application's internal data — the data it owns and serves to your end-users — is your responsibility to protect. IntelliAuth does not mediate that.
Where the picker appears
Section titled “Where the picker appears”The capability picker shows up in two places.
When you create a new M2M application, step 2 of the registration flow opens the picker. It pre-selects Users · Read as a sensible starting point. You can add, remove, or clear everything before you save.
When you open an existing M2M application's Access tab, the same picker is there to revise. Your current selection is already reflected — change it, save, and the new set takes effect on the next token request.
SPA, Native, and Server-side applications use their own allowed-scopes list in Settings → Scopes, not this picker. Capabilities in the Resource · Action format are specific to M2M applications that call the management surface directly.