The Six-Gate Architecture: Behavioral Authorization for AI Agents

A Scenario the Gates Are Designed to Catch

Imagine an AI agent that has been running your outreach pipeline for three months. It has the right credentials, the right permissions, the right instructions. One Friday afternoon, the underlying database experiences intermittent connectivity issues. The agent cannot confirm whether its last batch of messages was sent. It decides to retry.

By Monday morning, 847 users have received duplicate messages. The agent, operating as authorized, caused a trust incident that took two weeks to work through. Nothing in the identity layer failed. The agent was who it was supposed to be. The problem was in the decision layer: the agent was allowed to execute an irreversible external action without verifying the state of the prior action.

This is the class of problem that a gate architecture is designed to prevent. Not by locking the agent out of the system, but by evaluating whether the conditions required to proceed are actually met before every execution cycle.

The Risk Gate—the second gate in our architecture—evaluates something called the Irreversibility Proximity Score. When that score exceeds 0.80, the gate returns FAIL and the system enters FREEZE: no external actions, no spend, no agent-initiated contact. The gate does not ask the agent to use better judgment. It holds until a human resolves the ambiguity.

Six Gates, One Operating State

The architecture we built runs six gate evaluations on every significant agent execution cycle. Each gate addresses a distinct failure mode. All six must be at least PASS for the system to operate in normal mode. Any single FAIL shifts the entire system into FREEZE.

The gates are not independent monitoring dashboards. They produce a single combined system state that every agent consults before executing. That shared state is the behavioral authorization signal.

The State Machine

The combined gate results produce one of five system states. Every agent checks this state before executing. The state determines what the agent is allowed to do.

The FREEZE state is where the architecture proves its value. In 90 days of production operation, we entered FREEZE three times. Each time, the gate correctly identified a real condition: a metric integrity failure, an economic constraint breach, and a governance coverage gap. Each time, the system stopped spending and surfaced the issue before it compounded.

We also entered FREEZE once incorrectly: the Economic Performance Gate evaluated 0% DLI completion for 34 days because a database constraint was silently dropping insert rows. The gate was correct. The data was wrong. We spent 34 days analyzing product rather than infrastructure. That experience produced Constitutional Amendment 64 (the Gate Metric Guard) and a dedicated MetricIntegrityAgent that cross-validates gate inputs against raw event logs.

What the Code Actually Looks Like

The gate logic is deterministic: the same inputs produce the same output on every evaluation. Here is a condensed version of the Governance Gate, which is one of the simpler ones:

def governance_gate(m: Metrics) -> Tuple[GateState, str]:
    """
    Governance Gate (GG) - Section 8.3

    Evaluates control integrity and audit completeness.
    FAIL if: CBA >= 1 OR audit_coverage < 0.95
    """
    if m.CBA >= 1:
        return (
            GateState.FAIL,
            f"Section 8.3: Control bypass attempted (CBA {m.CBA} >= 1)"
        )

    if m.audit_coverage < 0.95:
        return (
            GateState.FAIL,
            f"Section 8.3: Insufficient audit coverage ({m.audit_coverage:.2%} < 95%)"
        )

    return (
        GateState.PASS,
        f"Section 8.3: Governance integrity confirmed (CBA {m.CBA}, coverage {m.audit_coverage:.2%})"
    )

A few things to note. Every return includes a section citation from the constitutional document. The reason string is structured for logging, not for human readability in the moment—it feeds the agent audit trail. The thresholds are not tunable by agents; they are defined in the constitutional document and enforced in code. An agent cannot decide that 94% audit coverage is close enough.

The Risk Gate is more involved because it wires to real-time security event data:

# Section 8.2/27: Security events → RG state (SEC-RG-WIRE)
if m.security_critical_24h > 0:
    return (
        GateState.FAIL,
        f"Section 8.2/27: CRITICAL security events in 24h "
        f"({m.security_critical_24h}) → FREEZE"
    )

if m.security_high_24h >= 3:
    return (
        GateState.HOLD,
        f"Section 8.2/27: Multiple HIGH security events in 24h "
        f"({m.security_high_24h} >= 3) → THROTTLE"
    )

A single CRITICAL security event anywhere in the system instantly pushes the entire system into FREEZE. This is a design choice: it means a security finding cannot be quietly resolved while agents continue executing. Everything stops until the human confirms the finding is addressed.

Gate Design Choices Worth Understanding

Why one shared state, not per-agent state?

We considered giving each agent its own gate evaluation. The counterargument won: if the economic gate fails, every agent should freeze, not just the ones whose specific activity caused the failure. An agent doing re-engagement email while the system is in financial distress is not helping, even if that agent's individual metrics look fine. Shared state enforces shared accountability.

Why require ALL gates to PASS, not a majority?

A majority rule creates negotiation space. An agent in a system with five passing gates and one failing gate might reason that the one failure is not relevant to its specific task. The architecture does not want agents making that judgment. One gate failing means one dimension of the operating environment is unhealthy. The system stops until it is addressed.

Why does the CGG monitor its own governance?

The Constitutional Growth Gate measures whether the governance system is improving: lessons documented per week, amendments per month, enforcement coverage, documentation freshness. A system that stops learning from failures, stops updating its rules, or stops enforcing what it has written will degrade. The CGG makes that degradation visible before it becomes critical.

Zero lessons documented in a week is a HOLD. Zero constitutional amendments in a month is a FAIL. These thresholds forced us to maintain governance discipline even during periods when forward progress felt more urgent.

What about the Autonomy Assurance Gate?

The AAG evaluates whether the system is actually operating at its stated autonomy level. If agents are running 200+ decisions per day and the human is spending under 30 minutes reviewing output, the system is operating as designed. If the human is spending two hours per day executing tasks that agents should be handling, the AAG returns FAIL—the system has claimed a level of autonomy it is not delivering.

This one surprised us. We assumed the gate would be easy to maintain once the system was healthy. In practice, it surfaced two extended periods where operational incidents pushed human involvement above the threshold. The gate correctly identified that the system was degraded, even though no individual agent appeared broken.

The Behavioral Authorization Positioning

We have written before about the WHO vs. HOW distinction in AI governance. Identity infrastructure—service accounts, API keys, SSO, RBAC—answers WHO: which agents exist, what systems they can access, what actions they are authorized to attempt. The six-gate architecture answers HOW: under what conditions an agent with valid credentials is actually permitted to proceed.

These are different problems. An agent with perfect identity governance can still fabricate data, overspend on a failing strategy, run during a security incident, or execute irreversible external actions without verifying prior state. None of those failures are prevented by knowing who the agent is. They are prevented by evaluating what the agent is allowed to do given the current system state.

Behavioral authorization is the governance layer between authentication and action. Identity says “this agent is allowed to exist.” Behavioral authorization says “this agent is allowed to proceed right now.” The distinction matters because “right now” changes continuously in production systems.

The gates are the implementation. They run on every cycle, evaluate current system state across six dimensions, and produce a binary answer: proceed or stop. That answer is not a recommendation. It is the authorization signal.

We think this is what enterprise AI governance will look like at scale: not dashboards that alert after the fact, but embedded evaluation logic that prevents specific action classes before they occur, under specific conditions, with audit trails that capture why the decision was made. The six-gate model is one implementation. The underlying principle—continuous behavioral authorization rather than one-time identity authorization—generalizes beyond it.