Security Groups

Grant scoped read, write, or admin access to specific resources. Covers default groups, allow vs deny, and the resolver.

Overview

A security group is a named bundle of permissions plus a list of people. For dashboard actions wired to security-group authorization, the server resolves the member's groups together with their role baseline before it allows the action.

You manage groups on the Security groups page, reachable from the sidebar under Organisation. The Team & Security page links to it too, and has a per-member Manage groups action.

When to use

Three common scenarios:

Read-only consultant. Someone needs to look at analytics and crawlers but should never edit anything. Invite them as a member, add them to a custom group that explicitly grants read.
Locked-down admin. During a freeze you want to keep someone in the admin role but stop them from making changes. Add them to the Restricted (read-only override) group.
Delegated member management. You want one person to manage invites without giving them admin access to policy rules or settings. Add them to the Member manager group.

If your team is "everyone is an admin", you don't need to touch this page. The default groups already cover that case.

Vocabulary

Four terms used throughout this page

Role: owner, admin, or member. Set when you invite someone from the Team tab. The role gives every user a baseline of permissions (see Role baseline below).
Resource: a category of thing in the dashboard: analytics, crawlers, policy_rules, members, settings, security_groups.
Level: read, write, or admin. Higher levels include lower ones, so admin covers write and read.
Effect: allow or deny. A group permission combines a resource, an effect, and a level: for example, allow: write on policy_rules. The resolver ignores a permission whose configured expiry has passed, including an expired deny. The current Security groups editor does not provide an expiry control.

Default groups

Every organisation starts with two groups, created automatically when the organisation is created and re-created on demand if they ever go missing:

Admins: full admin on every resource. Anyone you invite as an admin (or the org owner) joins automatically.
Members: read access on analytics, crawlers, and policy rules. Anyone invited as a member joins automatically.

You can edit either default group. You can't delete them. The system identifies them by an internal tag (seed_kind: admin or seed_kind: member), not by name, so renaming them is safe but losing them is not.

Custom groups

Resources

A group can grant or deny access on any of these:

Resource	What it covers
`analytics`	Analytics permission resource. Do not rely on it to hide or gate dashboard analytics views until an analytics access check exists.
`crawlers`	Crawler whitelist changes and robots.txt monitor settings.
`policy_rules`	The full Policy rules editor.
`members`	Invite, role-change, and remove team members.
`settings`	Organisation settings, API key rotation, 2FA requirement, deletion.
`security_groups`	Create and edit security groups themselves.

Allow vs deny

A permission is one of two effects, applied at a specific level:

allow grants access at the given level. If two groups grant the same resource, the higher level wins.
deny blocks access. Deny always beats allow.

Deny is level-aware: deny: L blocks every check that requires level L or higher. The strictest deny across all the user's groups wins.

Deny	Blocks	Leaves
`deny: read`	read, write, admin (full denial)	nothing
`deny: write`	write, admin	read
`deny: admin`	admin actions only	write, read

So if you put an admin in a group with deny: write on policy_rules, they retain read access but cannot create, edit, delete, import, or reorder policy rules. deny: admin on its own is almost never what you want. It only blocks admin-level actions on a resource, for example API-key rotation on settings, and leaves regular writes intact.

`allow: read` won't lock down an admin

An admin already has admin on every resource via their role. Adding them to a group with allow: read is a no-op: the resolver picks the highest level it sees, and the role baseline (admin) is still higher.

To actually restrict an admin you need a deny rule, or the Restricted (read-only override) template below.

Pickable templates

When you click New group on the security groups page, the dialog asks for a name, a description, and a starting template. The editor opens after you create the group; you can tweak any permission from there.

Current scope and condition limitations

Groups created through the Security groups dashboard apply to all domains. The current editor does not provide controls for per-domain scope, permission expiry, or conditions. Dashboard authorization checks run at organization scope, so a domain-scoped group does not grant access to the dashboard actions documented on this page. The resolver does not evaluate conditions.

Template	What it sets
Blank	No permissions. Configure them yourself in the editor.
Read-only auditor	`allow: read` on every resource. Good for granting visibility to a non-admin. Does not restrict admins.
Restricted (read-only override)	`deny: write` on every resource. For an admin, the resolver reduces each resource to effective `read`, blocking resolver-protected write and admin operations. It also prevents that person from opening Security groups, which requires `security_groups: admin`.
Member manager	`allow: admin` on `members`.
Policy editor	`allow: write` on `policy_rules`; `allow: read` on `analytics` and `crawlers`.

Adding someone to a group

Two ways:

At invite time. On Team & Security, click Invite member. The dialog has an Additional security groups picker listing your custom groups. Membership of Admins or Members follows the role you pick, so those two are not in the list. Invitees land in the groups you tick the moment they accept.

For an existing member. Same page, click the ⋯ menu next to their name, choose Manage groups. Tick the boxes for the groups you want them in and save.

