Skip to main content
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


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 decideResponder
  • They work incidents AND decide (approve AI actions, close incidents)Commander
  • They configure sureops — models, budgets, integrations, the teamAdmin
  • They are accountable for sureops at your orgOwner (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.
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.

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


Capability reference


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 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.