Tool Gateway (Policy-as-Code Enforcement)

Placement rationale

C05 sits in Layer 2 because it is the runtime enforcement point at the tool boundary - the single deterministic intercept through which every probabilistic agent decision becomes an enforceable, recordable action. Layer 1 controls establish who is acting (C01) and what they are allowed to be (C03, C04). C05 turns those facts into per-call decisions. Without C05, the Layer 1 identity primitives have nowhere to land: identity exists, but nothing verifies it on the call that matters.

Why

The model is not a security boundary. Prompt guardrails are soft and bypassable - an injection, a jailbreak, or a hallucination can produce a tool call that should have been blocked. The only reliable place to enforce what an agent is allowed to do is outside the model, at a deterministic intercept that every tool call must traverse. The intercept must reason about the call (who is making it, what tool, what arguments, what tier, what budget remains) and decide before the side effect happens.

Application-level allowlists fail because they assume the application enforces them: a compromised or misconfigured runtime can bypass them entirely, and an operator-driven config change can quietly widen the allowlist with no audit trail. Network rules fail because they cannot reason about call semantics - they see hosts and ports, not "transfer $50,000 from account X to account Y." Policy enforced in the prompt fails the first time the prompt is overwritten by instruction-channel content. RBAC alone fails because role assignment is too coarse to express the obligation context (HITL needed, signing needed, redaction needed) that high-impact actions require.

C05 reduces risk by placing deterministic enforcement at the tool boundary, where every side effect must pass through, and producing an immutable policy decision record per call. The decision record is the foundational evidence artifact for conformance: every other audit, replay, and incident-response capability in GATE depends on it being complete and tamper-evident.

What

A Tool Gateway implemented as a logical intercept that every tool call traverses before the side effect happens. On each call, the gateway:

1. Authenticates the agent identity (via C01) and verifies the claim set against the registered ABOM.
2. Validates the request payload against the registered tool schema.
3. Evaluates policy-as-code (allow / deny / obligate / transform / quarantine) over context: identity claims, tool risk class, tenant, ORM score, prior call history, time window.
4. Applies budgets and rate limits (C07).
5. Evaluates invariants alongside policy (C09) - invariants can deny even when policy allows.
6. Enforces attached obligations (HITL, signing, redaction) before forwarding the call.
7. Signs and commits the policy decision record to the audit ledger (C11 / C12).

Invariants the control guarantees:

• Every privileged tool call produces a policy decision record. Calls without a decision record are not possible because the gateway is the only path to the tool.
• Every decision record references the active policy bundle by hash, so the decision can be replayed against the same policy at audit time.
• Obligations attached to an allow decision are enforced by the gateway before the side effect happens. Obligations cannot be "logged and ignored."
• Bypass is detectable: any call to a registered tool that does not appear in the gateway's decision stream is a conformance failure.

How

Routing

Route all tool calls through the gateway. No direct tool access from agent runtimes. Block direct egress at the network layer where possible (cloud-native network policy, egress firewall, service mesh). The combination of a logical intercept and a network-layer block is what makes "bypass detection" trivial - any call that reaches a tool without a matching decision record indicates a hole in either the intercept or the network controls.

Schema validation

Validate inputs against the registered tool schema before policy evaluation. Reject malformed or ambiguous calls. Schema validation is where free-text injection content gets caught: an injection-crafted argument that does not conform to the schema fails before the policy engine ever sees it. Maintain tool schemas as a versioned artifact (C03); the gateway records the schema hash in the decision record.

Policy evaluation

Evaluate OPA / Rego (or equivalent) policy with full context: agent claims, tool risk class, tenant, ORM score, time, prior call history. Policy bundles are versioned and hash-pinned; the gateway loads from a signed registry and refuses to evaluate against an unsigned or mismatched bundle. The decision is one of five: allow, deny, allow-with-obligations, transform, quarantine. Each is recorded with the inputs hash so the decision is replayable.

Obligation enforcement

Obligations attached to an allow decision MUST be enforced by the gateway after the decision and before the side effect. HITL required: route to the approval service and wait for a signed approval. Signing required: produce an C12 action signature before forwarding. Redaction required: transform the payload before tool dispatch. Obligations that are logged but ignored collapse the conditional structure of the allow decision.

Deployment patterns

The "Tool Gateway" is a logical intercept, not necessarily a heavyweight network proxy:

• Sidecar pattern. Deploy as a localhost sidecar for low latency. The agent process talks to localhost; the sidecar performs identity verification, policy evaluation, and tool dispatch. Network policy blocks direct egress from the agent's pod.
• Library adapter. In strictly controlled runtimes, implement the gateway as a trusted library wrapper around the tool SDK - provided the agent process cannot bypass it (network policies blocking direct egress are the necessary complement).
• Centralised proxy. A shared mediation layer that all agent runtimes route through. Higher latency, but simpler central policy management and stronger guarantees against runtime-side bypass.

