Teams & Permissions

Manage team access, roles, and fine-grained permissions across your organization

Overview

ZeroPath uses a fine-grained authorization (FGA) system to control access to resources within your organization. Teams group users together and can be assigned to specific repositories, letting you control who sees what.

Team Management

Creating Teams

1. Navigate to Settings → Teams in the dashboard.
2. Click “Create Team”.
3. Give the team a name and optional description.
4. Add members by email or username.
5. Assign repositories the team should have access to.

Team Members

Teams can include:

• Users — people with ZeroPath accounts in your organization
• Contributors — code contributors identified from Git blame data (matched by email, name, or VCS username)

Contributors are automatically associated with teams when their git commit metadata matches a team member’s identity.

Linking Unmatched Contributors

When ZeroPath identifies code contributors that haven’t been matched to a user account, they appear in the Unmatched Contributors panel. From here you can:

• Search contributors by name, username, or email to quickly find the person you want to link.
• Search organization members within the assignment dropdown to find the right account.
• Link contributors individually — each contributor can be linked independently without blocking other link operations.

Default Team Permissions

You can configure baseline permissions that are automatically applied to teams created by GitHub team sync. This is especially useful when enabling access control for the first time, since newly synced teams start with no permissions by default.

From Settings → Teams:

1. Click “Configure Defaults” to open the Default Team Permissions editor.
2. Set the baseline permissions you want every new synced team to receive across three categories (see below).
3. Click “Save Defaults” to persist your changes.
4. Click “Apply to All Teams” to backfill the configured defaults onto all existing teams in your organization. Existing permissions are preserved — defaults are added on top.

When you first enable access control, a warning banner explains that teams without configured permissions will have no access. You can dismiss this banner after configuring permissions for your teams or applying defaults.

Permission Categories

The default permissions editor organizes permissions into three categories, each shown with a summary count of how many defaults are currently selected:

Organization Permissions — Controls what synced teams can do at the organization level, grouped into:

Group	Permissions
Member Management	Edit member roles, invite members, remove members
Team Management	View teams, create teams, manage teams
Installations	View, create, and delete VCS installations (GitHub, GitLab, etc.)
API Tokens	View, create, and delete API tokens
Alerts & Monitoring	View, edit, create, and delete security alerts
Repository Management	Create repositories and uploaded repository scan targets
Custom Reports	View, create, and delete saved custom reports
Assistant	Open the assistant and run user-scoped assistant chats

Repository Permissions — Default repository permissions are applied universally, meaning synced teams receive these permissions across every repository in the organization. Groups include:

Group	Permissions
Repository Access	View repository
Security Scans	View scans, start scans, cancel scans
Issue Management	Archive issues, mark as true/false positive, require context for false positives, open/close issues, edit priority, delete issues
Patches & Fixes	Generate patches, create pull requests
PR Security Checks	Bypass pull request security checks

Team Self-Management — Controls whether teams can manage their own settings and membership by default. Individual permissions include editing the team, adding members, removing members, and deleting the team.

You can toggle entire permission groups at once by clicking the group header, or toggle individual permissions within a group. A Reset button lets you discard unsaved changes and revert to the last saved state.

Permissions

ZeroPath uses role-based permissions at the organization level. Key permission categories include:

Category	Permissions
Issues	View, manage, mark as false positive, require context for false positives, archive
Scans	Start scans, cancel scans, view scan history
Repositories	Add, remove, configure repositories
Agent	View, manage, and run the AI AppSec Assistant
Integrations	Connect and manage Jira, Linear, Slack, Wiz
API Tokens	Create, view, delete API tokens
Patches	Generate patches, approve patches, create PRs
Settings	Manage organization settings, scanner settings
Teams	Create, edit, delete teams
Custom Reports	View, create, delete saved custom reports

Repository Access

Teams can be scoped to specific repositories. When assigning repositories to a team, you can search for repositories by name and the list supports pagination, making it easy to find the right repositories even in organizations with a large number of connected repos.

When a team is assigned to a repository:

• Team members can view scan results and findings for that repository
• Notifications and alerts are routed to the appropriate team
• Git blame attribution links findings to team members who authored the affected code

Tag-Based Repository Access

