Actions & approvals

Every change ISE can make to a target system is a declared operation in that connector’s action catalogue, classified up front with a risk tier, expected effect, and reversibility note. An operation that isn’t in the catalogue cannot be invoked — not by you, not by the UI, not by any prompt.

The tiers

The tier is a property of the operation on that system, declared by the connector author — never decided at runtime by a model.

Tier	Meaning	Examples	Handling
T0 — Safe	Reversible, no config change	Acknowledge an alert, re-run a check	Auto-applies where policy allows; audited
T1 — Low	Reversible, bounded blast radius	Restart a deployment, start a VM, purge specific cache URLs, write a tag	Auto-applies only if the integration’s policy opts in; otherwise queued for approval
T2 — Sensitive	Config change, or hard to reverse	Edit a monitor, update a DNS record, stop an instance, modify a Kubernetes resource	Always requires human approval
T3 — Critical	Identity, security posture, destructive	Every Entra ID write, deletions	Always requires an approver or admin, and the proposer cannot approve their own change

Each integration page lists its own catalogue with the tier of every operation.

Default-deny

An absent or empty policy auto-applies nothing. Every mutation, at every tier, queues for a human until someone deliberately opts in — the permissive path is never the one you get by doing nothing.

Auto-apply can only ever be enabled for T0 and T1. A policy asking to auto-apply T2 or T3 is ignored, because “always requires human approval” is not a default that configuration gets to override.

Per-integration policy may raise an operation’s effective tier or disable auto-apply entirely. It can never lower a declared tier: the connector author’s classification is a floor. An override attempting to lower one is ignored rather than honoured — and deliberately not treated as an error either, because a misconfigured policy must fail safe, and the safe direction is the stricter one. A typo can never produce an unclassified mutation.

Protected targets

Approval asks “should this happen?” It does not ask “should this be possible?” An approver looking at a plausible delete_resource on the ise namespace — sound rationale, real evidence — has no way to know they are about to delete the platform they are clicking in.

So each system carries protected targets: a deny-list on which no operation may run, regardless of tier and regardless of approval. It is not an approval failure; it is the statement that nobody has this permission, and an approver cannot click past it. The guard runs inside the connector’s action path itself, so no caller — including future ones and auto-apply paths — can forget to invoke it. Which parameters count as “the target” is declared by the connector, not guessed.

New systems are seeded with the namespaces where a mistake takes down the thing that would have to fix it.

Separation of duties

At the higher tiers the proposer cannot approve their own change. This is what makes AI-drafted remediation safe to allow: an AI proposal is just a request, and the AI has no approve capability at all — not as a matter of prompting, but because the function isn’t in its toolset.

For playbooks, separation of duties moves to publish time — a second engineer signs off once, and the approval is then spent for every execution.

Credentials are split

Every integration keeps read and write credentials separate. You can run any integration read-only indefinitely; enabling actions is a deliberate second step that grants a second, write-capable identity. Credentials are encrypted at rest and redacted from logs, and the write identity is scoped to exactly the catalogue’s operations — several connectors enforce a forbidden-permission invariant so an over-broad credential is rejected rather than quietly accepted.

Execution is deterministic and truthful

Once approved, execution runs the exact approved parameters through the connector, with no model in the loop. Long-running operations are polled to completion: an action reports success when the target system says it finished, not when it accepted the request. Failures are captured with their error and never silently retried unless the operation is provably idempotent.

Every step — proposed, approved, rejected, executed, failed — lands in the append-only audit trail.

Next

• Proposals — this model as you actually meet it on screen.
• Playbooks — pre-approved response for known fixes.
• Roles & access — who may propose, approve, and administer.