Safe rollout

Begin in shadow mode: the gateway evaluates policy but does not block. Operators observe the decision stream and tune policies against real call patterns. Promote to enforce per tool category, starting with read_only (lowest blast radius on a false deny) and ending with financial and infrastructure. The bypass-rate metric must be zero at each promotion gate.

Testing

Three test classes per policy change: unit tests on the Rego rules (per-rule pass/fail), policy regression tests against a corpus of historical decisions (the new bundle must produce the same decision on known-good calls), and adversarial tests with crafted inputs (the new bundle must reject known-bad calls and known-injection payloads).

Evidence

• Policy decision record per tool call. Fields: decision_id, request_hash, agent_instance_id, tool_name, tool_category, decision (allow / deny / etc.), obligations, policy_bundle_hash, tool_schema_hash, signature_ref, time, tenant_id, environment.
• Schema validation reject logs. When a request fails schema, the gateway emits a reject event with the input hash, schema hash, and validation error. Reject events are the early-warning surface for injection attempts.
• Bypass-rate metric. Count of calls reaching a registered tool without a matching decision record, computed daily. Target: zero. Any non-zero value is a P1 conformance failure.
• Policy bundle currency. Hash of the bundle the gateway is currently evaluating, compared against the latest signed bundle in the registry. Drift implies the gateway is enforcing a stale ruleset.
• Obligation enforcement evidence. Per obligation type: count of decisions with the obligation attached, count of decisions where the obligation was demonstrably enforced (HITL approval record, signature artifact, redaction log). Difference should be zero.
• Decision latency distribution. P50, P95, P99 of gateway decision time. Surfaces performance regressions before they push agents to attempt bypass.

Failure modes

• "Direct tool" shortcuts in code paths. A developer wires the agent directly to a tool SDK for performance or convenience. Any such path is a bypass of the entire control plane. Mitigation: pair the gateway with network-layer egress blocks; conformance check sweeps for tool calls without decision records.
• Policies enforced in prompts instead of the gateway. Soft, bypassable, and produces no evidence artifact. Mitigation: documented split between guidance (prompt) and enforcement (gateway); policy-as-code review in CI flags any prompt-embedded allowlist or constraint that should be in Rego.
• No schema validation. Free-text tool calling lets injection content through as tool arguments. Mitigation: schema registration is a precondition for tool listing; the gateway refuses to dispatch to a tool without a registered schema.
• Obligations not enforced (logged but ignored). The allow decision was conditional on the obligation. Logging without enforcement collapses that. Mitigation: obligation enforcement evidence as a tracked metric; gap between attached and enforced count is itself a conformance failure.
• Policy bundle drift. The gateway loads a bundle once and never refreshes; the registry has moved on. Mitigation: short refresh TTL on the gateway, hash comparison against the registry on every refresh, operational alert on drift.
• Fail-open on policy service outage. When the OPA process or policy bundle endpoint is unavailable, the gateway allows by default rather than denies. Mitigation: fail-closed by design; cache the last valid bundle and continue evaluating; if cache is also stale, deny with a documented recovery procedure.

NIST AI RMF alignment

C05 maps to MANAGE and MEASURE.

MANAGE: MG-2.3 (mechanisms to supersede, disengage, or deactivate AI systems are applied) - the gateway's deny path is the technical expression; MG-3.2 (responses to AI risks are documented and enforced) - policy bundles are the documented responses, the gateway is the enforcement; MG-4.1 (AI risks and impacts are documented and monitored) - the decision record stream is the monitoring surface.

MEASURE: ME-2.1 (test sets, metrics, and details are documented for AI system performance) - the policy decision record is the per-action measurement artifact; ME-2.5 (AI system performance and trustworthiness metrics are documented) - bypass rate, decision latency, obligation enforcement rate are the operational metrics.

ISO/IEC alignment

C05 maps to ISO/IEC 27001 A.8.2 (privileged access rights - per-call decision rather than per-session role), A.8.20 (network controls - egress blocks complement the gateway), and A.8.34 (protection of information systems during audit testing - the decision stream is the audit surface).

C05 maps to ISO/IEC 27002 control 8.7 (protection against malware - schema validation rejects malformed payloads at the boundary) and 8.20 (network controls - the gateway is the layered control that completes the network restriction).

Typical evidence: policy decision records, schema reject logs, bypass-rate metrics, policy bundle currency report, obligation enforcement evidence, decision latency distribution.

Related controls

• C01 Workload Identity - provides the identity and claims that C05 verifies on every request.
• C06 Circuit Breakers - the gateway is the enforcement point for stop conditions.
• C07 Resource Governance - budgets and rate limits applied by the gateway.
• C09 Invariant Enforcement - invariants evaluated alongside policy decisions.
• C12 Signed Actions - the gateway signs high-impact decisions for durable proof.
• C13 Policy bundle hash pinning - the decision record references the bundle hash so versions can be audited.