Agent Job Governance Gate

One entry point, seven checks

Every agent job passes through a single function before it executes. That matters more than the checks themselves: one entry point means there is no second path where a check can be forgotten.

The checks run in order, and the order is deliberate — cheapest and most absolute first, most expensive last.

1. Approval gate

   1 — Kill switch

   Decision point: Engaged for this scope? Deny. One switch, no negotiation, evaluated first because it is the cheapest possible answer.

2. Approval gate

   2 — Phase compatibility

   Decision point: Autonomy is ordered: observe is below assist, which is below autofix. A job may not request a mode above the phase its scope has reached. This is what makes escalation gradual rather than binary.

3. Approval gate

   3 — Allowlist

   Decision point: An explicit per-capability, per-phase allow or deny. The escape hatch for 'this specific thing, never'.

4. Approval gate

   4 — Concurrency

   Decision point: Running jobs in this scope at or above the ceiling? Deny. Bounds blast radius rather than cost.

5. Approval gate

   5 — Hourly rate

   Decision point: Decisions in the trailing hour at or above the ceiling? Deny. This is the check that makes a per-job budget mean something — a bounded job rescheduled immediately is an unbounded job in installments.

6. Approval gate

   6 — Verification, autofix only

   Decision point: A pluggable pre-check must return true. Skipped entirely for observe and assist, because the cost is only justified when something is about to change.

7. Approval gate

   7 — Canary, autofix only

   Decision point: The experiment canary must be green. A regression in the canary blocks the autofix.

8. Data store

   Audit the decision

   Every check writes a decision row and an event row with a machine-readable reason. Audit failure never fails the gate open — the gate's own logging cannot become a denial-of-service against it.

9. Monitoring / feedback

   Rollout advance

   Decision point: On a fixed cycle, a capability moves from one phase toward the next through a canary window, with automatic rollback and a recorded reason if it regresses.

Legend

• Data store
• Approval gate
• Monitoring / feedback

Scoped policy, resolved narrowest-first

A policy is not global-or-nothing. Three scopes exist — global, per-queue, and per-capability — and the effective policy is the narrowest one that matches. So the fleet can sit at observe while one well-understood capability runs at autofix, without weakening anything else.

The live policy rows are worth quoting because they show the intent: the two capabilities that have reached autofix are pinned to a concurrency of one, ten runs per hour, and both verification and canary required.

Decision points

• Is anything blanket-stopped? The kill switch, first.
• Has this capability earned the mode it is asking for? Phase compatibility.
• Is there capacity, and has it run too often? Concurrency and rate, separately — they bound different things.
• For autofix only: does it verify, and is the canary clean?
• Should this capability advance a phase, or roll back?

Responsibilities

Human approval points

1. Setting policy per scope, and the ceilings within it.
2. Approving an autofix run — required by default, and re-verified on resumption rather than trusted from the first check.
3. Advancing a phase, on the evidence the lower mode produced.
4. Engaging or releasing the kill switch.

Failure handling

Failure	Response
Policy store unreachable	Deny. An outage must not become an authorization bypass.
Audit write fails	The gate still returns its decision. Logging is best-effort so that it cannot block the thing it observes.
A capability regresses after promotion	The rollout rolls it back automatically and records the reason.
Workflow risk score too high	Auto-disabled, and the orchestrator refuses it before starting.
Approval requested but never given	The run stays parked. There is no timeout into execution.
Rate ceiling reached by legitimate load	Denied, and the denial is visible. Deliberate: a ceiling that yields under pressure is not a ceiling.

Monitoring

Decisions by outcome and reason, denial rate per check, concurrency and rate ceilings hit, rollout phase per capability, rollback count with reasons, and approval queue age. The reason codes are the useful part — an aggregate denial count tells you nothing, but a spike in one reason tells you exactly which ceiling to look at.