Each custom role is a named set of permission keys written as area:action, such as scan:run or issue:triage. A working example covers targets, profiles, scans, issues, schedules, groups, tags, CI, activity and settings. The API Reference lists the key each endpoint needs.
The short version
A custom role is a named bundle of permission keys. Every key follows the pattern area:action, for example scan:run or issue:triage. Give a role only the keys its owner needs for daily work, and add more later when someone reports a task they cannot finish.
How it works in Cyberlop
The activity feed records a custom role called "Pro Dev" at the moment someone creates it. The keys below show what a working role can hold.
| Area | Keys in the example role |
|---|---|
| Targets | target:read, target:create |
| Profiles | profile:read, profile:create, profile:update, profile:delete, profile:manage_credentials |
| Scans | scan:read, scan:run, scan:cancel, scan:delete, scan:read_report |
| Issues | issue:read, issue:triage, issue:export |
| Schedules | schedule:read, schedule:create, schedule:update |
| Groups and tags | group:read, group:create, group:update, group:delete, tag:read, tag:create |
| Pipeline and views | ci:trigger, dashboard:read, search:read |
| Activity and settings | audit:read, activity:read, activity:read_team, activity:read_all, settings:read |
Other keys sit outside that example. Next to every endpoint, the API Reference shows the permission it needs. It includes target:delete, schedule:delete, tag:delete, settings:update, user:manage, role:manage and team:manage. The last three change who can do what, so hand them out with care.
Two limits apply. Nobody can change the reserved SuperAdmin role, and the app refuses to delete a system role, so build a role of your own when you need something different.
What to do next
Start small and add keys when someone hits a wall. Read-only keys such as scan:read and issue:read make a safe base. Open the API Reference page and type a key into the filter box to see every route it covers.
The role form itself sits in Administration, which only admins see. Our capture did not cover that screen, so the final pick list is in the app. For the full steps, read how to create a custom role, or ask us on the contact page. The same idea in plain words lives in least privilege.
Related questions
- How do I create a custom role with specific permissions?
- How are permissions named?
- Which roles come built in?
- How do I see each user's role and team grants?
- How do I find the endpoint I need and the permission it requires?
Cyberlop API tokens and permissions: how to issue and limit them
Step-by-step, with annotated screenshots.
Updated · Back to the help centre
Still stuck?
Tell us what you see on screen and an engineer will help you sort it out.