Skip to main content
MoleSignal authorizes actions with permission keys, not by comparing role names. A user can belong to several organizations and hold different permissions in each one. Open Identity & Access in the sidebar to manage the access of the current workspace.

​
How authorization works

For an authenticated request, MoleSignal resolves:
  1. the subject: a user, a service account, or an API token;
  2. the active organization, or the protected platform scope;
  3. the role assignments and the access grants of the subject;
  4. the resource relationships and the accepted cross-organization grants;
  5. the permission that the route and the target resource require.
The permission catalog, the built-in roles, and the permission bundles are stored in PostgreSQL. GET /api/v1/iam/capabilities returns the effective permissions that the web application uses to build its navigation.
A visible page or a role label is not authorization. The server checks the exact permission and the ownership of the resource for every protected operation.

​
Permission scopes

Organization permissions cover one workspace. Examples:
  • org.settings.read and org.settings.manage;
  • org.members.read and org.members.manage;
  • iam.roles.read, iam.roles.manage, iam.policies.read, and iam.policies.manage;
  • the permissions of streams, dashboards, alerts, schedules, saved views, pipelines, functions, reports, audit, log inspections, and Mole Agent.
Platform permissions begin with sys. and apply only in the _sys organization. They control the organizations of the instance, system telemetry, trace debugging, platform administrators, and platform settings.

​
Built-in roles

The permission reference lists every permission with the built-in roles that hold it. Built-in roles cannot be edited. A permission that an upgrade adds reaches the Owner role at startup, so an Owner of an enabled organization can enter _sys and use the platform pages. On an instance with several organizations, every Owner has platform access: assign the role accordingly. API tokens cannot enter _sys, and a custom role never receives platform permissions this way. Create a custom role for a narrower responsibility.

​
Cross-workspace access

An access grant can relate a subject in one organization to a resource in another. The server checks that relationship and the resource permission together, and a grant never makes the other organization the active workspace of the subject. See Share resources across organizations. Dashboards and reports also have resource sharing. A public share receives a restricted share session, not a membership.

​
Platform administration

The _sys organization is separated from organization IAM. A tenant session and an ms_* token cannot list system telemetry or platform administrators. Use a session in _sys with the required sys.* permission. See Administration overview.

Members

List users, change roles, approve sign-ups, and record invitations.

Single sign-on

Connect OIDC, SAML, or LDAP, and limit the email domains that may join.
Last modified on October 26, 2026