# Roles and permissions (/en/docs/platform/team/roles-and-permissions)



CentralCSP has two role systems that work independently. Mixing them up is the most common source of confusion about who can do what.

**Workspace roles** decide who administers the account. **Website roles** decide what someone can do on one particular site.

## Workspace roles [#workspace-roles]

There are three workspace roles, and only two of them can be assigned:

| Role       | Can do                                                                                             |
| ---------- | -------------------------------------------------------------------------------------------------- |
| **Owner**  | Everything, plus billing, ownership transfer, deleting the workspace, and granting the Admin role  |
| **Admin**  | Create websites, manage members, groups, invitations, API keys, audit logs, and workspace settings |
| **Member** | Read the workspace and its member list, plus whatever websites they are granted                    |

**Owner** is not a role you assign. There is exactly one per workspace, and it moves only through **Transfer ownership** under **Settings** > **General**.

Only the Owner can invite or promote someone to Admin. An Admin can invite Members but not other Admins.

## Website roles [#website-roles]

There are four website roles, and each one includes the permissions of the roles before it:

| Role        | Adds                                                                                                     |
| ----------- | -------------------------------------------------------------------------------------------------------- |
| **Viewer**  | Read reports, settings, script inventory, and alerts, and export the inventory CSV and the evidence pack |
| **Analyst** | Decide on scripts under review, justify or reject                                                        |
| **Manager** | Change the website's configuration, ingestion, alerts, tags, rules, and payment pages                    |
| **Admin**   | Manage access to the site and delete it                                                                  |

The **Viewer to Analyst** boundary is the important one. PCI DSS script review is an approval decision with an audit trail, so Analyst is the lowest role that can justify or reject. Give it to the people who own that judgement and leave everyone else on Viewer.

The **Manager to Admin** boundary separates configuring a site from controlling who else reaches it.

## How the two connect [#how-the-two-connect]

Two rules cover every case.

<Callout type="warn" title="Workspace admins reach every website">
  Workspace Owners and Admins are automatically website Admin on every site, and you cannot reduce that by leaving them off an access list. If someone must be restricted to certain sites, they have to be a workspace **Member**.
</Callout>

**Everyone else gets the highest role they hold.** A direct Viewer grant plus membership of a group with Manager makes someone a Manager. When revoking, check both the People and Groups lists on the website, or the access will survive through the path you did not look at.

## Access patterns for a team [#access-patterns-for-a-team]

A shape that works for most organizations:

| Who                                        | Workspace role | Website access                                          |
| ------------------------------------------ | -------------- | ------------------------------------------------------- |
| **Platform or security lead**              | Admin          | Automatic everywhere                                    |
| **Developers**                             | Member         | Manager on their own services                           |
| **Compliance or audit**                    | Member         | Analyst on payment-facing sites, Viewer elsewhere       |
| **Executives, auditors**                   | Member         | Viewer, via a group                                     |
| **Continuous integration and other tools** | Not a member   | Use an API key created by someone with the right access |

Grant through [groups](/en/docs/platform/team/groups) rather than per person once you pass a handful of people. Per-person grants across a dozen sites become impossible to audit.

## API key inheritance [#api-key-inheritance]

An API key acts as the person who created it, with that person's current roles, and is limited to one workspace. There are no per-key scopes.

So a key created by a workspace Admin can reach every website. Create keys from an account with the narrowest access that still does the job. For more information, refer to [API keys](/en/docs/platform/integrations/api-keys).

## Next steps [#next-steps]

* [Members](/en/docs/platform/team/members)
* [Groups](/en/docs/platform/team/groups)
* [Website access](/en/docs/platform/team/website-access)