For the complete documentation index, see llms.txt. This page is also available as Markdown.

User roles

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 four roles

The User permissions page with a role dropdown open on one row
Tenant admins assign and change user roles from Settings → User permissions.

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.

Permission matrix

Permission
Admin
Sealer
Collaborator
Watcher

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

Permissions and the Seal AI Agent

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.

Last updated