Overview

Aperium decides what someone can do from three inputs: the roles granted to them, the permission groups they belong to, and the policies attached to those groups. Roles set the broad shape of what a user can reach; permission-group policies attach fine-grained access to individual MCP servers and data scopes on top. Access control lives in the Settings console under Workspace › Access, a tabbed hub. Members and their role grants are managed next door under Workspace › Members.

​

Roles

Aperium has three system roles, defined in code. Tenant-custom roles are deferred, so this set does not change per tenant.

​

Roles are additive grants, not a single value

A user does not have one role — they hold a list of role assignments. Each grant is scoped to a specific tenant, or is platform-wide, and carries who granted it, when, an optional reason, and an optional expiry. A user can hold several grants at once. You manage them per member on the Member detail page: a Role assignments list where you Grant and Revoke individual grants, each tagged with its tenant or “platform.” See Members.

​

The Access hub

Workspace › Access is a set of tabs, each gated by its own capability, so an administrator only sees the tabs their role reaches.

​

Two kinds of “group”

The word “group” refers to two distinct things in Aperium. They are never merged.

• Permission groups are native Aperium groups that carry MCP policies. Membership is native and manually granted — an administrator adds or removes a member from a group. See Permission groups.
• IdP groups are a read-only snapshot of the groups your identity provider reported on a user’s sign-in token. They are shown separately on the member’s detail page, with a “last reported” time, and are never editable in Aperium.

IdP groups do not add a user to permission groups. Instead, an IdP group can grant a role through Group mappings: when a user signs in, any mapped IdP group they carry grants them the mapped role for that tenant. This is how you manage role assignment through Okta, Microsoft Entra, or Google Workspace without touching each user by hand.

​

Policies

A policy is the set of rules on a permission group deciding what its members can do on each MCP server. Each policy controls two things per server:

• Access level. None, Read, or Read + write. Write implies read.
• Scope rules. For connectors that expose multiple distinct units (BigQuery datasets, Postgres schemas, GCS buckets), allowlist exactly which units the group may query.

Edit policies from the Permission groups tab. See Permission groups.

​

How effective access is calculated

When a user makes a request, Aperium combines every signal that applies:

1. The upstream system’s own permissions come first. Every tool call runs against the connected system using credentials with their own access controls. Aperium can only narrow that, never widen it.
2. Admins bypass group policy. A tenant_admin or super_admin is not bounded by permission-group policy inside Aperium (they are still bounded by the upstream credentials).
3. For everyone else, Aperium gathers the policies of every permission group the user belongs to.
4. Across those groups it takes the most permissive access level — if any group grants Read + write on Salesforce, the user gets Read + write on Salesforce.
5. Scope rules merge the same way: every unit allowlisted by any group becomes accessible.
6. Operational gates still apply. A disabled server, or one requiring personal credentials the user hasn’t linked, still fails regardless of policy.

There is no deny semantic — policies only union toward more access. To restrict, remove the user from the group that grants it, or change that group’s policy.

​

Where to go next