Skip to main content
ThreatLab controls access through a capability-based permission model rather than a flat role hierarchy. Permission roles grant specific capabilities, and a user’s effective access is the union of all capabilities across every permission role they hold. Title roles are purely cosmetic — they affect how your name appears in the UI but grant no permissions whatsoever. This separation keeps authorization decisions explicit and auditable.

Role Types

Permission Roles

Grant one or more capabilities. Every authorization decision in ThreatLab — server actions, API routes, and UI elements — is gated on a specific capability drawn from a permission role. A user can hold multiple permission roles; their effective capabilities are the combined set.

Title Roles

Display-only labels such as SOC Lead, Instructor, or Engineer. Title roles appear next to your name in the platform but carry no permissions and are never checked during authorization.

System Roles

Two roles are built into ThreatLab and cannot be modified or deleted: Additional title roles — such as Engineer and Instructor — are pre-configured on every ThreatLab instance for cosmetic use.

Capabilities Reference

The table below lists every capability in ThreatLab, its display label, and what it authorises you to do:

Checking Your Own Capabilities

You do not need to memorise which roles you hold. ThreatLab surfaces your permissions in two practical ways:
The sidebar only renders navigation items that your account has the capability to access. If an admin page or feature is not visible in the sidebar, your account does not currently hold the required capability.
Contact your ThreatLab administrator to have roles assigned to your account. Administrators manage role assignments under Admin > Users.