Owner-Based RBAC Feature

In this guide, we'll explore Owner-Based RBAC—a feature designed for large organizations where multiple teams work within the same platform. It allows you to fine-tune access to elements within the platform based on the list of Owners users can access.

Access Model Without Owner-Based RBAC

Before Owner-Based RBAC, the platform uses organization-wide role-based access:

graph TB ORG[🏢 Organization<br/>All Resources] subgraph "Four Roles - Organization-Wide Access" ADMIN[👑 Admin<br/>Read + Write + Admin Actions<br/>Integrations, IAM, Settings] USER[👨‍💼 User<br/>Read + Write<br/>No Admin Actions] READER[👁️ Reader<br/>Read Only<br/>All Resources] AUDITOR[🔍 Attack Surface Auditor<br/>Asset Management via Owners<br/>Legacy Role] end ORG -.->|Full Access| ADMIN ORG -.->|Read+Write| USER ORG -.->|Read Only| READER ORG -.->|Owner-based Assets| AUDITOR style ORG fill:#95a5a6,color:#fff style ADMIN fill:#e74c3c,color:#fff style USER fill:#3498db,color:#fff style READER fill:#95a5a6,color:#fff style AUDITOR fill:#f39c12,color:#fff

Admin: Full read and write access to everything, plus administrative actions like managing integrations, IAM settings, and organization configuration.

User: Read and write access to all organization resources—assets, scans, tickets. Cannot perform admin actions like changing integrations or IAM settings.

Reader: Read-only access to all organization resources. Perfect for stakeholders who need visibility without modification rights.

Attack Surface Auditor: Legacy role that already uses Owners to manage asset access. This role is deprecated and will be removed soon.

The Problem: Everyone sees everything within the organization. No team boundaries. In large multi-team environments, this creates noise, confusion, and potential interference between teams.

Owner-Based RBAC solves this by adding granular, team-based access control.

What is Owner-Based RBAC?

Owner-Based RBAC introduces an intermediate access layer called 'Owners'—logical groups representing teams within your organization.

graph LR O[📁 Owners<br/>Groups] -->|Assigned to| U[👤 Users] O -->|Control| A[📦 Assets<br/>Apps, Domains, IPs] S[🔍 Scans<br/>Security Tests] -->|Run on| A S -->|Create| T[🎫 Tickets<br/>Vulnerabilities] style U fill:#3498db,color:#fff style O fill:#2ecc71,color:#fff style A fill:#f39c12,color:#fff style S fill:#9b59b6,color:#fff style T fill:#e74c3c,color:#fff

The flow is simple: Owners are assigned to Users. Owners control Assets like mobile apps, domains, and IP addresses. Scans run on Assets. After completion, Scans create Tickets for discovered vulnerabilities. Access automatically propagates: If you have access to an Owner, you automatically access all its assets, scans, and tickets. No manual permission management needed. The system is hierarchical—Owners can have parent-child relationships mirroring your org structure. This creates natural, manageable access patterns while the platform handles complex calculations automatically.

User Roles in Owner-Based RBAC

When Owner-Based RBAC is enabled, role capabilities change:

flowchart TB subgraph roles["Role Permissions"] A["👑 Admin<br>Full Organization Access<br>Bypasses Owner restrictions"] B["👨‍💼 User<br>Read + Write<br>Within assigned Owners<br>No Owners = All Access"] C["👁️ Reader<br>Read Only<br>Within assigned Owners<br>No Owners = All Access"] D["🔍 Attack Surface Auditor<br>Same as User<br>Deprecated - Will be removed"] end A -. Unrestricted .-> ALL["All Resources"] B -. Restricted .-> OWN1["Owned Resources<br>or All if no Owners assigned"] C -. Restricted .-> OWN2["Owned Resources<br>or All if no Owners assigned"] D -. Restricted .-> OWN3["Same as User"] style A fill:#e74c3c,color:#fff style B fill:#3498db,color:#fff style C fill:#95a5a6,color:#fff style D fill:#f39c12,color:#fff,stroke-dasharray: 5 5

Admin: Unchanged—full unrestricted access to everything. Bypasses all Owner restrictions. Can perform admin actions like managing integrations and IAM settings.

User: Read and write access to assets within assigned Owners. Can initiate scans, manage vulnerabilities, and work with tickets for their Owner's resources. Important: If no Owners are assigned, User has access to ALL organization resources.

Reader: Read-only access to assets within assigned Owners. Cannot modify anything. Important: If no Owners are assigned, Reader has read access to ALL organization resources.

Attack Surface Auditor: Deprecated legacy role. Currently behaves the same as User role. Will be removed in future releases—use User role instead.

Key distinction: Admins ignore Owner boundaries. Users and Readers respect Owner assignments or get full access when no Owners are assigned.

Access Hierarchy - The Foundation

