Roles and Permissions

Overview

Fencer uses a role-based access control (RBAC) system to govern what each user can see and do within an organization. Every member of an organization is assigned exactly one role, and that role determines the set of permissions they hold. Understanding roles is essential for keeping your security data safe while giving teammates the access they need.

How it works

Permissions follow a resource:action format (for example, vulnerabilities:edit or scans:execute). When you perform an action in Fencer — whether through the UI or the API — the system checks whether your role includes the required permission. If it does not, the request is denied, and links to pages your role cannot open are left out of the sidebar.

Each built-in role is assigned a fixed set of permissions, listed in the table below. Fencer staff accounts (internal platform administrators) hold every Administrator permission in every organization.

Permissions decide who may use a feature; your plan decides whether the organization has it. A paid feature your plan does not include stays locked whatever your role.

Roles

Fencer has four built-in roles, and Administrators can also create custom roles. You assign Administrator, Team Member, Read Only, or a custom role when you invite someone, and you can change it at any time from Admin > Team. The Penetration Tester role cannot be assigned directly: the penetration-testing workflow grants it.

Administrator

The Administrator role has full control over the organization. Admins can manage members, configure organization settings, manage integrations and roles, and perform every action available to other roles.

Team Member

The Team Member role is intended for day-to-day security practitioners. Members can add and edit assets, run scans, triage vulnerabilities, view detections and hunt through security events, manage detection rule sources and rule variables, and comment on detections. They cannot change detection status or rule settings, delete assets, connect integrations, edit vendors, or manage the team, roles, or organization settings.

Read Only

The Read Only role provides view-level access across the platform. Read-only users can see assets, scans, vulnerabilities, identities, detections, and vendors, but they cannot change them. They can still manage their own personal notification rules and complete access reviews assigned to them.

Penetration Tester

The Penetration Tester role is a scoped role for external or internal pen testers. Its permissions apply only to the penetration test engagements the tester is assigned to: there they can view and run scans, upload results, edit findings, and verify fixes. Pentesters have no organization-wide access to data, so Penetration Testing is the only sidebar link they see. They do not have access to assets, detections, or organization settings.

Custom roles

When a built-in role grants too much or too little, an Administrator can define a custom role under Admin > Team > Roles:

1. Click Create role, or open a built-in role and click Duplicate to start from its permissions.
2. Enter a Name and an optional Description. Start from copies the permissions of an existing role; later changes to that role do not carry over.
3. Under Permissions, grant actions area by area (for example Asset Inventory, Security Monitoring, or Team), or use Grant all for an area.
4. Click Create role.

Custom roles follow a few rules:

• A custom role can hold only permissions the Administrator, Team Member, or Read Only roles hold. Creating, editing, and deleting roles stays with the built-in Administrator role (shown as Built-in roles only), and the tester-side penetration testing permissions stay with the built-in Penetration Tester role.
• Some permissions bring others with them, and the editor ticks them for you: inviting or editing members, creating API keys, and editing organization settings each add roles:read; automations:read adds org_settings:read; and automations:edit adds automations:read and org_settings:edit.
• Built-in roles cannot be changed or deleted. To delete a custom role that members still hold, choose a role to Move to; a role still used by a service account or as the SSO or SCIM default role cannot be deleted.
• You can only assign a role whose permissions you hold yourself, unless you are an Administrator.

Use the Compare view on the Roles tab to see what each role holds, area by area.

Permission reference

The table below lists every permission a role can hold, grouped by the area the role editor shows it under, and which built-in roles include it.

