Fortify implements a two-tier access control system — organization-level RBAC for platform access, and fine-grained per-resource permissions (FGA) that control exactly what each user can do on targets, sessions, libraries, and playground sessions.

Fortify's permission model ensures users only see and act on what they are authorized for. The UI renders dynamically based on the logged-in user's role — restricted actions and sections are hidden or disabled rather than surfaced as errors.

This page documents every role, resource, and permission rule in the system.

Access Control Model

Access control in Fortify operates at two distinct levels. The organization layer gates who can access Fortify at all. The fine-grained access (FGA) layer controls what each user can do within a specific resource — and varies per target, library, or playground session.

Resources

The following resources have their own FGA rules and permission matrix:

• Target
• Session
• Attack Library
• Attack Playground

Owner(Full control)

Full control over the resource including sharing, archiving, and managing ownership. Automatically assigned to the creator of the resource.

✓ Share resource with others
✓ View all resource content
✓ Archive resource
✗ Add or change owners

Collaborator(Read & Write)

Can actively work within the resource — create, view, and share — but cannot archive or manage ownership.

✓ Share resource with others
✓ View all resource content
✗ Archive resource
✗ Add or change owners

Viewer(Read only)

Read-only access to the resource. Cannot create, share, or archive anything. Suitable for consumers who need visibility without edit rights.

✗ Share resource
✓ View resource content
✗ Archive resource
✗ Add or change owners

Resources with FGA

Fine-grained access control applies to four resource types. Each has its own permission matrix and specific rules that govern creation, visibility, and management.

🎯 Target

The root resource. FGA roles are scoped per target. Only Org Admins can create targets. Creator is auto-assigned as owner.

📋 Session

Red teaming sessions run against a target. Permissions derived from the user's target role. Viewers can view and download but not create or archive.

📚 Attack Library

Custom attack prompt collections. Any user can create. Private by default — only becomes accessible when explicitly shared with others.

🕹️ Attack Playground

Manual adversarial testing sessions. Phase 1: fully private — only the session creator can view, run, or delete their own sessions.

Targets — permission matrix

🎯 Target resource

Target permissions control sharing, visibility, archiving, and ownership management. Only the target:owner can add another owner — this cannot be delegated to Collaborators or Viewers.

› Only Org Admin can create a target — not Members.
› The admin who creates the target automatically becomes target:owner.
› FGA roles apply to all users after target creation.

Sessions — permission matrix

📋 Session resource

Session permissions inherit from the user's role on the parent target. Owners and Collaborators have identical session permissions. Viewers can view and download sessions but cannot create new ones or archive existing ones.

› target:owner and target:collaborator have equal session permissions — full create, view, download, and archive
› target:viewer can view and download sessions but cannot create or archive.

Attack Library — permission matrix

📚 Attack Library resource

Any user — admin or non-admin — can create an attack library. A newly created library is private to the creator by default and only becomes accessible to others when the owner explicitly shares it. The library uses its own independent role set.

› Any admin or non-admin can create an attack library.
› Libraries are private to the creator by default until shared.
› Library roles ( library:owner , library:collaborator , library:viewer ) are independent from target roles.
› library:viewer can run attacks but cannot create, edit, or delete prompts.

Attack Playground — permission matrix

🕹️ Attack Playground resource

All Attack Playground sessions are private to the creator. Owners and Collaborators can run, view, and delete their own sessions only — they cannot access another user's sessions. Viewers have no access to the Attack Playground at all.

› Playground sessions are private — only the session creator can view, run, or delete them.
› fortify:owner and fortify:collaborator can only access their own sessions — not other users' sessions.
› fortify:viewer has no access to Attack Playground.

Step-by-step walkthrough

The following steps trace the complete lifecycle of setting up access control in Fortify — from creating a target as an Org Admin through to a team member using the Attack Playground within their permitted scope.

1. Org Admin creates a target

• Only an Org Admin can create a new target in Fortify.
• Navigate to the Targets tab and click on 'Add New Target' button on the right side of the screen. (Highlighted in Red)

• Complete the target configuration details such as — name, description, language, fallback response and integration settings.

• The target is created. The Org Admin who created it is automatically assigned as target:owner. No other users have access to this target yet.

2. Owner adds team members via Manage Members.

• As the target owner, open the target and navigate to the Manage Members page.(Highlighted in Red)

• User clicks on 'Add member' button, to add team members by email and assign each one a role — Collaborator for active testers, Viewer for stakeholders who need read access only.

• A toast message is displayed once the member is successfully added.

• The recently added member details gets updated in the Manage members page. (Highlighted in Red) Users can also click on the 'View Roles and Permission' section to view the permission matrix whenever they want.(Highlighted in Green)

• Team members receive access to the target. Each user's UI renders according to their assigned role — Collaborators see create and manage options; Viewers see read-only content only.

3. Each user sees a role-appropriate UI.

• When a team member logs in and opens the target, they see only the actions their role permits. Restricted controls are hidden — not shown as disabled errors. The UI adapts automatically to the logged-in user's FGA permissions.(As shown Below)

• Each user operates within their permitted scope with no friction — no permission errors, no broken states, no accidental access.

4. Collaborator creates and runs a session

