Skip to content

Permissions & Scopes

RedCloud authorizes every action against dot-namespaced permission strings granted per role. The model is strict: a caller must hold all required permissions, there is no wildcard bypass, and the most sensitive admin actions additionally require MFA.

  • Permissions look like scans.run, audit.view, admin.users, chat.use.
  • Roles bundle permissions; users (and API keys) inherit their role’s permissions.
  • Permissions are re-resolved from the database on each request, so changes take effect quickly.
  • has_permission requires all listed permissions — holding “most” is not enough, and there is no * shortcut.
PermissionAllows
dashboard.view / dashboard.exportView / export dashboards
scans.view / scans.run / scans.deleteView / launch / delete scans
iac.view / iac.scanView / run IaC scans
audit.view / audit_logs.exportView / export the audit log
scheduler.viewView the scheduler
chat.use / chat.analyticsUse / see analytics for the AI assistant
admin.users / admin.roles / admin.settings / admin.integrationsAdministration areas

A granular catalog also covers approvals (ra.approve_high, ra.approve_critical), integrations (integrations.jira, integrations.slack, …), reports, custom fields, and more.

The high-impact admin permissions — admin.users, admin.roles, admin.integrations, admin.settings — additionally require the caller to have TOTP (2FA) enabled in production. Without it, the API returns 403 MFA_REQUIRED.

Cross-tenant platform actions require an explicit database super-admin flag (not just a permission). Break-glass does not satisfy this — it is deliberately not super-admin.

Some endpoints are gated by your license plan via require_feature(...). If the plan lacks the feature, the API returns 403 FEATURE_DISABLED (for example, scan report/export endpoints and the AI endpoints are feature-gated).

  • Break-glass receives a fixed, scoped permission set — never a wildcard.
  • Permission and role management lives under Administration → User Management.