Roles and Permissions

Everything a person can do inside an organization comes from the roles they hold. A role is a list of permissions; a member’s access is the sum of every role they hold. There are no per-person permission switches — if two people need the same access, they get the same role.

A permission is an action on a subject

Every permission is one action applied to one subject:

Action	What it allows
Read	See it
Create	Make a new one, or run one
Update	Change an existing one, including pausing/archiving
Delete	Remove it permanently

The subjects are:

Group	Subject	Covers
Tools	Proxy search	Running and viewing proxy searches
Tools	Direct search	Running and viewing direct searches
Tools	Position tracker	Position tracking campaigns, runs, results, alerts
Tools	Ad tracker	Ad tracking campaigns, runs, results, alerts
Tools	Maps	Maps campaigns, grids, runs, results
Tools	AI visibility	AI visibility campaigns, prompts, runs, results
Tools	Data chat	Asking questions of your own data
Work	Project	Projects themselves — see the note below, it does not mean what you expect
Work	Search history	Saved searches and search activity
Team	Member	People in the organization, their roles and spending limits
Team	Invitation	Sending and withdrawing invitations
Team	Team role	Creating and editing the organization’s own roles
Team	Team settings	Organization name, logo, defaults; Delete removes the organization
Team	API key	Creating and revoking API keys
Team	Billing	Plan, invoices, payment method, token top-ups

Each tool is its own subject, so “may use Maps, nothing else” is expressible. Restricting a tool removes it from the sidebar and refuses its endpoints; it does not hide the rest of the product.

Read on Project means every project

Project: Read is the one permission that does not mean “may open the projects page”. It means this person sees every project in the organization, which switches off project-level access for them entirely.

Everyone can open the projects page and work in the projects they can see — that comes from being a member, not from this permission. Leave Project: Read off for any role that should be limited to assigned projects. Owner and Admin hold it deliberately.

The built-in roles

Every organization starts with three roles it cannot edit or delete:

Role	Access
Owner	Everything, including billing and deleting the organization
Admin	Everything except deleting the organization; full team management
Member	Runs every tool, creates and edits projects and searches, read-only view of the team, own API keys

The Member seat has two deliberate gaps, and both are the point of the seat:

No Project: Read. Read means “every project in the organization”, so granting it would make project restriction a no-op for the default seat — the Access dialog would appear to work and do nothing. Without it a member still sees every unrestricted project plus the ones they are assigned to.

No Delete, anywhere except their own API keys. A member could otherwise run a campaign and then delete it, or delete the project it lived in, taking a colleague’s history with it. Creating and editing is the job; removing is an administrative act. They also cannot send invitations — deciding who is in the organization is administration however small it looks.

An organization that wants a looser member layers a team-authored role on top; that is what those are for.

Keep more than one Owner. The last Owner cannot be demoted or removed, so a single-owner organization is one lost account away from having nobody who can manage billing.

Building your own role

Owners and admins can create roles for their organization under Settings → Team → Roles. Start from a template or tick the matrix yourself, name it, and assign it to people from the Members list.

Three starting points are offered:

• Search only — proxy search and direct search, read-only history, nothing else.
• Read-only — read on every tool, no creating, no deleting.
• No AI tools — everything except AI visibility and data chat.

A worked example — a member who may run searches but must not delete anything or start a token-consuming campaign:

1. Settings → Team → Roles → New role, name it Search only.
2. Tick Read and Create for Proxy search and Direct search.
3. Tick Read for Search history.
4. Leave everything else empty — including Project: Read.
5. Save, then open Members, choose the person, Edit roles, tick Search only and untick the others.

Their sidebar now shows only the two search tools. Deleting a project, archiving a campaign or starting a tracker all return “not allowed”, and the tools they cannot use show only campaigns that have been shared publicly.

Rules the editor enforces

• You cannot create a role more powerful than you are. Every permission you tick must be one you hold yourself. An admin cannot mint an owner-level role and assign it to themselves.
• You cannot rewrite or delete a role that grants more than you hold — including narrowing it. Otherwise an admin could quietly strip an owner by editing the role the owner depends on.
• You cannot reshape someone more powerful than you. An admin cannot change an owner’s roles or spending limits.
• Built-in roles are read-only, and roles belong to one organization — you will never see or touch another organization’s roles.
• How many roles you may create depends on your plan. Deleting one frees a slot.

Removing access takes effect within a minute

Permissions are cached briefly for speed. A role change reaches every open session within about a minute — usually immediately. Signing the person out and back in applies it at once.

Denials

A permission can be a denial instead of a grant — “cannot delete Billing”. A denial always wins over a grant from another role, so it is the way to carve an exception out of an otherwise broad role without cloning it.

Denials count as power in reverse: removing one gives access back, so the editor requires you to hold the underlying permission before you can delete or rewrite a role that contains one.

API keys

An API key carries its own permission list, and it can never exceed the permissions of the person who created it. A member restricted to proxy search cannot mint a key that runs campaigns.

Keys act as the organization, not as a person: project restrictions and per-member spending limits do not apply to them. Treat a key as an organization-wide credential —

• one key per integration, never a shared key,
• the smallest permission set that does the job,
• revoke rather than reuse when an integration is retired.

See Authentication and API keys.

MCP connections

An MCP connection is bounded by both what you approved at connect time and your live role permissions, re-checked on every call. Reduce someone’s role and their agent’s access shrinks on the next request, with no re-consent needed.

Troubleshooting

“I removed a tool from their role but they can still see the data.” Check whether they hold the tool through a second role — access is the sum of all roles. The Members list shows every role a person holds.

“I restricted a project and nothing happened.” The people who still see it hold Project: Read through one of their roles — the Access dialog marks them “Sees all projects”. Owners and admins always do.

“They cannot open a tool I did not restrict.” Tools are also gated by your plan. A tool nobody in the organization can open is a plan question, not a permissions one — check Settings → Billing.

“An admin cannot edit a role they can see.” That role grants something the admin does not hold. An owner has to make the change.