Area	Permission	Admin	Member	Read Only	Pentester
Asset Inventory	assets:read	Yes	Yes	Yes
Asset Inventory	assets:create	Yes	Yes
Asset Inventory	assets:edit	Yes	Yes
Asset Inventory	assets:delete	Yes
Scans	scans:read	Yes	Yes	Yes	Yes
Scans	scans:edit	Yes
Scans	scans:execute	Yes	Yes		Yes
Vulnerabilities	vulnerabilities:read	Yes	Yes	Yes	Yes
Vulnerabilities	vulnerabilities:edit	Yes	Yes		Yes
Identities	identities:read	Yes		Yes
Access Reviews	identity_reviews:read	Yes	Yes	Yes	Yes
Access Reviews	identity_reviews:review	Yes	Yes	Yes	Yes
Access Reviews	identity_reviews:manage	Yes
Penetration Testing	pentests:submit_fix	Yes	Yes		Yes
Penetration Testing	pentests:edit_finding				Yes
Penetration Testing	pentests:verify_finding				Yes
Penetration Testing	pentests:upload_results				Yes
Security Monitoring	detections:read	Yes	Yes	Yes
Security Monitoring	detections:edit	Yes
Detection Rules & Alerting	secops:read	Yes	Yes	Yes
Detection Rules & Alerting	secops:create	Yes	Yes
Detection Rules & Alerting	secops:edit	Yes	Yes
Detection Rules & Alerting	secops:delete	Yes	Yes
Threat Hunting	hunt:read	Yes	Yes	Yes
Data Sources	data_sources:read	Yes	Yes	Yes
Data Sources	data_sources:edit	Yes	Yes
Agents	agents:read	Yes	Yes	Yes	Yes
Agents	agents:edit	Yes	Yes
Inbox	inbox:read	Yes	Yes	Yes	Yes
Inbox	inbox:edit	Yes	Yes		Yes
Integrations	integrations:read	Yes
Integrations	integrations:create	Yes
Integrations	integrations:delete	Yes
Vendor Catalogue	vendors:read	Yes	Yes	Yes
Vendor Catalogue	vendors:edit	Yes
Team	members:read	Yes
Team	members:create	Yes
Team	members:edit	Yes
Team	members:delete	Yes
Roles & Permissions	roles:read	Yes
Roles & Permissions	roles:create	Yes
Roles & Permissions	roles:edit	Yes
Roles & Permissions	roles:delete	Yes
Organization Settings	org_settings:read	Yes
Organization Settings	org_settings:edit	Yes
Automations	automations:read	Yes
Automations	automations:edit	Yes
Service Accounts	api_keys:read	Yes
Service Accounts	api_keys:create	Yes
Service Accounts	api_keys:delete	Yes

In the role editor, read is labelled View, execute Run, identity_reviews:review Attest, and identity_reviews:manage Manage campaigns. Detection Rules & Alerting covers rule sources, rule variables, and comments on detections; changing a detection’s status or a rule’s settings is detections:edit.

automations:read requires org_settings:read, and automations:edit requires automations:read and org_settings:edit. Personal notification rules need no permission: Administrator, Team Member, and Read Only users manage their own under User settings > Notifications. Penetration Tester and custom roles cannot.

Usage

Permissions are enforced automatically throughout the platform. When a user attempts an action they don’t have permission for, they’ll see an appropriate error message or the action will be hidden from the interface. No additional configuration is required — the permissions table above defines exactly what each built-in role can do.

Examples

Scenario: Inviting an external pen tester. You hire a contractor to run a penetration test. You set up the engagement, and the penetration-testing workflow gives them the Penetration Tester role. On that engagement they can run scans and log findings, but they cannot access your detection pipeline, organization settings, or member list.

Scenario: Onboarding a new analyst. A new security analyst joins your team. You assign them the Team Member role. They can create assets, run scans, triage vulnerabilities, and read detections — everything needed for daily work — without the ability to change organization settings or manage team membership.

Scenario: Giving a stakeholder visibility. A compliance officer needs to review your security posture but should not make changes. You assign them the Read Only role. They can view assets, vulnerabilities, detections, and vendors across the platform.

Scenario: Letting a team lead manage integrations. Duplicate Team Member, grant View, Create, and Delete under Integrations and View under Organization Settings (the Admin section of the sidebar appears only to roles that can view organization settings), and assign the new role to the team lead.

Troubleshooting

• “Permission Denied” when accessing a page or API endpoint. Verify the user’s role includes the required permission by checking the table above. An Admin can update the user’s role from **Admin

  Team**.

• A role is missing from the role picker. Pickers offer only roles you are allowed to hand out: the Administrator, Team Member, Read Only, and custom roles whose permissions you hold yourself. Penetration Tester is never offered.
• Fencer staff can see your organization. This is by design — Fencer staff accounts hold every Administrator permission in every organization. This status is only granted to internal platform administrators.

Related pages

• Platform Overview
• Team and Member Management
• Organization Settings