Skip to main content
Permission groups are how you attach fine-grained access to individual MCP servers in Aperium. Every group carries a policy that decides which servers its members can read or write, and which data scopes within those servers they may query. This page covers the day-to-day tasks: creating a group, editing its policy, and resolving Needs review items. Find them under Settings › Workspace › Access › Permission groups.
Group policies can only restrict access, never grant it. Aperium always honors the underlying system’s permissions first. Setting a group to Read + write on Salesforce doesn’t grant Salesforce access; it only authorizes Aperium to use whatever access the user (or the configured tenant credentials) already has there. To remove an upstream permission, change it in the source system.

​
How membership works

Permission-group membership is native and manually granted. An administrator adds or removes a member from a group on the Member detail page — there is no automatic enrollment from an identity-provider claim.
Do not assume a matching IdP group name enrolls users automatically. IdP groups are a read-only snapshot and never join a user to a permission group. An IdP group can grant a role through Group mappings, but permission-group membership is always native. See Access control overview.

​
The Permission groups tab

You’ll see every permission group in your tenant. From here you can create a group, rename it, edit its policy, or delete it (members lose any access that came only from that group; their other groups and role grants are unaffected).

​
Editing a group’s policy

Open a group’s Policy to reach the editor.

​
Per-server access

For each MCP server the group has a rule for, choose one access level: A group doesn’t need a rule for every server. With no rule for, say, NetSuite, members simply don’t see NetSuite tools. To grant access, add a rule; to revoke it, set the level to None or remove the row.

​
Scope rules

Some connectors expose multiple distinct units of data — BigQuery datasets, Postgres schemas, GCS buckets. For these the editor shows a scope rules section where you allowlist exactly which units the group may query.
  • Add a unit and members can query it; remove it and the group loses access even at Read + write.
  • Units not in the allowlist are invisible to the group.
  • Scope rules merge across groups: every unit allowlisted by any of a user’s groups becomes accessible. There’s no deny at this level, so to keep a unit private to one group, only allowlist it there.
Admin roles bypass scope rules. Because tenant_admin and super_admin bypass group policy, scope rules do not apply to a group whose members are admins — they always reach every scope.

​
Needs review

The policy editor flags a Needs review state on servers whose configured policy doesn’t match runtime reality — for example a server that requires personal credentials but is configured here for shared credentials, or a server that has been removed from the tenant while its policy row remains. These don’t crash agents at runtime, but they lead to confusing access decisions, so reconcile them promptly.
Verify before relying: the exact “Needs review” triggers and remediation wording render from the live policy panel. Confirm the current copy in the product before quoting it to users.

​
Designing groups

  • Start coarse, then split. Begin with a few broad groups (engineering, finance, ops) and carve out narrower ones when a specific access pattern emerges.
  • Use Policy audit to validate changes. After a big policy edit, check Policy audit to confirm the change landed as intended.
  • Resolve Needs review items quickly. They are the most common source of “I can’t see the tool I’m supposed to” tickets.