Enforcement Boundary
This page defines the pre-execution policy gate: all execution-capable entry points must route through the Gate enforcement boundary before an action can proceed.
Spec Drift Warning
Changes to implementation that violate invariant mappings invalidate compliance with v1.0. Implementations MUST preserve invariant-to-component, invariant-to-artifact, and invariant-to-verification-step mapping.
Compliance Assertion
- • Satisfies INV-6 by constraining all execution-capable entry points to the Gate execution boundary.
Non-Compliance Results In
- • Any bypassable execution path is non-compliant.
- • Any unauthenticated execution interface invalidates compliance.
Boundary Rule
Invariant Mapping: INV-6
No execution-capable interface SHALL exist outside the Gate enforcement boundary.
- • All direct API calls MUST route through Gate.
- • All background jobs MUST verify an approval envelope before execution.
- • All message-driven workers MUST verify an approval envelope before execution.
- • All scheduled tasks MUST use an approval envelope with explicit expiry.
- • All internal service-to-service execution requests MUST carry a valid approval envelope.
Pre-Execution Policy Gate
Invariant Mapping: INV-6
A pre-execution policy gate is the runtime decision point between agent intent and side effect. It evaluates identity, policy version, approval envelope, parameters, and target resource before execution. If the gate cannot verify the request, the action is denied or escalated instead of proceeding through an implicit bypass path.
- • The policy gate MUST run before a provider call, tool call, workflow transition, data write, or operating-system side effect.
- • The policy gate MUST bind the approval decision to the exact action parameters presented for execution.
- • The policy gate MUST emit approval or denial evidence before the governed action advances.
Allowed and Disallowed Paths
Invariant Mapping: INV-6
- • Allowed path: Client -> Gate -> Control Plane -> Gate -> Execution Layer -> Audit System.
- • Disallowed path: Client -> Execution Layer.
- • Disallowed path: Internal service -> Execution Layer without Gate mediation.
- • Disallowed path: SDK escape hatch that writes directly to the execution runtime.
Boundary Enforcement Mechanisms
Invariant Mapping: INV-6
- • Network policy MUST prevent non-Gate callers from reaching execution endpoints.
- • Runtime configuration MUST reject execution without an approval envelope.
- • Admission controls MUST prevent deployment of execution services that expose public execution interfaces.
Compliance Evidence
- • Firewall or service mesh policy showing only Gate reaches execution services.
- • Runtime test proving direct execution call is rejected.
- • Inventory of execution-capable interfaces with ownership and policy coverage.
Enforcement Mechanism Closure
Invariant Mapping: INV-6
- • Network isolation MUST restrict execution service listeners to a Gate-controlled network segment.
- • Service mesh or equivalent policy MUST require authenticated Gate identity for all execution traffic.
- • Execution runtime MUST validate approval envelope presence before dispatching the requested action.
- • Deployment policy MUST reject any new service that introduces an execution-capable interface outside Gate ownership.
Verification Linkage
INV-6
Artifact: audit-chain-001.json
Check: All execution traces include Gate, Control Plane, and Execution Layer components
Verification step: verify.sh: INV-6
INV-6
Artifact: verification walkthrough
Check: Direct execution bypass is rejected without an envelope
Verification step: Adversarial scenario 3