> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sureops.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles & capabilities

> Five roles from Observer to Owner — what each can do, and how to pick the right one

sureops has five roles, ordered from least to most privileged: **Observer → Responder → Commander → Admin → Owner**. Default new members to the least role they need — it's the most effective way to keep your deployment secure.

***

## At a glance

| Capability                                    | Observer | Responder | Commander | Admin | Owner |
| --------------------------------------------- | :------: | :-------: | :-------: | :---: | :---: |
| View incidents, settings, reports             |     ✓    |     ✓     |     ✓     |   ✓   |   ✓   |
| Create & update incidents                     |          |     ✓     |     ✓     |   ✓   |   ✓   |
| Run agents manually                           |          |     ✓     |     ✓     |   ✓   |   ✓   |
| Edit problem records & sync to tracker        |          |     ✓     |     ✓     |   ✓   |   ✓   |
| Approve agent actions (HITL)                  |          |           |     ✓     |   ✓   |   ✓   |
| Transition stages, force-close incidents      |          |           |     ✓     |   ✓   |   ✓   |
| Edit settings (models, budgets, integrations) |          |           |           |   ✓   |   ✓   |
| Manage team (invite, edit, remove)            |          |           |           |   ✓   |   ✓   |
| Read audit log                                |          |           |           |   ✓   |   ✓   |
| Transfer ownership                            |          |           |           |       |   ✓   |

***

## Role reference

### Observer

**Who this is for.** Reviewers, auditors, PMs, and execs who need visibility without operational authority.

Observers can see everything — incidents, problems, dashboards, reports, and settings — but cannot change anything. They cannot run agents or act on incidents.

**Example:** a VP of Engineering checking MTTR weekly; a PM reviewing which services cause the most incidents; an auditor verifying controls.

***

### Responder

**Who this is for.** On-call engineers who work incidents directly.

Responders can create new incidents, update in-flight ones, trigger agent tasks, and edit problem records. They cannot approve agent actions that require human judgment (that is Commander) and they cannot change settings.

**Example:** an on-call engineer running playbooks, adding context to a live incident, kicking off a diagnostic agent.

***

### Commander

**Who this is for.** Senior on-call engineers who make incident-command decisions.

Commanders do everything a Responder does, plus:

* Approve or deny agent actions that need human judgment (HITL)
* Transition incidents between stages (diagnosis → resolution → verification → closure)
* Force-close or escalate incidents
* Override stage routing

Commanders cannot edit org settings — configuration is an Admin concern.

**Example:** a senior on-call deciding whether an agent's proposed mitigation is safe to apply; an incident lead coordinating response.

***

### Admin

**Who this is for.** Operators responsible for how sureops runs at your organization.

Admins configure everything: LLM providers and budgets, agent models and skills, integrations, notification routing, runbooks. They also manage the team — invite members, change roles, remove people — and can read the audit log.

Admins cannot transfer organization ownership; only the Owner can do that.

**Example:** a platform engineer owning the sureops deployment; an SRE lead tuning agent behavior.

***

### Owner

**Who this is for.** The person accountable for the org's use of sureops. Exactly one per org.

The Owner can do everything an Admin can, plus transfer ownership to another member. Ownership transfer is **irreversible** — the moment you promote someone else, you become the previous role (typically Admin) and they become the accountable party.

**Example:** the person who signed up the org, or the engineering leader who has been formally handed accountability.

***

## Choosing the right role

A quick decision tree:

* **They watch but don't act** (PM, VP, auditor) → **Observer**
* **They work incidents on-call but don't decide** → **Responder**
* **They work incidents AND decide (approve AI actions, close incidents)** → **Commander**
* **They configure sureops — models, budgets, integrations, the team** → **Admin**
* **They are accountable for sureops at your org** → **Owner** (exactly one; transfer carefully)

When in doubt, **default to the least-privileged role and upgrade on request**. The person will tell you when they need more.

***

## Security properties

### Least privilege by default

New members default to **Observer** unless you explicitly select a higher role at invite time. sureops will never implicitly grant a higher role based on activity.

### Exactly one Owner per org

There is always one — and only one — Owner. If the Owner leaves the organization, transfer ownership before they lose access. There is no self-service owner recovery flow; contact sureops support if this happens unexpectedly.

<Tip>
  Pre-identify a designated backup Owner before your current Owner needs to hand off. Transfer when the timing makes sense — don't wait until it's an emergency.
</Tip>

### Immediate revocation

Role changes take effect on the affected user's **next request** — not at their next login, not when their session expires. This matters during incident response: if you suspect a compromised account, demote it to Observer from **Settings → Team → Edit**. The change lands before their next click.

### Audited role changes

Every role change — invite, promote, demote, remove — writes an audit log entry with actor, target, old role, new role, and timestamp. Admins can read the audit log in **Settings → Audit**.

***

## What happens during a role change

| Action                        | Effective when                            | Visible to affected user                                 |
| ----------------------------- | ----------------------------------------- | -------------------------------------------------------- |
| Invite new member             | Immediately after they accept             | They receive an invite email; role is set at first login |
| Edit role (promote or demote) | Immediately on their next request         | No automatic notification — you should tell them         |
| Remove member                 | Immediately on their next request         | They see a "no access" page on next page load            |
| Transfer ownership            | Immediately (both parties simultaneously) | Both parties see their new role on next settings refresh |

***

## Capability reference

| Capability                | What it grants                                  | Granted to              |
| ------------------------- | ----------------------------------------------- | ----------------------- |
| `settings:read`           | View settings surfaces                          | Observer and above      |
| `settings:write`          | Edit org / environment / agent settings         | Admin, Owner            |
| `team:manage`             | Invite, remove, change member roles             | Admin, Owner            |
| `team:transfer-ownership` | Promote another member to Owner                 | Owner                   |
| `approvals:grant`         | Approve or deny HITL agent actions              | Commander, Admin, Owner |
| `agents:execute`          | Trigger agent tasks manually                    | Responder and above     |
| `incidents:act`           | Create and update incidents; add context        | Responder and above     |
| `incidents:command`       | Transition stages, force-close, escalate        | Commander, Admin, Owner |
| `problems:write`          | Edit problem records; sync to external trackers | Responder and above     |
| `audit:read`              | Read the organization's audit log               | Admin, Owner            |

***

## Frequently asked questions

**Can a user see another organization's data?**

No. sureops is strictly multi-tenant — every database table uses row-level security scoped to the organization. No customer user can access another org's data.

**Can I create a custom role?**

Not yet. sureops ships five fixed roles today; custom role bundles are on the roadmap. If the current roles don't fit your team structure, [let us know](https://github.com/sureops-public/sureops/discussions) what you are trying to express.

**What if the Owner leaves without transferring?**

Contact sureops support. We can escalate ownership through an out-of-band process requiring verification of your org's accountable party. Much easier to transfer before they leave.

**Do these roles apply to agent tool access?**

Partially. Agents run with your organization's credentials and have their own permission surface (which tools they can call). Human roles control *who can change what the agents do*. Agent tool access is configured under **Settings → AI Agents**.

***

## Related

* [Team management](/next/administration/team-management) — how to invite, edit roles, and remove members
* [Notifications](/next/administration/notifications) — route alerts and approvals to the right people