The eight gates every agent run should pass

Most teams treat AI governance as something you observe: a dashboard, a quality score, an audit you run at quarter-end. Observation matters, but it happens after the action already executed. By then the money has moved and the record has been written. Real governance has to happen before — on the execution path, as a gate the action must pass to proceed.

In Cortex, every agent action runs the same pipeline of eight fail-closed gates. Fail-closed means deny is the default: if a gate cannot affirmatively pass an action, the action stops. Nothing reaches the model or the tool until the whole sequence clears. Here is the pipeline, in order.

The pipeline

• 1 — Identity. Is this a governed agent identity, active and unexpired? An expired or suspended identity is refused with 403 IDENTITY_EXPIRED before anything else runs.
• 2 — Budget. Is there spend left under the tenant and per-agent caps? A blown cap returns 402 — the run never starts.
• 3 — Guardrails (input). DLP and safety screening on the prompt and inputs before the model or any tool sees them. A blocked input never reaches the model.
• 4 — Registry. Is the skill, tool, or model registered, allowed, and — for publish — above the reliability bar? A below-bar publish is refused with 409 RELIABILITY_TOO_LOW.
• 5 — Control Tower. Is the agent or tool paused, contained, or under a kill switch? A paused subject is stopped here.
• 6 — Execute. The governed call to the model and tools actually runs — the only gate whose happy path is a 200.
• 7 — Output guardrails. DLP and safety screening on the generated artifact before it is released to a human or a downstream system.
• 8 — Audit. The outcome is sealed into the tamper-evident Trust Ledger with a signed receipt — so the run is provable, not just claimed.

Every box in the pipeline is a governance gate you can see and control. If any gate denies, the run never reaches the model or the tool. Deny is the default.

Policy and oversight layer on top

The eight gates are the structural floor. Two configurable layers sit on top of them and can only make a decision stricter, never weaker. Policy-as-Code evaluates your rules in priority order and resolves to the most-restrictive effect — deny beats require_approval beats allow. A high-value action trips a require_approval rule and pends instead of executing:

POST /v1/governance/simulate
  { "context": { "amountUsd": 7000 } }
  -> { "effect": "require_approval",
       "matchedRule": "high-value-payout" }

# the same call with amountUsd: 100 -> "allow"

Oversight modes decide how much autonomy an agent has — from suggest_only, where every action pends, through execute_low_risk, up to autonomous, where only the action's own risk floor pends. Critically, oversight is a tightening layer: the action's high-risk floor is always respected, and oversight can only add friction, never remove it.

Why a denial is a feature, not a failure

A real status code on a denied action is the most useful thing a governed runtime produces. A 402, a 403, a 409, or a 451 is an honest, machine-readable verdict: this action was stopped, here is exactly why, and here is the record that proves it. Silent passes are what get enterprises into trouble — the action that ran when it shouldn't have, with nothing to show for it.

When every run clears the same eight gates and every verdict lands in the ledger, governance stops being a quarterly audit and becomes a property of the system. You don't hope an agent behaved. You can show, gate by gate, that it had to.