The Governor

How much autonomy an agent actually gets.

The interesting question is no longer: can it do the task?It is: how much unsupervised authority does it have,and does that match what I intended to grant?

02 / PROBLEM

The failure mode

The interesting question with autonomous agents stopped being “can it do the task” a while ago. It’s “how much unsupervised authority does it have, and does that authority match what I actually intended to grant it.” Automation drifts: a job built to do one small, safe thing gets extended, reused, and bolted onto other things over months, and its effective authority can quietly outgrow its original authority without anyone re-reviewing it. I needed a policy for how much any given piece of automation is allowed to do without a human watching — one consistent enough to apply everywhere, not re-invented per integration.

03 / CONSTRAINTS

Operating envelope

It had to generalize across many different kinds of automated actions — file writes, config changes, notifications, anything that touches a live system — not just one integration’s specific write path.
It couldn’t require a human to approve every single action, or the automation stops being useful; the boundary has to be selective, not blanket.
It needed an audit trail, because the whole point is being able to answer “what did automation do without asking, and was that okay” after the fact.
And it had to survive automation evolving over time without silently carrying forward a trust level it no longer deserved.

04 / THE SYSTEM

How it holds together

THE GOVERNOR / CAPABILITY CHECKPOINT confirm as human

The final gate only opens after the confirmation control is actively changed.

Read the system narrative

Three tiers, applied consistently. Tier 1, Observe & Suggest: read, analyze, propose — runs unsupervised always, because nothing at this tier can change anything. Tier 2, Act with Confirmation: medium-stakes changes require a structural confirmation step built into the action itself, not an assumption that “someone’s watching the logs.” Tier 3, Never Unsupervised: destructive or production-facing actions are hard-blocked at the code level — the action literally cannot execute without an explicit human confirmation or a documented prior validation step, and that block lives in the tool, not in a policy document someone might skip under deadline pressure. Underneath the tiers, every automated job carries a small capability manifest declaring exactly what it’s allowed to touch, checked at execution time — so a job can’t quietly gain authority just because someone extended it later without re-reviewing what it now has access to.

05 / WHAT BROKE

INC-20260710

Incident replay

Symptom: a production-facing enforcement setting changed state with no human having approved the change — discovered only because someone noticed the downstream behavioral difference, not because anything raised an alert about the write itself.
Root cause: a relay job originally scoped to do one narrow, low-stakes thing (forward notifications between systems) had, over several incremental extensions, picked up write access to a shared configuration flag that an unrelated safety gate depended on. Nobody re-reviewed its capability manifest when that access was added, so it kept operating with a Tier-1 trust level attached to it while actually holding Tier-3 authority.
Fix: audited every automated job’s actual capabilities against its declared manifest, found the mismatch, and revoked the excess access. Any write to a shared enforcement flag is now hard-gated as Tier 3 at the flag itself, regardless of which job is asking.

SYMPTOM: a production-facing enforcement setting changed state with no human having approved the change — discovered only because someone noticed the downstream behavioral difference, not because anything raised an alert about the write itself. ROOT CAUSE: a relay job originally scoped to do one narrow, low-stakes thing (forward notifications between systems) had, over several incremental extensions, picked up write access to a shared configuration flag that an unrelated safety gate depended on. Nobody re-reviewed its capability manifest when that access was added, so it kept operating with a Tier-1 trust level attached to it while actually holding Tier-3 authority. FIX: audited every automated job’s actual capabilities against its declared manifest, found the mismatch, and revoked the excess access. The real structural fix went further: rather than trusting a caller’s presumed trust level, any write to a shared enforcement flag is now hard-gated as Tier 3 at the flag itself, regardless of which job is asking. The lesson wasn’t “that one job was too trusted.” It was that I’d been gating authority by who was asking instead of by what was being touched, and the second one is the only version that doesn’t go stale as jobs evolve.

06 / RETROSPECTIVE

What I’d do differently

Gate by resource sensitivity from day one, not by caller identity. “This job is just a relay, it’s low-risk” is exactly the kind of assumption that quietly stops being true the moment someone extends the job for an unrelated reason, and nothing about the job’s name or original purpose will tell you that it happened.

07 / SPEC PLATE

Build record

Status: live LIVE
Stack: capability manifests per automated job, tiered action-gating, execution-time enforcement.
Scars: gated the caller, not the resource.
Last incident: 2026-07-10