> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/getting-started/users-and-sso/user-roles.md).

# User roles

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

<figure><img src="/files/uvFMlZsO9LhbKD9GBJEk" alt="The User permissions page with a role dropdown open on one row"><figcaption><p>Tenant admins assign and change user roles from Settings → User permissions.</p></figcaption></figure>

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.

## Related

* [Inviting and managing users](/getting-started/users-and-sso/inviting-users.md): the invite flow and role changes.
* [SSO and SAML](/getting-started/users-and-sso/sso-and-saml.md): how roles are assigned when users are auto-provisioned through SAML.