Roles & access
Access is role-based and cumulative — each role can do everything the one below it can, plus more.
| Role | May do |
|---|---|
| viewer | Read everything non-secret: dashboards, systems, incidents, signals, audit log, agent runs. |
| responder | viewer + run published playbooks on matched incidents, resolve them afterwards, record notes. |
| operator | responder + trigger syncs and analyses, manage incidents, propose changes, execute T0 and policy-enabled T1 actions. |
| approver | operator + approve or reject T2 and T3 proposed changes — never their own. |
| admin | approver + manage integrations and credentials, risk policy, model configuration, and role mapping. |
The responder rung exists for the service-desk pattern: someone who can run the standard fix without being able to author one or approve anything else. The guided incident page is that role’s entire surface.
Enforcement is at the API, on every route. The UI hides what your role cannot do, but the API is the authority — hiding a button is a convenience, not a control.
Signing in
Section titled “Signing in”Primary authentication is Microsoft Entra ID via OIDC (Authorization Code + PKCE). ISE holds no primary user credentials.
Roles map from Entra group membership. Access is granted and revoked by changing group membership in Entra, where your joiners-movers-leavers process already lives — ISE’s user table is a mirror plus an audit anchor. After sign-in, ISE issues its own short-lived session tokens; the frontend never handles Entra tokens directly.
Break-glass
Section titled “Break-glass”Entra ID is also a system ISE manages — which means SSO-only sign-in would lock you out of the tool you need exactly when Entra is the incident you’re working.
So one break-glass local admin account exists outside Entra: credentials stored as a strong hash, configured as a secret, with no password-reset flow. Every break-glass login raises a prominent audit event and an alert. It is for Entra-outage use only, should be verified periodically, and is never used day to day. It is a standing risk accepted deliberately, and mitigated by making it impossible to use quietly.
Separation of duties
Section titled “Separation of duties”For T2 and T3, proposer ≠ approver is enforced in the approval state machine, not by convention. This is what makes AI-drafted remediation safe: an AI proposal is a request, and the AI has no approve capability at all.
For playbooks, separation of duties sits at publish time instead — a second engineer who is not the sole author publishes, and every later execution inherits that approval.
In a small team, self-approval is allowed only for admin, and it is distinctly audited
as such so it stands out in review rather than blending in.
AI containment
Section titled “AI containment”Agents get allow-listed, read-only tools. Proposal-drafting agents see action descriptions — they never reach execution. The assist surface is the widest, since it reads the whole estate on free-text input, so its read-only guarantee is backed by mechanism rather than convention: every assist tool runs inside a read-only database transaction and cannot write, whatever it calls.
That bound is what makes prompt injection from target-system content survivable. A poisoned agent’s worst case is proposing a change a human then reviews, or acting inside the narrow T0/T1 auto-band — which is exactly why that band stays narrow and reversible. Read-only is not the same as harmless: injection can still make an answer wrong. It cannot make ISE act.
Streamed output is redacted as it flows, accumulated and scrubbed as a whole rather than per chunk, so a secret split across two fragments cannot slip through to the browser.
- Audit trail — what gets recorded, and credential handling.
- Actions & approvals — the tiers these roles act on.
- Installation — configuring Entra and break-glass.