Runtime Enforcement Boundary
The runtime enforcement boundary is the component that intercepts operations, evaluates them against policy, and enforces the appropriate action. Placement affects latency, isolation, and operational characteristics.
What are the placement options?
The boundary can be deployed at different layers in your architecture. Each placement has distinct tradeoffs.
API Gateway
Enforcement at the network edge, before requests reach backend services.
Sidecar Proxy
Per-pod/container proxy that intercepts all traffic to the workload.
Runtime Wrapper
In-process wrapper that intercepts function calls or API usage.
Agent Framework Integration
Built into the AI agent framework at the tool/action invocation layer.
What does the boundary do?
Regardless of placement, the boundary performs the same core functions:
- 1.Intercept: Capture the operation before execution proceeds
- 2.Match: Evaluate selection rules to determine if governance applies
- 3.Measure: If matched, compute current state hash against baseline
- 4.Decide: Apply enforcement_mapping to determine action
- 5.Enforce: Execute action (CONTINUE, BLOCK, TERMINATE)
- 6.Receipt: Emit signed receipt documenting the decision
How do I choose placement?
Consider these factors when selecting boundary placement:
Factor Gateway Sidecar Wrapper Agent ───────────────────────────────────────────────────────────── Latency Higher Medium Lowest Low Isolation Strong Strong Weak Medium Language agnostic Yes Yes No Framework Deployment Simple Complex Embed Integrate Per-workload policy No Yes Yes Yes Semantic context None None Some Full Bypass resistance High High Medium Medium
What are the isolation requirements?
The boundary must be isolated from the workload it governs. If the workload can modify the boundary, it can bypass enforcement.
- ■Process isolation: Boundary runs in separate process with distinct permissions
- ■Network isolation: Workload cannot reach boundary admin interfaces
- ■File isolation: Policy artifacts stored in read-only locations for workload
- ■Key isolation: Signing keys not accessible to governed workloads
Frequently asked questions
Can I use multiple boundaries?
Yes. Defense in depth often uses gateway-level coarse filtering and sidecar-level fine-grained enforcement. Each emits its own receipt chain.
What if the boundary itself crashes?
The policy defines fail-closed or fail-open semantics. Fail-closed blocks all operations when the boundary is unavailable. Fail-open allows operations but marks them as ungoverned.
How do I handle high-throughput scenarios?
Use async receipt emission and batch checkpointing. The boundary should not block on receipt persistence for every operation. Chain integrity is maintained even with batched writes.