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 become Owner or change who holds that role — that’s not something any role can do through the app; see Owner below.
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. sureops doesn’t offer a self-service way to transfer ownership to another member — the role editor is deliberately structured so no role change can promote someone to Owner. If your Owner needs to change (they’re leaving the organization, or accountability needs to move to someone else), contact sureops support for a verified ownership change.
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; changing who holds it requires sureops support)
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 Responder unless you explicitly select a different 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, and there’s no self-service way to change who holds it — the role editor is deliberately structured so no role change can promote someone to Owner or alter one. If the Owner is leaving the organization or accountability needs to move to someone else, contact sureops support before they lose access; support can walk you through a verified ownership change.
Pre-identify who should become the next Owner before your current Owner needs to hand off, so the support-assisted change is quick when the time comes — don’t wait until it’s an emergency.
Role change timing
Role changes take effect on the affected user’s next token refresh or next sign-in — not on their very next request. Role is a claim baked into the session JWT at issuance, so a request made with an already-issued token still carries the old role until that token is refreshed or reissued. The change is written to the database and audited immediately, but an already-signed-in user does not lose or gain access mid-session just because the row changed underneath them.
This matters for incident response: if you suspect a compromised account, demoting it to Observer from Settings → Team → Edit does not cut off in-flight access immediately — their current session keeps working under the old role until their token refreshes or they sign in again. Don’t treat a role demotion alone as having ended a compromised session; pair it with whatever other containment steps your incident response process calls for (for example, rotating credentials the account had access to).
Audited role changes
Every role change — invite, promote, demote, remove — writes an audit log entry with actor, target, old role, new role, and timestamp. There is no in-app audit log viewer today; Admins and Owners can retrieve the audit log via the API (GET /api/v1/audit-logs) or by asking sureops support for a report.
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. The primary enforcement point is application code: every query the backend issues is scoped to your organization explicitly, either as a filter on the query itself or as an ownership check performed before the request is allowed to read or write the record. PostgreSQL row-level security policies do exist on these tables, but they’re a secondary layer that applies to a database session connecting directly with your own credentials — not a substitute for the application-level org-scoping, since the backend API itself connects with elevated, RLS-bypassing credentials. 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 the organization?
Contact sureops support. There’s no self-service way to reassign the Owner role — support can walk you through a verified ownership change through an out-of-band process that confirms your org’s accountable party. Easier to start that process before the current Owner loses access than after.
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.
