User roles
The four user roles in Seal and the permission matrix.
Last updated
The four user roles in Seal and the permission matrix.
Seal supports four user roles, each with a distinct permission set. Tenant administrators assign a role at the time they invite a user and can change a user's role later.

The roles form a hierarchy, with each level adding capabilities on top of the one below.
Admin. Full permissions. In addition to everything a Sealer can do, an Admin controls tenant-wide settings: managing users and their roles, generating tokens, configuring SSO, enabling automatic pull requests, enabling AI features, and the rest of the tenant configuration.
Sealer. Operating permissions that can affect the actual code running in your environment. Sealers create and edit remote Sealing Rules, configure automatic pull requests, and otherwise drive the Seal CLI to apply fixes. They cannot change tenant-wide settings or manage users.
Collaborator. Operating permissions that can affect how your security posture is reported, but not the code that runs. Collaborators can scan, import data, hide packages from views, and trigger Generate fix on a vulnerable package. They cannot create Sealing Rules.
Watcher. Read-only. Watchers can view data and generate reports.
View data (the Protection page, the Repository page, etc.)
✓
✓
✓
✓
Generate reports
✓
✓
✓
✓
Import a manifest, SBOM, or Snyk export
✓
✓
✓
Hide and restore rows on the Protection page
✓
✓
✓
Create, edit, or archive a Seal Project
✓
✓
✓
Connect source control
✓
✓
✓
Trigger a scan
✓
✓
✓
Trigger Generate fix on a vulnerable package
✓
✓
✓
Create Sealing Rules
✓
✓
Configure automatic pull requests
✓
✓
Edit tenant settings
✓
Invite users and change their roles
✓
Generate tokens
✓
The Seal AI Agent runs in the context of the user who triggered it. Anything you ask the AI Agent to do is gated by your role's permissions: a Watcher cannot ask the AI Agent to create a Sealing Rule, a Collaborator cannot ask it to invite users, and so on. The AI Agent does not have its own permissions or its own role.
The Seal Engineer is a separate product with a separate permissions model: flows run on a schedule and may act outside any individual user's session. Its guardrails (what a flow can do without explicit confirmation, how per-tenant tool gating works) are covered under the Seal Engineer chapter.
Inviting and managing users: the invite flow and role changes.
SSO and SAML: how roles are assigned when users are auto-provisioned through SAML.
Last updated