# Roles and permissions

> The two workspace roles in Ace, what admins and members can each do, how approval permissions work, and how people sign in and join.

Source: https://tryace.dev/docs/security/roles-and-permissions

Ace has two workspace roles. Admins control what Ace can see and do, and members follow investigations, work incidents and approve the actions an admin lets them approve.

## Roles

**Settings** > **Team** describes the roles like this:

| Role | Description in Ace |
| --- | --- |
| **Admin** | Changes settings, invites people and approves any action. |
| **Member** | Follows investigations and approves what you allow below. |

The person who creates a workspace becomes its first admin. A workspace always keeps at least one admin, so the last admin can't be demoted or removed.

## What each role can do

| | Admin | Member |
| --- | --- | --- |
| **Workspace** | | |
| View incidents, workloads and the System Map | Yes | Yes |
| Change workspace settings: name, timezone, how much Ace posts, operating rules, pausing all watches | Yes | No |
| Complete guided setup | Yes | No |
| **Team** | | |
| Invite people, revoke invites, change roles, remove members | Yes | No |
| Link teammates' Slack accounts to their Ace accounts | Yes | No |
| **Integrations** | | |
| Connect, edit, validate and disconnect integrations | Yes | No |
| Allow actions on an integration, including the AWS actions role | Yes | No |
| Choose which Slack channels Ace posts to | Yes | No |
| Create and revoke [MCP tokens](https://tryace.dev/docs/mcp) | Yes | No |
| **Workloads** | | |
| Create and rename a workload | Yes | Yes |
| Add HTTP checks | Yes | Yes |
| Mute or tune watched signals | Yes | Yes |
| Link GitHub repositories to a workload | Yes | No |
| Choose which alerts start a workload's investigations | Yes | No |
| Choose which sources Ace reads for a workload | Yes | No |
| Add or delete custom watches | Yes | No |
| Confirm which AWS resources a workload's actions may change | Yes | No |
| Delete a workload, which deletes its data | Yes | No |
| **Incidents** | | |
| Start an investigation, in Ace or from Slack | Yes | Yes |
| Investigate again, add notes, close or resolve an incident | Yes | Yes |
| **Actions** | | |
| View action policies and approval permissions | Yes | Yes |
| Approve actions that aren't production changes | Yes | Yes |
| Approve production changes | Yes | With an approval permission |
| Undo an update Ace made to an observability tool | Yes | Yes |
| Set action policies (**Off**, **Approval**, **Automatic**) and stop all actions | Yes | No |
| Grant approval permissions | Yes | No |
| Manage deployment mappings | Yes | No |

Acting from Slack, including starting investigations and approving, also needs the person's Slack account linked to their Ace account, so Ace can check their role and permissions. The person who installed Slack is linked automatically, and an admin links everyone else in **Settings** > **Team**.

## Approval permissions

In every environment, changes Ace makes through a provider count as production changes, except observability updates such as an annotation or a muted alarm. Fix pull requests and changes you report yourself count as production changes when they're in production.

Any admin can approve a production change, and so can a member with an approval permission that covers it. Any member can approve everything else.

An admin grants approval permissions in **Settings** > **Team**, or attaches them to an invite so the person can approve as soon as they join. A permission covers one or more actions, or every action, in one or more environments, or every environment. Admins don't need approval permissions because they can already approve everything.

Each member's scope is shown next to their name, for example "Approves every production action" or "Can't approve production actions".

Someone without permission who tries to approve a production change is told it needs an admin or a member with approval permission. Approval permissions decide only who may approve, while your action policy decides whether an action can run without approval. See [Actions and approvals](https://tryace.dev/docs/concepts/actions-and-approvals).

## MCP tokens

Only admins can create and revoke tokens for the [Ace MCP server](https://tryace.dev/docs/mcp), because a token is scoped to your organization and gives read-only access to all of its incidents, workloads and operating rules, whoever created it.

Tokens last 90 days by default and 365 days at most. Ace stores only a hash of each token and records which token read which incident.

## Sign-in

People sign in with **Continue with Google** or **Continue with GitHub**, and one Ace account can link both. Sessions last 7 days and renew while you use Ace.

Ace is invite-only, so a new account can be created only for an email address with a pending invite or one our team has given access to.

## Invites

1. An admin opens **Settings** > **Team**, or the **Team** step of guided setup.
2. The admin enters email addresses and chooses **Member** (the default) or **Admin**.
3. The invitee signs in with Google or GitHub, using the invited email address, and chooses to join the workspace or create a separate one.

Invites are valid for 7 days, and an admin can revoke one before it's used. Each person belongs to one workspace.

## Next steps

  - [Security and data](https://tryace.dev/docs/security/security-and-data): What Ace reads, what it keeps and how it's protected.
  - [Actions and approvals](https://tryace.dev/docs/concepts/actions-and-approvals): Action policies, approvals and earned autonomy.
  - [Ace MCP server](https://tryace.dev/docs/mcp): Create a token and connect your coding agent.
  - [Quickstart](https://tryace.dev/docs/quickstart): Set up a workspace and run your first investigation.