Roles & permissions
Four roles per organisation. Every capability in the product resolves against this matrix. The dashboard and the CLI enforce the same boundaries.
The roles
| Role | In one line |
|---|---|
| Organisation Admin | Governs the organisation, including people, projects, models, access, and settings. |
| Security Researcher | Does the security work. Full findings authority, including accepting risk. |
| Developer | Works within their own scope: their models, scans, and findings. |
| Executive | Reads posture at summary level. No raw findings, no administration. |
Permission matrix
| Capability | Admin | Exec | Security | Developer |
|---|---|---|---|---|
| View organisation overview | Yes | Yes | Limited | Limited |
| Manage organisation settings | Yes | - | - | - |
| Manage users | Yes | - | - | - |
| Manage models | Yes | - | Optional | Optional |
| Set model criticality | Yes | - | Limited | - |
| Manage projects | Yes | - | - | - |
| Manage CLI access | Yes | - | - | - |
| Generate CLI keys | Yes | - | Limited | Limited |
| View CLI activity | Yes | Summary | Yes | Yes |
| View scan results | Yes | Summary | Yes | Yes |
| Manage findings | Optional | - | Yes | Limited |
| Change severity | Yes | - | Yes | - |
| Accept risk | Approval | - | Yes | - |
| View runtime alerts | Yes | Summary | Yes | Summary |
| Generate technical reports | Yes | - | Yes | Yes |
| Generate executive reports | Yes | Yes | Optional | - |
| View audit logs | Yes | - | Limited | - |
| Manage integrations | Yes | - | Limited | - |
Reading the levels
- Yes: full access.
- Limited: access confined to their own scope, or to a subset of the actions.
- Summary: aggregate figures only, without the underlying records.
- Optional:available, but not the role's primary path.
- Approval: the action requires sign-off rather than being taken unilaterally.
- -: no access.
Why accepting risk sits with Security, not Admin
A security researcher can accept a risk outright; an org admin only through approval. Accepting risk is a security judgement, and separating it from the person who controls accounts keeps one role from being able to both create a finding and dismiss it without approval.
Developer scope
Developers see the models and projects they are assigned, not the whole organisation. Their overview, scans, findings, and CLI activity are all filtered the same way. So a developer on the support bot does not see the payments agent's findings.
Assign scope from Models & projects.
Changing someone's role
Only an org admin can. The change takes effect at their next sign-in and applies to the CLI too. A developer promoted to security researcher gains wider payload access on their next secureai login. See Managing users.
CoreLayer staff
CoreLayer operates the platform from a separate internal console. Staff there can provision and administer organisations, but they cannot read your security findings, scan results, or reports. That separation is enforced by the platform, not by policy alone.