Security groups

Grant scoped read, write, or admin access on specific resources to your team. Covers default groups, templates, allow vs deny semantics, and how the resolver decides what each member can do.

A security group is a named bundle of permissions plus a list of people. When someone in the group does something in the dashboard (or hits the API), the validator looks at the group's permissions and decides whether to allow it.

You manage groups on the Security groups page. There's a shortcut from the Organisation page and a per-member Manage groups action on the Team tab.

When to use security groups

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 as an admin (so they show in the admin list, get notifications) but stop them 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: e.g. allow: write on policy_rules.

The resources

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

Resource	What it covers
`analytics`	Dashboard analytics, traffic charts, drill-downs.
`crawlers`	Crawler whitelist, robots.txt sync settings, per-crawler policy.
`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.

Default groups

Every organisation starts with two groups that are created automatically:

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.

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 can still see the policy rules page but every save returns a 403. deny: admin on its own is almost never what you want; it only blocks admin-level actions on a resource (e.g. "rotate API keys" 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.

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. The only template that locks an admin to read-only (write/admin blocked, read intact).
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 the Team tab (under Organisation), click Invite member. The dialog has an "Add to security groups" picker: tick the boxes you want and send. They land in those groups the moment they accept.

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

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

How the resolver decides

When the validator or 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. For any resource that still has no level: 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.

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.

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 as an admin (so they show in the admin list and get admin-only notifications) but stop them 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 keep their role and can still see every page, but every save returns a 403. The owner can remove them from the group when the freeze ends.

Where enforcement runs

The same resolver gates every server-side mutation the dashboard performs:

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`

The same checks back the page-level redirects, so a member who lacks security_groups: admin can't even open the security groups page.

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, protected endpoints, and where to find the security groups page.

Policy rules

Dashboard

On this page