• A team member with the Collaborator role navigates to the Sessions tab and clicks on 'Add New Session' button.

• They configure the session — selecting the target, judge mode, conversation type — and start the session.

• All session actions (create, view, download, archive) are fully available to Collaborators.

5. User creates and shares an Attack Library

• Any user — admin or non-admin - can create an Attack Library. Navigate to Attack Library → Create Library.

• The library is private by default. To make it available to others, click on any existing library, open 'Manage Members' within the library and add members with their respective library roles. (Highlighted in Red)

• This page showcases the list of existing members and their respective roles. User can click on the 'Add Member' button to add members.

• Users can 'Add Members' by searching the team members by email and selecting and assigning appropiate roles to them.

• A toast message is displayed once the member is successfully added.

  

• Now, the updated list of members who can access the attack library is shown below along with their roles. Only the Owner of the Attack library can 'Edit Role' or 'Delete' any existing member from the Attack Library.

• The library is now shared with the designated members.

6. Owner or Collaborator uses Attack Playground

• Navigate to Attack Playground and start a new playground session.

• Each user can only view, run, and delete their own sessions — no user can access another user's playground session, regardless of their Fortify role.

• The user runs their playground session privately. Their session is not visible to any other user in the organisation — including other Owners and Collaborators.

7. Owner updates a member's role or removes access

• As team composition changes, the target owner can return to Manage Members at any time to update a member's role or remove their access entirely.

• A system discalimer is shown confirming the role update. User clicks on 'Save Changes' to confirm and proceed.

• A toast message confiming that the member role has been updated successfully is shown.

• Role changes take effect immediately — the member's UI updates on their next page load.

• Similarly, an owner can remove a member access entirely. They can click on the 'Delete' icon beside the member record and proceed to delete the member access.

• A system prompt pops-up confirming the remove member action. Click on 'Remove Member' to confim and proceed.

• A toast message confiming that the member removed successfully is shown.

• Access is updated. The affected member's UI reflects their new permissions on next load. Removed members lose all access to the target, its sessions, and reports.

Manage members

A dedicated Manage Members page is available for both Targets and Attack Library resources. Member management is handled in a separate, focused view — not embedded inline within the resource UI — to keep permission changes auditable and intentional.

What the Manage Members page covers

🎯 Targets

• View all current members and their assigned role
• Add a new member and assign them a role
• Update an existing member's role
• Remove a member from the target
• Only target:owner can add or promote owners
• Manage Members option hidden for Viewers

📚 Attack Library

• View all users with access to the library
• Add members and assign library role
• Update an existing member's role
• Revoke a member's access
• Library remains private until first member is added

---

RBAC Phase 2

As Fortify scales across more organizations, targets, and libraries, access management needs to move from manual, one-off admin work to structured, self-service controls.

This update covers planned RBAC improvements across four areas:

1. Global visibility for security/audit personnel via a new Super Admin role
2. Self-service ownership transfer for targets.
3. Organization-level UX improvements — switching, display, and access-failure handling

1. Super Admin Role — Global Visibility via Audit Access

A new Super Admin role will let security personnel (e.g., CISOs) audit access across all targets and libraries, without needing to be manually added as a member of every individual resource.

• A dedicated Super Admin visibility page is added to Fortify, giving a single place to review access across the organization.
• User can click on their 'Profile name' on the top-right corner of the screen. Under the various options, 'Audit Access' can now be found.

• Now, 'Org name' is displayed once org selection is done on Fortify. This helps the Super Admin to know which 'Org' they are currently accessing. In the example below, the current org which the user is using is 'FortifyTeam'.

• Click on 'Audit Access' to open the super admin visibility page. A banner can seen, mentioning the type of access granted to the 'Super Admin'.

• Here a high-level summary of all the accesses available is shown. Ex: Number of Targets, Attack Library and Total Users.
• The page is segregated by having specific tabs for both 'Targets' and 'Attack Library'. Click on the tab to view the specific accesses.
• All the 'Targets/Attack library' access details is listed with 'Target/Attack Libray Name', 'the number of members'(who have access), their respective 'email' and their current 'role'.
• Super Admin can search for any 'Targets or Attack Library' using - 'Target name', 'Username' or 'email'. (Highlighted in Green)
• A 'Download' button is provided for the Super Admin which downloads the 'current Orgs' 'resource/member access list' in the form of PDF. (Highlighted in Red)

2. Self-Service Target Ownership Transfer

Earlier, reassigning a target's owner requires a manual database override. With this update, that is being moved to a self-service UI flow with the following rules:

1. An owner can assign another user as owner.
2. An owner can 'remove' themselves only if more than one owner exists on the target.
3. If only one owner is present, that owner cannot be 'removed' — every target must always retain at least one owner.

3. Organization Switcher

Users with access to multiple organizations will be able to switch between them directly within Fortify.

• Click on 'Switch Organization' to switch to other 'Orgs' the user is assigned to.

• This redirects the user to the screen where all the 'assigned Orgs' are visible to the user. (If applicable)
• The current org is depicted with a 'Current' tag. (In Green)
• User can click on any other Org of their choice. For example: User can click on 'Ali's Test Organization' and switch to that org.

• As seen above, the user Org has been 'switched' successfully.