Team & Security is the single source of truth for who is in which group. The security group editor shows members as a read-only list.

Groups and roles are one thing

The two default groups and the role field are two views of the same setting, kept in sync both ways. Changing someone's role moves them between Admins and Members. Changing their groups rewrites their role: ticking Admins in Manage groups makes them an admin, and unticking it demotes them to member. The two groups are mutually exclusive.

Owners are exempt from that projection, and only an owner can edit another owner's groups. An admin also cannot demote a fellow admin this way.

How the resolver decides

When the dashboard needs to know whether a user can do something, it runs the same four steps:

Apply deny rules. Walk every group the user belongs to. For each resource, track the strictest deny level seen (lowest rank = blocks more). deny: read is the floor and blocks everything; deny: write blocks write+admin; deny: admin blocks admin only.

Apply allow rules. Walk every group again. For each resource, keep the highest allowed level, capped at one level below any deny in force. So allow: admin on a resource with deny: write ends up as effective read.

Role baseline. Raise each resource to the role's level if that is higher than what the allow rules produced. Owners and admins get admin on everything; members get read on analytics, crawlers, and policy rules. The same deny cap applies, so a deny: write here trims an admin baseline down to read. Because this raises rather than fills, an allow: read grant cannot demote an admin.

Anything still unfilled is denied.

The order matters. Deny rules cap allow rules and the role baseline. An admin with deny: write on policy_rules cannot edit policy rules; the cap brings their effective level down to read, even though their role baseline would otherwise grant admin.

Owner deny-immunity

The org owner is one exception. An owner ignores deny rules on the security_groups resource specifically. That's the bootstrap escape hatch: if an admin accidentally locks everyone out of the security groups page, the owner can still open it, remove the bad rule, and let people back in. Same idea as the AWS root user or the GitHub org owner.

The immunity is scoped to security_groups only. Owners are subject to deny on every other resource.

Centinel support staff working in an internal view bypass group permissions entirely. That path is outside your organisation's control and is not affected by anything on this page.

Every change to a group, permission, or membership is recorded with its before and after state, and shown on the Activity page. Group edits also record the role change they projected.

Examples

The blocks below show how the permissions look in the group editor. Each row is a single permission set on the resource via the editor. There's no file to paste anywhere.

Auditor with read-only visibility

A consultant needs to look at analytics and crawler data, nothing else.

Invite them as a member (not admin).
They're auto-added to the seeded Members group. That's already enough for read access on analytics, crawlers, and policy rules.
If you want the grant to be explicit (e.g. for an audit trail), add a custom group with:

Resource      Effect  Level
analytics     allow   read
crawlers      allow   read
policy_rules  allow   read

Policy editor without analytics access

Someone manages policy rules but shouldn't see traffic data.

Invite as a member.
Add to a custom group:

Resource      Effect  Level
policy_rules  allow   write
crawlers      allow   read
analytics     deny    read

The deny: read on analytics blocks the member-role read baseline. (Use deny: read to fully hide a resource; deny: write would still leave the read view visible.)

Lock an admin to read-only

You want to keep someone in the admin role but stop them from making changes during a freeze.

Keep them as admin.
Add them to a group built from the Restricted (read-only override) template:

Resource         Effect  Level
analytics        deny    write
crawlers         deny    write
policy_rules     deny    write
members          deny    write
settings         deny    write
security_groups  deny    write

They retain their admin role, but the resolver reduces their effective permission on every resource to read; resolver-protected write and admin operations are refused. Because the Security groups pages require security_groups: admin, they cannot open those pages. The owner can remove them from the group when the freeze ends.

Where enforcement runs

The resolver currently gates these server-side dashboard actions:

Action	Resource:Level required
Edit policy rules	`policy_rules: write`
Save the interstitial / blocked HTML template	`settings: write`
Edit the crawler whitelist	`crawlers: write`
Save robots.txt monitor settings	`crawlers: write`
Invite, change role, remove a member	`members: admin`
Rotate API keys	`settings: admin`
Change the organisation name or require 2FA	`settings: admin`
Request organisation deletion	`settings: admin`

Opening either Security groups page requires security_groups: admin. A user without that access is redirected away.

Common mistakes

Expecting allow: read to take admin access away. It can't. Allow rules can only grant. Use deny for downgrades.
Using the Read-only auditor template on an admin and wondering why they can still edit things. That template is allow-only. Switch to Restricted (read-only override).
Forgetting that the seeded Admins group grants admin everywhere. If you also put the same user in a restrictive group, deny will win; but if you only grant allow rules, the Admins group keeps them at admin.
Trying to lock the owner out of security_groups. You can't. The owner is always able to recover. If they're the only admin and you try to remove them from the Admins group, the action is blocked server-side.

Policy rules

The rule engine that decides which requests to allow, block, or rate-limit.

Dashboard

API keys, and where to find the security groups page.

Policy rules

Dashboard

On this page