Permissions & approvals
EnClaw's governance model has two halves. Permissions decide what an agent (or user) may do at all — allow it, block it, or require sign-off. Approvals are the human-in-the-loop workflow that fires when sign-off is required. Permissions live at /permissions, approval workflows and pending requests at /approvals.
The 8 RBAC roles
Roles gate access to EnClaw's own surfaces — who can administer, review, approve and use. (The invite-time view of these lives in Inviting your team & assigning roles; this is the governance view.)
| Role | What it's for |
|---|---|
super_admin | Platform-operator top role (EnClaw support, or your in-house platform team on self-hosted). Everything, cross-tenant. Not for everyday customer use. |
org_admin | Tenant-wide administration — users, teams, integrations, SSO, permission rules, approval workflows. |
security_admin | Security posture — secrets vault, egress policies, sensitive-data policies, security audit logs. |
compliance_officer | Read-oriented compliance role — retention policies, compliance reports, certifications, audit review. |
team_admin | Manage one team: its members and its agents. No tenant-wide reach. |
agent_admin | Manage agents and templates across the tenant, without user management. |
skills_curator | Review and approve skills submitted to the catalogue (see Custom skills). |
agent_user | The default. Use agents, chat, file space. No admin surface. |
Most organisations only ever hand out org_admin, team_admin and agent_user, adding skills_curator and compliance_officer once skill submissions and compliance reporting become real workflows.
Permission rules
A permission rule targets a resource type and sets an action:
Resource types: skills · tools · data · config · agents
| Action | Effect |
|---|---|
auto_allow | Executes immediately, no human involved. |
require_approval | Execution pauses; an approval request is raised and the action runs only if approved. |
deny | Blocked entirely. The agent is told the action isn't permitted. |
Rules can also carry conditions (match a specific tool name, a data classification, a configuration key), so "allow JIRA reads, require approval for JIRA writes" is one pair of rules, not a per-tool spreadsheet.
7-layer permission resolution
The same tool can be governed at several levels at once — the org sets a default, a team tightens it, a user gets an exception. EnClaw resolves conflicts with a fixed priority order. The highest-priority layer that has a matching rule wins; layers with no matching rule are simply skipped.
| Priority | Layer | Typical use |
|---|---|---|
| 1 (highest) | Sandbox | Hard isolation limits on sandboxed executions — non-negotiable by anything below. |
| 2 | Session | Restrictions applied to one running session (e.g. a locked-down shared demo session). |
| 3 | Channel | Rules for a specific channel — e.g. no outbound email from the public support channel. |
| 4 | User | Per-user overrides and exceptions. |
| 5 | Agent | What this specific agent may do, regardless of who's asking. |
| 6 | Team | Team policy for all the team's agents and members. |
| 7 (lowest) | Org | Tenant-wide defaults — the baseline everything else refines. |
A useful mental model: org sets the default, everything above it is an increasingly specific exception, and the sandbox/session layers exist so that runtime safety restrictions can never be argued away by a generous org default.
Worked example 1 — user override beats team deny
- Org:
jira_create_issue→require_approval - Team (Delivery):
jira_create_issue→deny - User (Priya, delivery lead):
jira_create_issue→auto_allow
Priya asks her agent to create a JIRA issue. Resolution walks the layers top-down: no sandbox, session or channel rule matches; the user layer (priority 4) has a match — auto_allow — so the issue is created immediately. The team's deny (priority 6) and the org's require_approval (priority 7) are never reached.
Anyone else on the Delivery team hits the team deny first, so they're blocked. Someone outside that team with no user rule falls through to the org default and gets the approval prompt. Three different outcomes from three rules — which is exactly the point: the deny protects the team broadly, while the named lead keeps working.
Worked example 2 — agent rule vs org default
- Org:
outlook_send_email→require_approval - Agent ("Weekly Digest"):
outlook_send_email→auto_allow
The Weekly Digest agent sends its Friday summary without an approval prompt — the agent layer (priority 5) matches before the org layer (priority 7). Every other agent in the tenant still triggers an approval on outbound email. This is the standard pattern for automating a trusted, narrow workflow without loosening the tenant-wide default.
Worked example 3 — sandbox always wins
- User (an org admin, no less):
run_shell→auto_allow - Sandbox policy for high-risk skills: network egress →
deny
A high-risk custom skill runs in an isolated sandbox with networking disabled. Mid-run it tries to call an external API. The sandbox layer (priority 1) denies it — the admin's personal auto_allow at the user layer never gets a look-in. Runtime isolation rules are deliberately un-overridable; if the skill genuinely needs egress, the fix is to adjust its sandbox/risk classification and egress policy, not to grant a user permission.
Approval workflows
When resolution lands on require_approval, an approval request is raised and the action pauses until someone decides. Workflows are configured at /approvals.
What triggers an approval
Seven trigger types cover the common governance moments: tool type (e.g. any write-class tool), command patterns (specific commands in code-execution tools), data sensitivity (touching classified data), spend thresholds (actions above a cost line), blast radius (bulk operations affecting many records), time of day (out-of-hours actions), and first use (the first time an agent uses a given tool). Skill submissions to the catalogue also route through approval — see Custom skills.
Flow types
| Flow | How it decides |
|---|---|
| Simple | One approver (or any member of an approver group) decides. |
| Sequential | Approvers decide in order — the request only reaches step 2 after step 1 approves. |
| Parallel | All named approvers are asked at once; all must approve. |
| Quorum | A configurable number of a group must approve (e.g. any 2 of 5 team leads). |
Custom flows are available for cases the four standard shapes don't cover — talk to your operator.
Delivery, timeouts and audit
- Multi-channel delivery — approvers are notified where they actually are: Slack, push notification, the web UI, or email. A decision made in any channel resolves the request everywhere.
- Timeout auto-deny — every request carries a configurable expiry. If nobody decides in time, the request is denied, not silently allowed. The agent is told the action was declined and can proceed accordingly.
- Audit trail — every request records who was asked, who decided, what they decided, when, and any comment. Decision history is browsable at /approvals and flows into the audit log.
Next
- Security & compliance — secrets, egress, retention and PII controls that sit alongside permissions.
- Managing agents — per-agent skill toggles, the other half of capability control.