Skip to main content

How Ops AI governs AI actions

Ops AI can do real work in your customers' systems — update tickets, reset a password, change a subscription, isolate an endpoint. The reason you can hand it real customers is that it can't do much on its own. Every write the AI is capable of runs through a stack of independent controls, most of which are off or require a human by default. This page explains, honestly, what the AI can write to and exactly how each write is governed.

If you only remember one sentence: on a new customer the AI drafts and you approve every write; the genuinely dangerous operations can never run without a human clicking Approve; a runaway agent auto-halts after a handful of writes; reversible Microsoft 365 changes have one-click undo; and everything is logged for seven years.

What the AI can write to​

We'd rather tell you the full write surface than imply the AI is read-only when it isn't. Every integration's write-capable tools are enumerated exactly on the per-vendor setup page; the ones worth naming here:

VendorNotable writes
Autotask (PSA)Update / create / close tickets, add notes, log time entries, create tasks, contacts, and configuration items.
Microsoft 365 / CSPCreate / disable / delete users, reset passwords, assign/revoke licences, add/remove group members, clear MFA methods; wipe / retire Intune devices; create/update/delete Conditional Access policies; create/delete Teams and channels; assign/remove directory roles.
IT GlueCreate / update / archive documents, configurations, contacts, and flexible assets — including the password vault: create, update, and archive passwords, and read a password in plaintext (a plaintext read is gated exactly like a write).
Pax8Change a subscription's seat quantity, cancel a subscription, place an order, update companies and contacts (real billing impact).
Datto RMMReboot / shut down / restart / wake devices, run scripts and jobs, isolate a device, mute or resolve alerts.
Datto EDRIsolate / release endpoints, release quarantined files, mark false positives, manage incidents, create IOCs, suppress threats.
UniFiBlock / unblock clients, restart APs / switches / gateways, create / update WLANs and networks, create/update/delete firewall and port-forward rules, issue guest vouchers.

Yes — that includes password-vault writes and device wipes. Read on for why that's safe to enable.

The write-safety stack​

Every write is checked against these controls, in order. A write only applies if it clears all of them; failing any one blocks or pauses it.

1. Global kill-switch (per MSP)​

Each MSP has a master automation switch. With it off, the AI can still read and propose, but no autonomous write executes anywhere in your workspace. This is the single lever to pull if you ever want to stop everything.

2. Per-customer autonomy mode​

Autonomy is set per customer, on the Customer Mapping page, so a long-standing SMB can run more freely while a regulated client or a customer mid-migration stays locked down. There are three modes:

  • Read-only — every write against this customer is blocked outright. The AI can read and suggest, never change anything.
  • Propose-only — this is the default for every new customer. The AI drafts the write and routes it to the Approvals queue; a human approves or rejects before anything happens. Nothing applies autonomously.
  • Full-auto — the AI may apply writes without a per-action approval, but only after clearing every remaining gate below (Tier-4, blast-radius, per-tool policy). Full-auto is opt-in, one customer at a time.

If the platform can't confirm a customer's mode (for example during a transient database hiccup), it fails closed and blocks the write rather than risk applying it to a read-only customer.

3. Draft-then-apply​

Sensitive tools can only draft a change. The draft and the live apply are two distinct steps, so a write can never be a silent side-effect of the AI "thinking out loud" — there is always a discrete apply action to gate and to log.

4. Tier-4 — human-only, no exceptions​

A small set of irreversible or lockout-class operations is Tier-4: the AI may draft and propose one, but it can never auto-execute it, even in full-auto, even with a double-confirm token. The only thing that releases a Tier-4 write is a human clicking Approve, which mints a single-use, cryptographically signed (HMAC) token bound to the MSP, the exact tool, and the exact arguments, with a 15-minute expiry. If the token store is unavailable, the mint fails and the action stays pending (fail-closed).

The Tier-4 set:

  • csp_wipe_device, csp_retire_device — factory-reset / unenrol a device.
  • m365_delete_user — hard-delete a user.
  • Create / update / delete a Conditional Access policy — a bad CA policy can lock every admin out of the tenant.
  • Delete a Team or channel — takes the backing group, mailbox, and SharePoint site with it.
  • Assign / remove a directory role — granting Global Administrator hands over the whole tenant; removing the wrong role locks an admin out.

5. Blast-radius circuit breaker​

To bound the worst case from a looping or mis-prompted agent, each run has write caps: 10 writes per run and 25 writes per customer per rolling hour (both tunable per MSP). Breach either cap and the run halts with status halted_blast_radius, its partial progress is preserved, and resuming requires an explicit human acknowledgement.

6. Per-tool policy, typed confirmation, and auto-approval threshold​

Individual destructive tools require a typed confirmation before they'll apply. Separately, each MSP sets an auto-approval threshold in AI Config: writes the agent judges below the threshold can proceed on a full-auto customer, while anything at or above it is surfaced for human review regardless.

7. Full audit trail​

Every privileged action — by a human or an agent — lands in the append-only Audit Log: who (or which agent), what tool, what arguments, and the outcome. Entries can never be edited or deleted from the UI, and a CI meta-test statically verifies that every admin mutation endpoint writes an audit row, so new administrative actions can't ship without logging.

One-click Microsoft 365 undo​

For the reversible Microsoft 365 changes (the ones where a clean inverse exists), Ops AI captures the before-state at the moment the write runs, so you can revert it in one click from the agent run. The capture is conservative and best-effort: if it can't safely record enough to reverse an operation, that operation is simply marked non-undoable rather than offering a revert that might do the wrong thing. Irreversible operations (the Tier-4 set above) are never eligible for undo — which is exactly why they're human-only in the first place.

How long the record is kept​

  • Audit log — retained for 7 years, for your compliance posture.
  • Agent-run history and raw webhook payloads — retained for 90 days (decision traces are configurable).

Autopilot​

Autopilot is a paid add-on that turns on the proposal engine and the knowledge-capture and automation features on top of your base plan. It's the thing that watches your tickets and proposes work; it does not change the safety model above — Autopilot proposals land in exactly the same Approvals queue and are subject to the same autonomy modes, Tier-4 gate, and blast-radius caps as any other write.

Pricing. The add-on is priced flat per MSP — not per seat — billed monthly, cancel anytime. See the pricing page for the current, authoritative rates.

Data handling. AI inference runs on Azure OpenAI, which does not train on your inputs. Your tickets, customers, SOPs, and decision traces never enter a training set. Integration credentials are held in Azure Key Vault, separate from the database, and decrypted only at call time. Tenant data is isolated at the row level so one MSP can never see another's. For the full platform data-handling statement, see the security page.