---

name: clickup-enterprise-rbac description: >- Assess and change ClickUp roles, custom roles, groups, object ACLs, and audit access with plan-aware approvals. Use when governing enterprise ClickUp authorization. Trigger with "ClickUp RBAC", "ClickUp custom roles", or "ClickUp ACL audit". argument-hint: "[workspace-id] [assess|plan|apply]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.8.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags:

• saas
• clickup
• access-control model: inherit effort: high compatibility: Designed for Claude Code; enterprise endpoints require the relevant plan, owner authority, and approved identities

---

ClickUp Enterprise Access Governance

Overview

Use API role and ACL evidence as inputs to authorization decisions without assuming a numeric role alone proves effective access.

Prerequisites

• An Enterprise-plan and owner/admin capability check for the intended endpoint
• An authorized Workspace inventory of users, guests, groups, custom roles, and protected objects
• A ticketed desired-state change with separation of duties and rollback

Tool Discipline

Use Read, Glob, and Grep to inspect the repository, adapters, configuration names, tests, and evidence. Use WebFetch only for current official ClickUp documentation. Use Write or Edit after confirming the target file, Workspace boundary, and requested mode.

Current Contract

• The v2 member role field uses 1 owner, 2 admin, 3 member, and 4 guest; custom roles require their own endpoint.
• Groups are user groups, while v2 team_id means Workspace.
• User/guest management is Enterprise-only; v3 audit-log queries are Enterprise-only and owner-only.
• v3 ACL changes can alter privacy and sharing and may incur charges; effective access can inherit from hierarchy.

Authentication

Use a personal token only for accountable individual/testing work or OAuth Authorization Code for a user-facing integration. Inject the token server-side through a governed secret reference, send it in Authorization, verify authorized Workspace IDs, and never print the token, OAuth client secret, or webhook secret.

Instructions

1. Identify the Workspace, plan, caller role, endpoint version, and approved authorization objective.
2. Inventory direct and inherited access, groups, custom roles, guests, and application tokens.
3. Compare effective access to policy; do not collapse custom roles into the four base role codes.
4. Build a least-privilege plan with additions, removals, charge impact, and rollback.
5. Require a second reviewer for owner/admin, guest, group, or ACL changes; apply bounded changes.
6. Re-read effective access and, where authorized, query audit evidence for the change.

Approval Boundaries

Never self-approve privilege elevation, owner/admin changes, broad sharing, guest expansion, paid ACL effects, or user removal.

Output

Return plan/endpoint eligibility, before/after access matrix, inherited-access caveats, approvals, applied changes, audit evidence, and rollback.

Error Handling

Condition	Response
Plan or owner prerequisite fails	Stop and report the unavailable control.
Effective access is ambiguous	Do not remove or grant access until inheritance is resolved.
Change would incur unapproved charges	Leave ACLs unchanged.
Verification differs from desired state	Roll back safe changes and escalate.

Examples

The example below is a redacted operator receipt; it contains no task text, member data, credential, or webhook secret.

mode=plan; workspace=approved; custom-roles=3; excessive-access=2; changes=0; second-review=pending

Resources

• Skill-specific official documentation
• Object and location ACLs
• Authentication
• Rate limits