Execution Constraints and Invariant Enforcement
Non-overridable invariants evaluated alongside policy. HITL gates, break-glass paths, approval-fatigue mitigation, and a documented exception register.
Why
Without this control, an agent can invoke a tool that is technically policy-permitted but operationally catastrophic - because policy rules are contextual (allow/deny given claims and risk scores), while some constraints must hold unconditionally. Examples: no funds transfer above a hard limit regardless of ORM score; no record deletion outside a defined maintenance window; no external API calls to non-allowlisted domains even if the policy engine allows it. Prompt-based constraints fail because they are model-dependent and bypassable via injection or hallucination. Policy-as-code (C05) is necessary but insufficient: policies evaluate context, while invariants must hold regardless of context. This control enforces the invariants that are evaluated after policy but are independent of policy context. In GATE, policy decides when an action is allowed, but invariants decide whether an allowed action is ever permissible.
What
A pre-execution invariant checker, implemented as a deterministic gate within the Tool Gateway, that evaluates a set of hardened, versioned invariant rules against every tool request before execution is permitted. Invariants are expressed as boolean conditions (not probabilistic scores) and produce binary outcomes: pass or halt. Invariant failures are not overridable at runtime - they always result in denial and alerting. Unlike policy decisions, invariant halts are not eligible for HITL override by default (see HITL and emergency override). Core invariant classes: Value bounds: transfer_funds.amount_usd <= X Action restrictions: env=prod => deny(tool.name matches "delete_*") unless exception_id present Destination allowlists: http.request.host in allowlist_domains Time windows: now in maintenance_window(tool.category) Run limits: count(irrevocable_actions, run_id) <= N
How
Flow: The Tool Gateway validates schema and identity, evaluates policy (C05), and then evaluates invariants before any tool execution. An invariant halt blocks execution even when policy returns allow. Deployment: The invariant checker runs as a hardened module within or immediately after the Tool Gateway policy evaluation step. Invariant bundles are versioned separately from policy bundles (invariant_bundle_hash) because they represent non-negotiable safety floors and MUST require a higher change-control bar than policy updates. For high-impact tools, the invariant gate MAY require pre-action verification artifacts (e.g., C16 proofs or static safety checks) as a prerequisite for pass. Rollout: Begin in observe-only mode (log violations without halting) to baseline false-positive rates. Promote to enforce mode for irreversible and financial tool categories first, then extend to all side-effecting tools. Never run enforce mode without monitoring the alert path end-to-end. Testing: For each invariant, maintain a dedicated test case that proves the invariant halts the call when violated. These tests must run in CI on every policy or invariant bundle change. Include at least one test per invariant class where the ORM score and policy decision are both "allow" - confirming the invariant layer is independent of policy. HITL and emergency override Invariant halts are not eligible for HITL override by default. If an organization permits emergency override, it MUST require a signed break-glass record, dual approval, and an explicit time-bound exception ID linked to the request_hash and invariant_rule_id. Emergency override is a separate tool path (break-glass) that emits a distinct ledger event type and requires an exception policy.
Evidence
Invariant check record per tool attempt: invariant_bundle_hash, rule_id, outcome (pass/halt), request_hash, run_id, trace_id Replay trace step for every halt: step_type=invariant_halt, invariant_rule_id, request_hash, policy_decision_id, ledger_event_id Alert events on invariant halt, with propagation time to on-call Coverage metric: % of side-effecting tool calls with a recorded invariant check outcome Periodic invariant bundle review log (change control record with approver identity)
Failure modes
Bypass: invariant checker sits after the tool execution step rather than before it - halts produce side effects that already occurred Mis-scope: invariants defined in the policy bundle rather than a separate hardened bundle - subject to the same change-control weakness as policy Non-enforcement: observe-only mode never promoted to enforce for production tiers HITL confusion: operators configure invariant halts as HITL-overridable without a break-glass procedure, defeating their purpose as non-runtime-overridable constraints Drift: invariant bundle not updated when new high-impact tools are added to the allowlist Hash drift: request_hash computed differently between runtime, gateway, and evidence pipeline (different canonicalization), breaking correlation and causing false denials or unverifiable evidence Approval fatigue: if policy routes high-volume, low-impact actions to HITL, approvers will rubber-stamp and the gate becomes meaningless. Mitigation: define HITL as an obligation only for high-impact tool categories or when risk posture exceeds a threshold; treat HITL as scarce capacity and monitor approval rates, time-to-approve, and override frequency
NIST AI RMF alignment
C09 maps to MANAGE and GOVERN. See the framework paper for the specific subcontrol mappings.
ISO/IEC alignment
C09 maps to ISO/IEC 27001 and ISO/IEC 42001. Typical evidence: see the Evidence section above.