Role-Based Access Control (RBAC)
Last updated: June 23, 2026
Aisle uses Role-Based Access Control to manage what users can see and do within the platform. This article explains the available roles, what each can do, and how to think about access design.
For step-by-step instructions on assigning roles, see User management.
How access works in Aisle
Two things determine what a user can do:
Their role, which defines a set of permissions.
The scope of that role — either the whole platform (global) or specific teams (team-scoped).
Global roles (Admin, CISO) apply across all repositories.
Team-scoped roles (Security Engineer, Developer, Observer) only apply within the teams a user is assigned to. A Security Engineer in Team A cannot access repositories in Team B.
A user can hold different team-scoped roles in different teams — for example, Security Engineer in the Platform team and Developer in the Mobile team. Global roles, by contrast, apply platform-wide.
A note on authentication. Aisle relies on your organization's identity provider (SSO) for sign-in. RBAC only determines what a user can do after they've authenticated. Creating a user in Aisle doesn't grant them login access on its own — they must also exist in your IdP.
The five roles at a glance
Role | Scope | Primary purpose |
|---|---|---|
Admin | Global | Full platform administration and configuration |
CISO | Global | Security oversight with read access and user management |
Security Engineer | Team | Vulnerability triage and scanner management within team repos |
Developer | Team | Fix vulnerabilities and create pull requests within team repos |
Observer | Team | Read-only access to team repositories |
Admin
Full access to all platform and repository features. The only role that can create or delete scanners, create or delete repositories, delete users, or update platform settings. Assign sparingly — Admin should be reserved for people who own platform configuration.
CISO
Designed for security oversight, not operations. CISOs have read access to all repositories and can manage users, teams, and reports — but cannot create fixes, configure scanners, modify repositories, or delete users. Use this role for security leadership who need visibility across the whole platform without operational permissions.
Security Engineer
The full issue-lifecycle role within assigned teams: triage, ignore, dismiss, retriage, move to backlog, and create fixes. Can also enable or disable existing scanners on their team's repositories (but not create new scanner configurations).
Developer
Fix-focused. Within assigned teams, Developers can create fixes, open pull requests, download patches, and use chat to update proposed fix. They cannot triage issues or manage scanners. This is the role for engineers who should remediate issues but not make triage decisions.
Observer
Read-only within assigned teams. Suitable for auditors, stakeholders attending reviews such as engineering managers, or anyone who needs visibility without the ability to act.
Platform permissions
These actions apply globally and are only available to Admin and CISO.
Category | Action | Admin | CISO | Sec. Eng. | Developer | Observer |
|---|---|---|---|---|---|---|
User Management | view | ✓ | ✓ | ✗ | ✗ | ✗ |
create | ✓ | ✓ | ✗ | ✗ | ✗ | |
update | ✓ | ✓ | ✗ | ✗ | ✗ | |
delete | ✓ | ✗ | ✗ | ✗ | ✗ | |
Team Management | view | ✓ | ✓ | ✗ | ✗ | ✗ |
create | ✓ | ✓ | ✗ | ✗ | ✗ | |
update | ✓ | ✓ | ✗ | ✗ | ✗ | |
delete | ✓ | ✓ | ✗ | ✗ | ✗ | |
Repository Management | create | ✓ | ✗ | ✗ | ✗ | ✗ |
update | ✓ | ✗ | ✗ | ✗ | ✗ | |
delete | ✓ | ✗ | ✗ | ✗ | ✗ | |
Scanner Management | create | ✓ | ✗ | ✗ | ✗ | ✗ |
update | ✓ | ✗ | ✗ | ✗ | ✗ | |
delete | ✓ | ✗ | ✗ | ✗ | ✗ | |
Settings & Reports | settings-update | ✓ | ✗ | ✗ | ✗ | ✗ |
report-manage | ✓ | ✓ | ✗ | ✗ | ✗ |
Repository permissions
These actions apply at the repository level. Admin and CISO have global access; team-scoped roles (●) only have access within their assigned teams.
Category | Action | Admin | CISO | Sec. Eng. | Developer | Observer |
|---|---|---|---|---|---|---|
Repository Access | view | ✓ | ✓ | ● | ● | ● |
update | ✓ | ✗ | ✗ | ✗ | ✗ | |
Issue Remediation | issue-fix | ✓ | ✗ | ● | ● | ✗ |
issue-create-pr | ✓ | ✗ | ● | ● | ✗ | |
issue-download-fix | ✓ | ✗ | ● | ● | ✗ | |
issue-chat-refix | ✓ | ✗ | ✗ | ● | ✗ | |
Issue Triage | issue-ignore | ✓ | ✗ | ● | ✗ | ✗ |
issue-dismiss | ✓ | ✓ | ● | ✗ | ✗ | |
issue-retriage | ✓ | ✗ | ● | ✗ | ✗ | |
issue-move-to-backlog | ✓ | ✗ | ● | ✗ | ✗ | |
issue-chat-retriage | ✓ | ✗ | ● | ✗ | ✗ | |
Scanner Control | scanner-enable | ✓ | ✗ | ● | ✗ | ✗ |
scanner-disable | ✓ | ✗ | ● | ✗ | ✗ |
Legend: ✓ Global access · ● Team-scoped · ✗ No permission
Designing access for your organization
A few principles that tend to work well:
Keep Admin tight. Admin is the only role that can delete users and reconfigure scanners. Two or three Admins is usually enough, even for large organizations.
Use CISO for visibility without operational power. If a security leader needs to see everything but doesn't need to configure the platform, CISO is the right role. It lets them manage users and run reports without giving them the ability to change repositories or scanner configurations.
Default new engineers to Developer. Developers can remediate issues within their team's repositories but can't override triage decisions. This keeps the triage queue under the security team's control.
Reserve Security Engineer for people who triage. The Security Engineer role exists because triage is a security judgment call — deciding what's a false positive, what's acceptable risk, what should be re-triaged. Assign it to people who own that judgment for a team.
Use Observer for auditors and stakeholders. Anyone who needs to look but not act — auditors, compliance reviewers, leadership doing spot checks — should get Observer in the relevant teams.
Frequently asked questions
Can a user have multiple roles?
Yes, but only at the team-scoped level. The same user can be a Security Engineer in Team A and a Developer in Team B. Global roles (Admin, CISO) apply platform-wide and aren't combined with team-scoped roles.
What's the difference between "ignore" and "dismiss"?
Ignore marks an issue as a false positive — it won't be reported again.
Dismiss marks an issue as accepted risk for a certain time period, after which it will be reported again.
Who can configure scanners?
Only Admins can create, update, or delete scanner configurations at the platform level. Security Engineers can enable or disable existing scanners within their team's repositories.
Who can invite new users?
Admins and CISOs can create user accounts. Note that creating a user in Aisle doesn't automatically grant login access — users must also exist in your organization's identity provider. See [Managing users] for the full flow.
How do I request a role change?
Contact your Admin or CISO — both can modify role assignments.
What does "team-scoped" mean in the permission matrix?
The ● symbol means the role only has that permission within repositories assigned to their team. They cannot perform that action on repos outside their team.
Can Security Engineers create new scanners?
No. They can enable or disable existing scanners on their team's repos. Only Admins can create, update, or delete scanner configurations.