Access flows through a clear chain:

graph TD O[📁 Owners] -->|1.Assigned to| U[👤 Users] O -->|2.Control| A[📦 Assets] A -->|3.Have| S[🔍 Scans] S -->|4.Generate| T[🎫 Tickets] ST[📝 Standalone Tickets] -.->|Visible to ALL| U style U fill:#3498db,color:#fff style O fill:#2ecc71,color:#fff style A fill:#f39c12,color:#fff style S fill:#9b59b6,color:#fff style T fill:#e74c3c,color:#fff style ST fill:#e67e22,color:#fff,stroke-dasharray: 5 5

Step 1: Owners are assigned to Users—the foundation of all access.

Step 2: Owners control Assets—mobile apps, domains, IP addresses.

Step 3: Scans run on Assets. If you access the asset, you access its scans.

Step 4: Scans generate Tickets. If you access the scan, you access its tickets.

Exception: Standalone Tickets—created manually without scans—are visible to ALL users organization-wide. This ensures important announcements and manual findings reach everyone.

The hierarchy creates automatic, cascading access that mirrors real security workflows.

Owner Hierarchy - Parent-Child Relationships

Owners can form hierarchies—parent-child relationships mirroring your org structure.

graph TD P[👔 Engineering Team<br/>PARENT Owner] C1[📱 Mobile Team<br/>CHILD Owner] C2[🌐 Web Team<br/>CHILD Owner] P --> C1 P --> C2 C1 --> A1[iOS Apps] C1 --> A2[Android Apps] C2 --> A3[Domains] C2 --> A4[APIs] U1[👤 User assigned to<br/>Engineering Parent] -.->|Sees| P U1 -.->|Sees| C1 U1 -.->|Sees| C2 U2[👤 User assigned to<br/>Mobile Child] -.->|Sees ONLY| C1 style P fill:#e74c3c,color:#fff style C1 fill:#3498db,color:#fff style C2 fill:#3498db,color:#fff style U1 fill:#2ecc71,color:#fff style U2 fill:#f39c12,color:#fff

Downward access is key:

User assigned to Parent Owner sees all child Owners and their assets. Perfect for managers overseeing multiple teams.

User assigned to Child Owner sees ONLY that child and its assets—not the parent or siblings. This ensures team members stay focused on their scope without seeing unrelated data.

Example: Assigned to Mobile Team? You see ONLY Mobile assets—not parent Engineering or sibling Web Team.

Assigned to Engineering Parent? You see Engineering plus ALL children: Mobile and Web Teams.

This is recursive—grandchildren are visible to grandparents. Build deep org structures with clear access boundaries.

Access Propagation Example - Following the Chain

Let's trace a real example of access propagation.

flowchart LR U[👤 Jane] -->|Assigned| O[📁 Mobile Team] O -->|Controls| A1[📱 Banking App] O -->|Controls| A2[📱 Payment App] A1 -->|Scanned| S1[🔍 Scan #12345] A2 -->|Scanned| S2[🔍 Scan #12346] S1 -->|Found| T1[🎫 SQL Injection] S1 -->|Found| T2[🎫 XSS] S2 -->|Found| T3[🎫 Weak Crypto] U -.->|✓ Accesses| A1 U -.->|✓ Accesses| A2 U -.->|✓ Accesses| S1 U -.->|✓ Accesses| S2 U -.->|✓ Accesses| T1 U -.->|✓ Accesses| T2 U -.->|✓ Accesses| T3 style U fill:#3498db,color:#fff style O fill:#2ecc71,color:#fff style A1 fill:#f39c12,color:#fff style A2 fill:#f39c12,color:#fff

Jane is assigned to the Mobile Team Owner.

Mobile Team controls two assets: Banking App and Payment App. Jane automatically accesses both.

Scans run: Scan #12345 on Banking App, Scan #12346 on Payment App. Jane can access both scans because they're on her Owner's assets.

Vulnerabilities found: SQL Injection and XSS in Banking App. Weak Crypto in Payment App. Jane accesses all three tickets automatically.

One assignment → Seven resources accessed. The chain works automatically: User → Owner → Assets → Scans → Tickets. No manual permission management needed."

Activate Owner-Based RBAC

To activate Owner-Based RBAC, start by clicking the menu button on the top left side of the screen.

Then locate Settings in the menu.

And click on Organization.

Scroll down until you find the toggle for Enable Object Level Access Control.

If the toggle is off, the platform will use the legacy mode where all users see all resources within the organization. If you turn the toggle on, it will activate the new Owner-Based RBAC system, filtering all queries by Owner assignments and enabling the Owner assignment interface.

In this guide, we explored Owner-Based RBAC, a powerful feature designed for large organizations with multiple teams working on the same platform. We saw how it provides granular, team-based access control that eliminates the noise and confusion of everyone seeing everything.