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 audit records have a default seven-year retention window.

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.

These are consequential capabilities, not recommendations to enable them. Assess the exact action, customer scope and controls before authorising their use.

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. Autopilot master switch (per MSP)​

Each MSP has one Autopilot master switch: the master kill switch under Autopilot Switches in the admin menu (the page comes with the Autopilot add-on). It is on unless an admin turns it off. While it is off:

  • No write the AI makes on its own runs anywhere in your workspace. Ticket triage, security response, Copilot and SOP runs (scheduled, chained or run by hand) treat every customer as Propose-only, including customers set to Full auto: each write becomes an approval card and runs only once a person approves it.
  • An MCP client's write is refused, because MCP has no approval step, and so is any SOP step that reaches a write without a recorded human approval.
  • Internal notes don't need approval (below) has no effect; internal notes need approval too.
  • Autopilot's own features (daily questions, event-driven proposals, the corrections loop, the proposal engine) pause, and the ROI page shows its enable prompt instead of figures.

Reads are never blocked, and a write a person has approved still runs. Read-only customers, Tier-4, typed confirmation and the blast-radius caps work exactly as they do with the switch on. If Ops AI cannot read the switch, it treats it as off for writes.

This is the single lever to pull if you ever want to stop the AI acting on its own.

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.

Internal notes don't need approval is an MSP-wide setting in Settings → AI Configuration, and it is on by default. While it is on, an agent's ticket note that is hidden from the customer (an Autotask note with internal visibility) is added without an approval card for Propose-only customers, the same way Full-auto customers already get it. What it does not change:

  • Read-only customers still get no writes at all, and a customer the platform cannot identify or whose mode it cannot read still fails closed.
  • Customer-visible notes and every other write still need approval on a Propose-only customer.
  • Tier-4 and always-human tools, SOP approval levels and step approvals, the blast-radius caps and the audit log all still apply. Each note added this way is recorded in the audit log as tool.internal_note_auto_applied.
  • It covers the agent's own runs (triage and Copilot). SOP graph steps and MCP clients still follow the customer's mode.

An admin can turn it off; Propose-only customers then get an approval card for every internal note again. While the Autopilot master switch is off, the setting has no effect.

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 retain their typed-confirmation requirements.

An auto-approval threshold is a minimum confidence, not a risk ceiling: on an otherwise eligible action, confidence at or above the configured threshold can clear that approval gate; confidence below it does not. Missing, malformed, boolean or non-finite confidence is treated as 0.0. An explicitly configured threshold of 0.0 also matches that fallback; it does not remove the other safety controls.

This cannot clear Tier-4 human approval, a propose-only customer's requirement, or a chain/approval-level requirement. Read-only mode, the Autopilot master switch, per-tool policy, typed confirmation, target checks and downstream execution controls still apply. An approval decision is permission to attempt an action, not proof of vendor completion.

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 — default 2557 days (at least seven calendar years). Effective retention depends on your configured period and successful retention processing; this default is not a compliance certification or contractual retention commitment.
  • 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 encrypted in the database with a separately managed encryption key; production key configuration uses Azure Key Vault. Credentials are decrypted when needed for authorised integration operations, including verification. 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.