Permissions

The full permission catalog, the built-in team permission sets, and the defaults applied to new firewalls.

Permissions are verbs evaluated in a context: a namespace-level permission such as fw:create applies in the namespace, a firewall-level one such as fw:update:rule applies to a specific firewall through its grants. For how the levels combine, see Access and permissions.

Catalog

Namespace

Permission	Allows
`ns:access`	Any use of the namespace API; the baseline everything else builds on
`ns:update`	Rename the namespace and update its metadata
`ns:delete`	Delete the namespace
`ns:create:pat`	Create Personal Access Tokens
`ns:create:service-token`	Create Service Access Tokens
`ns:update:licenses`	Create, update, and delete license sets. Reading them only needs `ns:access`
`ns:update:webhooks`	Create, update, delete, and test webhooks. Reading them and their deliveries only needs `ns:access`

Creating a namespace is not permission-gated: it requires the tenant admin or owner role on the session, so no team grant can enable it.

Teams

Permission	Allows
`team:read`	List teams and read team details
`team:update`	Change a team's name, description, and permissions
`team:delete`	Delete a team
`team:update:membership`	Add and remove team members

Firewalls

Permission	Allows
`fw:access`	Package traffic through the firewall (install, publish)
`fw:create`	Create a firewall in the namespace
`fw:clone`	Create a firewall from an existing one as template
`fw:read`	Read configuration, rules, and exceptions
`fw:update:config`	Update configuration such as upstreams
`fw:update:credentials`	Update upstream credentials
`fw:update:rule`	Change rules
`fw:update:exception`	Change exceptions
`fw:delete`	Delete the firewall

Built-in team sets

Every namespace has two protected teams that cannot be updated or deleted.

everybody (all users):

ns:access, ns:create:pat, team:read, fw:create, fw:access, fw:clone, fw:read

admin (everybody's set plus):

ns:update, ns:delete, ns:create:service-token, ns:update:licenses, ns:update:webhooks, team:update, team:delete, team:update:membership, fw:update:config, fw:update:credentials, fw:update:rule, fw:update:exception, fw:delete

Assignable to custom teams

Custom teams can be granted:

ns:access, ns:update, ns:delete, ns:create:pat, ns:create:service-token, ns:update:licenses, ns:update:webhooks, fw:access, fw:create, fw:clone, fw:read, fw:update:config, fw:update:credentials, fw:update:rule, fw:update:exception, fw:delete

Team-management permissions (team:* beyond read) stay with the admin team.

Available to Service Access Tokens

A SAT can carry at most:

ns:access, ns:update, fw:access, fw:create, fw:clone, fw:read, fw:update:config, fw:update:rule, fw:update:exception

Notably absent: namespace and firewall deletion, credential updates, team and token management. Those actions require a person.

Defaults for a new firewall

A firewall created without an explicit permissions map gets the default grants:

Team	Permissions on the new firewall
`everybody`	`fw:access`, `fw:clone`, `fw:read`
Owner team	`fw:access`, `fw:clone`, `fw:read`, `fw:update:config`, `fw:update:credentials`, `fw:update:rule`, `fw:update:exception`, `fw:delete`

The owner team is the owner named in the create request (API); without one, the full set goes to everybody, which is also the dashboard's default. A create request carrying an explicit permissions map is stored verbatim, so exported configs import unchanged.

Lockout guard

The server rejects (400) saving a firewall permissions map that would make the firewall unmanageable:

The resulting map must grant fw:update:config to at least one team.
A user cannot remove their own team's fw:update:config grant; handing over management works by granting another team first, then having that team drop yours.

The guard runs on create, update, and rollback, and only when the permissions map actually changes, so tokens restricted to rule updates can keep re-applying full configs with an unchanged map.

Service Access Tokens are exempt from the self-lockout rule: their fw:update:config grant comes from the token, not from the team map being edited, so a map change cannot lock them out.

Permissions

On this page