DocsDevelop

Access control

Discover permissions, create organization roles, and assign them to principals.

The access-control API manages the organization's permissions, roles, principals, and role assignments.

Discover permissions

Read the live permission catalog instead of copying a static list:

GET /v1/permissions

The response includes each permission's description, risk, category, assignability, and compatible principal kinds.

Resource access starts with mobius.resource.view. mobius.resource.use covers working with reachable resources, while mobius.resource.build covers creating and changing configuration under eligible personal custody. Use and build are independent; each implies view. mobius.org.admin implies all three and adds organization administration and team resource posture.

Billing, machine-job execution, and action execution have separate permissions. An action permission can allow every action, one provider family, or one exact action name without granting broader organization administration.

Manage roles

GET /v1/roles
POST /v1/roles
GET /v1/roles/{role_id}
PATCH /v1/roles/{role_id}
DELETE /v1/roles/{role_id}

Create a custom role with a small, explicit permission set:

{
  "name": "slack-poster",
  "description": "Works with reachable resources and can request one Slack posting action.",
  "permissions": [
    "mobius.resource.use",
    "actions.execute.slack.message.post"
  ]
}

This role makes one action executable; it does not grant a Slack connection. When an assistant calls that action as a tool, Mobius still checks the selected connection and its grant before dispatch. The platform does not add a human confirmation. A direct API invocation follows the Actions API authorization path.

System roles are assignable but immutable. Create a custom role only when no system role matches the workload.

Assign roles

GET /v1/role-assignments
POST /v1/role-assignments
DELETE /v1/role-assignments/{assignment_id}
{
  "principal_id": "<principal-id>",
  "role_id": "<role-id>"
}

A principal may represent a person, API client, worker, or agent. Credentials authenticate as the principal; role assignments decide what it can do.

A role is only one side of authorization. It does not make a private resource visible or let an assistant use an arbitrary connected account. Resource ownership, audience, and connection grants are checked separately for the specific operation.

Next