Leadership brief · one page

Guarded Automation: Agents That Run Operations

AI Assurance wrote the deployment addendum for MU-AI-011 (the proposed crew-dispatch agent at Meridian, the fictional utility every training in this sequence follows) and said "not yet" — it left NEEDS-OWNER in every cell, and the release decision stays its gate (AI Assurance lesson 4.3, The Agent Deployment Addendum, and its release gate in 5.5), not this training's. This training fills the rows the addendum left blank: an assigned owner, Distribution Operations, and the one capability nobody had named — per-action authorization, enforced at a gateway outside the agent: the envelope can stand, but the authorization cannot, because every action is decided fresh, inside limits the agent cannot reach, and receipted where it cannot write.

Self-paced · 6 modules, 22 lessons · about 6 hours

Chapter 9 in the Meridian sequence · 9 live so far — the sequence follows one fictional utility through the same modernization, so the examples build on each other, and this one picks up the story from Operating in Production: On-Call, Incident Command, and Reporting Clocks, AI Assurance: System Risk and Release Decisions, Zero Trust Implementation. Each training stands on its own; the order is the recommended path, not a prerequisite — the examples name the same fictional utility, but nothing from the earlier trainings is needed to follow them.

What this training covers

Six modules follow one proposed agent, MU-AI-011, from an addendum with no owner to a guarded first night on shift. Module 1 assigns that owner — Distribution Operations — and classifies every action the agent might take by impact and reversibility, from a draft work order it can revise, through a crew reassignment that costs real time to undo, to a dispatch notice that cannot be recalled once crews move. Module 2 builds the envelope itself: parameter and budget limits enforced at a gateway outside the agent's own instructions, tested the way code is tested, with a sandbox that closes the doors an envelope alone leaves open. Module 3 captures the state before an action and checks the result afterward with a test the agent did not write itself, then either reverses what can be reversed or requires two named people to authorize what cannot. Module 4 makes every approval expire — bound to one action, usable once — and builds a kill switch the agent cannot reach, rehearsed and timed like a fire drill. Module 5 gives every attempted action a receipt in a chain the agent has no write access to, so an incident record can point at what happened without ever trusting the agent's own account of it — and reads five dated cases where other organizations' agents acted without one. Module 6 costs the incremental effort of guarding one agent in reader-supplied numbers, promotes and demotes its autonomy on receipts rather than a settings flag, and closes with a full guarded night: MU-AI-011 running end to end, entirely inside a non-production lab.

Why it matters

Most organizations cannot say how fast they could stop an artificial intelligence (AI) system if they had to, and that gap is measured, not assumed: ISACA (an international IT-governance and audit professional association) surveyed more than 3,400 professionals in May 2026 and found that 56% do not know how fast they could halt an AI system, and 39% have no documented shutdown process at all. This training closes that gap for one agent by building a kill switch outside the agent and rehearsing it until time-to-halt is a measured number, not a guess. Approval fatigue is the other half of the same problem: in a 2026-03-25 post about its own coding product, Anthropic reported that users approved 93% of the permission prompts they were shown — a rate that makes rubber-stamping, not judgment, the default the moment approvals become routine. This training answers that by designing approvals to be rare, specific, and bound to one action instead of frequent and generic. And "keep a human in the loop" is not, by itself, a control: the joint guidance "Careful adoption of agentic AI services" (2026-04-30 — one document) states that human oversight must be decided "by system designers or operators, not delegated to the agentic AI system" itself — which is exactly what a named owner, a signed action register, and an expiring approval are for. None of this guidance binds Meridian directly; it is a vendor, not a government agency, so a federal rule reaches it only where a contract says so — Lesson 4.4 walks that determination row by row, so a reader can tell which rules a given contract, sector, or vendor puts them under. A memo from OMB (the White House office that issues binding policy to federal agencies), M-25-21, reaches Meridian's systems solely through its interconnect contract with the federal energy-coordination system MU-AI-011's data ultimately feeds — and even that reach stops at the information technology (IT) and data boundary. The same test applies to any organization: an interconnect that carries federal data flows can carry a directive with it, and the contract, not the guidance, is where to look. The physical grid-control systems that keep power flowing stay out of scope for this training and for the agent's authority, full stop.

What changes in practice

Tags name what each shift affects most: calendar time, cost, contract risk, or an audit finding avoided.

1. 1

   Every agent action gets a named owner and a class before its first run

   Audit finding avoided

   Why it matters: an agent with no owner does not run at all - the guard refuses it - and the register a named owner signs sorts every action into reversible, compensable, irreversible-with-two-people, or never delegated before the agent is ever pointed at a real work order · Module 1

2. 2

   Limits are enforced at a gateway the agent cannot edit, never inside its own instructions

   Cost

   Why it matters: a rule written only in the prompt can be lost when context compaction removes it - enforcing budgets and parameter bounds outside the agent is what keeps one bad plan from becoming fourteen bad actions · Module 2

3. 3

   Every action is checked against a plan the approver saw and a result nobody self-graded

   Contract risk

   Why it matters: a restart that reports success is a claim, not a verification - an independent check before and after protects the outcome, and anything that cannot be undone gets two named approvers instead of one · Module 3

4. 4

   Approvals expire, and a switch outside the agent halts it in a measured window

   Calendar time

   Why it matters: a token that never expires is a standing grant wearing a different name - binding an approval to one action with a deadline, and timing how fast the kill switch actually halts the next attempt, turns the claim that it can be stopped into a measured number · Module 4

5. 5

   Every attempted action leaves a receipt the agent cannot edit or delete

   Audit finding avoided

   Why it matters: an incident record can cite an action by its receipt id without ever granting write access to the log it points at - and a request to delete that log gets quarantined for review instead of honored · Module 5

6. 6

   Autonomy is promoted and demoted on receipts, and the incremental cost is named before it is funded

   Cost

   Why it matters: raising an action class from `L1-approval-required` to `L2-autonomous-with-notice` is a signed record change, not a settings toggle - and the approver hours, drills, and receipt storage a wider envelope costs are counted before the next level is granted · Module 6

Where the effort goes

Most of the effort lands in building and rehearsing the gateway an agent's actions pass through, not in the agent itself. The work is writing the action register with the owner, classifying each action by impact and reversibility, wiring parameter and budget limits into a policy the agent cannot edit, and standing up a kill switch outside the agent's own reach. The practice substrate uses the command-line assistant the team already has plus small tools that require no account; it does not require a new agent platform or gateway product. The recurring work is approver time on actions that land at "ask," halt drills rehearsed on a cadence, and receipt storage that grows with every action the agent attempts — costed in Module 6 from numbers the reader supplies, not from an invented average.

How you'll know it worked

• Every action in the register carries a named owner, a class by impact and reversibility, and an autonomy level — never inferred, always signed
• Every approval expires, binds to one action, and is used at most once — a replayed or stale approval is refused, not merely logged
• The kill switch halts the next attempted action in a rehearsed, measured time, and re-enabling it names who did it and when
• Every attempted action — approved, denied, or halted — leaves a receipt in a chain the agent cannot edit, and an incident record can cite that receipt without ever writing to it