Skip to main content

Access Control

The Access Control group manages who can sign in, what they can do, and which actions need a human in the loop. Every item requires org_admin or above; for lower roles the entire group vanishes from the sidebar.

Users​

/users lists every user in the workspace in a table: name, email, role, source (SSO provider or local), status, last login and created date.

  • Add User creates a local account with email, name, password and role.
  • Edit User changes name, role and active status, and sets per-user token quotas (daily and monthly limits) with current usage shown alongside.
  • The role dropdown is driven by the API's assignable-roles rules, so you only ever see roles you are allowed to grant — tenant-tier roles (from Agent User up to Org Admin) for tenant admins, with platform-tier roles reserved for operators.
  • Reset password issues a temporary password and displays it once, with a copy button.
  • For SSO-managed users, a break-glass dialog can grant or revoke a password-login exception, with a required reason that is audited.
  • Delete User is a confirmed, destructive action.

Roles and their meanings are covered in Teams and roles.

Teams​

/teams groups users for scoping agents, secrets, MCP servers and permission rules.

  • Create Team takes a name and a lowercase slug.
  • The table lists name, slug and created date; expanding a row manages that team's membership, and teams can be deleted from the row actions.

Permissions​

/permissions ("Permission Rules") is the layered policy engine that decides whether an operation is auto-allowed, requires approval, or is denied.

  • Add Rule composes: a layer (org, team, agent, user, channel, session, sandbox), a scope ID, a resource type (skill/tool, LLM provider, connector/channel, agent, secret, config, gateway), a resource ID (or *), an operation (install, execute, read, write, admin, submit, curate, revoke), an action (auto_allow, require_approval, deny) and a priority.
  • Rules can be filtered by layer, edited, toggled and deleted.
  • A built-in resolution tester lets you pick a user, agent, resource and operation and see exactly which rule wins and what the effective action is — use it before rolling out a new deny rule.

SSO Providers​

/sso-providers configures enterprise sign-in.

  • Supported providers: Azure AD (Microsoft Entra ID), Okta, Google Workspace and Ping Identity, over OIDC (with SAML fields present for providers that need them).
  • Each config carries client ID/secret, issuer and endpoint URLs (auto-derived for Azure AD and Google), scopes, callback URL, a default role and an auto-provision toggle.
  • Group sync maps external directory groups to EnClaw roles (Agent User, Agent Admin, Org Admin) and optionally to teams, on a configurable interval with nested-group support; Sync now and sync status are available per provider.
  • Providers can be SSO-only (blocking password login for linked users) and can strip passwords when an account is linked.

Full provider-by-provider setup lives in SSO.

Approvals​

/approvals ("Approval Workflows") is both the live approval queue and the rule set behind it, split into Queue and Rules tabs, with metric cards for pending, approved, denied and expired requests.

  • The Queue tab lists approval requests filtered by status. Each card shows the request type, delivery channel badge, multi-step progress (e.g. step 1/2), the request details as JSON, and — once resolved — the recorded reason. Pending requests are actioned inline.
  • A collapsible Test Trigger panel evaluates a hypothetical event (trigger types: tool type, command, data sensitivity, spend threshold, blast radius, time of day, first use) and reports whether approval would be required and which rule matched.
  • The Rules tab manages the approval rules themselves — what triggers an approval and which flow it follows.

How approvals interact with permission rules is described in Permissions and approvals.