troq rbac command group is the operator surface for inspecting this model, checking access, and managing member assignments.
The full command surface is:
roles-list, roles-permissions-list, members-list, members-assign-role, and check. Two additional commands, roles-create and roles-permissions-replace, exist for administrative use but are intentionally hidden from the default help output. They are not intended for routine workspace operations.
How Roles Work
Roles are workspace-scoped. A workspace starts with four system roles:owner, admin, developer, and viewer. These are created automatically and their names are fixed and cannot be renamed or deleted. Each role carries a set of permission keys that determine what the holder can read or write in the platform.
Permissions in the platform are namespaced by resource and operation, following the pattern <resource>.<action>. For example: apps.read, secrets.write, members.read, roles.read. A role may carry any combination of these keys, and a member inherits all of them through their assigned role.
There is no concept of individual permission overrides at the member level in the CLI. If you need different access boundaries for different people, they need different roles. Fine-grained per-member overrides are available through the web interface.
Listing Roles
troq rbac roles-list returns all roles in the active workspace, each with its system identifier, human-readable name, and role code.
role_id for each role. Role identifiers follow the format <workspace_uuid>:<role_name>, for example e3ad3c79-b320-41d5-ba0a-1d8ec225ed20:viewer. This full identifier is what you need when passing --role-id to other commands.
Inspecting Role Permissions
To see which permission keys a specific role carries, useroles-permissions-list. The command requires a role identifier. If you do not pass --role-id, it presents an interactive selector that lists all roles in the workspace so you can pick one by name.
roles.read permission.
This is the right command to run before assigning a role to a member, so you know exactly what access you are granting.
Listing Members
troq rbac members-list shows all members currently active in the workspace, their assigned role name, and their membership status.
user_id values for use in members-assign-role and check. The user_id field in the output is the identifier the platform uses for all member-scoped operations.
Assigning a Role to a Member
troq rbac members-assign-role changes the role binding for a workspace member. When run interactively, it presents a member selector first, then a role selector. Before submitting the request, it prints the permission keys the selected role carries, giving you a clear view of what access you are about to grant.
--user-id and --role-id must be the full identifiers returned by members-list and roles-list respectively. Passing a partial or workspace-only UUID will not match any record.
This operation requires the members.write permission. If you are unsure whether you hold it, check first:
Checking Permissions
troq rbac check evaluates whether a specific user holds a given permission in the active workspace. When --user-id is omitted, it opens an interactive member selector with your own account pre-selected. This makes it easy to verify your own access without looking up your user ID first.
allowed: true or allowed: false line. This is intentionally minimal, the command is meant for quick spot checks, not for building policy dashboards.
This command requires the roles.read permission to execute.
Non-Interactive Usage
All commands that present interactive selectors fall back to flag-based input when stdin is not a terminal. This means they work cleanly in scripts, CI pipelines, and LLM-driven automation without modification, just pass the flags directly.Output Formats
Allrbac commands support --output table, --output json, and --output jsonl. Table mode is the default and is optimized for human reading. JSON and JSONL outputs carry the full response payload and are suitable for piping into downstream tools.