In addition to selecting individual repositories, you can grant a team access to repositories through tags. When you select a tag, the team receives the configured repository permissions on every repository that belongs to that tag. Access updates automatically as repositories join or leave the tag — there is no need to manually adjust team membership when your repository set changes.

To configure tag-based access:

1. Open a team’s settings and navigate to the Permissions panel.
2. Under Repository Access, select Selected repositories.
3. In the Tags section, select one or more tags to grant access to all repositories within those tags.
4. Save the team’s permissions.

Each tag shows the number of member repositories alongside its name. Tags that are auto-synced (membership is driven by GitHub custom properties) are labeled accordingly — team access follows automatically as the tag’s repository membership changes.

When viewing a team’s Repositories tab, any tags that have been granted to the team are displayed as read-only chips at the top of the repository list. Each chip shows the tag name, the number of repositories it contributes, and whether the tag is auto-synced. Repositories inherited through a tag cannot be individually removed — to revoke tag-based access, remove the tag from the Permissions tab instead.

Switching a team’s repository access to All repositories removes any tag-based mappings. A warning is displayed before this change takes effect.

Finding Details

When viewing a finding, ZeroPath displays contextual information to help your team triage effectively:

• Exploit steps — a step-by-step breakdown of how the vulnerability could be exploited
• Preconditions — conditions the scanner could not fully verify that may reduce exploitability. Each precondition includes a description and optional supporting evidence you can expand for more context. Preconditions help your team assess real-world risk by highlighting assumptions that must hold for the vulnerability to be exploitable.
• SCA vulnerability and reachability data — for dependency findings, package details and whether the vulnerable code path is reachable from your application
• Runtime Validation — when a finding has been tested dynamically, a Runtime Validation panel appears inline on the issue. It shows the verdict (e.g. Confirmed, Disconfirmed, or Unable), a timestamp, and a summary of the outcome. You can expand two collapsible sections for deeper detail:
  • Validated attack path / Validation path — for confirmed findings, step-by-step reproduction steps with numbered entries; for all tested findings, the sequence of agent actions and observed results.
  • Evidence and scope — a narrative summary of the evidence collected, plus the specific targets and roles that were tested. If the issue could not be tested dynamically, this section notes that testability was not possible.

Inviting Members

You can invite new members to your organization from Settings → Members. When adding invitees, you can assign each person a role — Member or Admin — at invite time, so they have the correct permissions from the moment they join. New invitees default to the Member role.

You can add invitees one at a time or switch to bulk edit mode to paste a list of email addresses separated by commas or new lines. Bulk-added emails are assigned the Member role by default; switch back to the list view to adjust individual roles before sending invitations.

If you re-enter an email address that is already in the invite list with a different role, the role is updated to reflect your latest selection.

Member Status

Organization members can be in one of the following states:

Status	Description
Active	The member has accepted their invitation and has full access based on their role.
Pending	An invitation has been sent but the member has not yet joined. Admins with invite permissions can re-send the invitation using the send icon next to the member’s name. Re-sending an invitation preserves the invitee’s assigned role, so a pending Admin is not inadvertently downgraded to Member. Pending members can also be removed to cancel the outstanding invitation.
Inactive	The member has been deprovisioned through your identity provider (SCIM). Inactive members appear with an Inactive badge and cannot have their role changed or be removed through the dashboard — they must be managed in your identity provider. This prevents accidental modifications to deprovisioned accounts while still giving admins visibility into who previously had access.

Issue Status Workflow

Findings follow a structured lifecycle that maps to team workflows. You can change a finding’s status directly from the issue detail view — status actions like marking as false positive, accepted risk, true positive, or resolved take effect immediately without a confirmation dialog, streamlining the triage process.

Status	Meaning
Pending Review	New finding, awaiting triage
Reviewing	Under active review by the team
Patching	Fix is being developed
Resolved	Fix has been applied (manually or via merged PR)
False Positive	Confirmed not a real vulnerability. Teams can optionally require that users provide a justification when marking findings as false positive (see Require Context for False Positives permission).
Accepted Risk	Known issue accepted by the team
Non-Exploitable	Technically present but not exploitable in context
Backlog	Acknowledged but deferred for later