MITIGATION · m-tool-preexec
Pre-execution validation — a two-pass gate on every tool call an agent makes
An LLM produces tool-call arguments through generation, not through a type system, and generation is not reliable. The arguments may be wrong in type, out of range, or assembled in a combination that violates business rules. A pre-execution validation gate intercepts the call before it reaches the tool: a schema pass confirms each argument conforms to the declared JSON Schema, and a policy pass confirms the argument combination is permitted for this agent and this action. The tool executes only when both passes clear.
At a glance
TL;DR
- The gate runs before any tool executes. The LLM produces arguments by generation, not through a type system, so the gate rather than the model is the reliable enforcement point.
- Pass 1 is schema validation: every argument must match the declared JSON Schema for that tool (type, range, enumeration, regex pattern). Pass 2 is policy validation: the argument combination must satisfy business rules for this agent and this action, evaluated by a decision engine external to the LLM.
- A rejected call is logged with the tool name and the failure reason, and surfaces as an audit signal. The tool never runs.
- Schema validation (Pass 1) is already available from major function-calling SDKs at negligible latency cost. Policy validation (Pass 2) via OPA adds 1-5 ms over a local Unix socket. No separate infrastructure is required for Pass 1.
How it behaves
What it is
When an LLM calls a tool, it generates a block of arguments. That generation step is probabilistic: the arguments may be incorrectly typed, outside declared ranges, or composed into a combination that the tool's operator never intended to permit. The agent cannot reliably constrain its own output here, because the constraints are not part of its reasoning; they are external policy.
A pre-execution validation gate sits at the seam between the LLM output and the tool invocation. The gate runs in two sequential passes.
The first pass is schema validation. Each argument in the generated call is checked against the declared JSON Schema for that tool: types, enumeration membership, numeric ranges, string patterns. A mistyped argument or an out-of-range value fails here before any further evaluation.
The second pass is policy validation. Even when every individual argument is schema-valid, the combination may violate a business rule. For example, transfer(amount, recipient) may be individually valid arguments, but the combination may exceed the agent's authorised daily transfer limit for that recipient. Policy rules evaluated by a decision engine such as OPA express these cross-parameter constraints and return an allow or deny decision. The tool executes only if both passes return clear.
The seam this gate occupies is the natural enforcement point. An argument that passes both checks may still be wrong in intent, but it cannot be wrong in type or in policy, which is the class of error that causes the most consequential misuse.
Detection signals
- Schema-validation failure rate per tool. A rising rate points to prompt injection, a misaligned system prompt, or an attacker probing the parameter surface.
- Policy-validation rejection rate by rule category. A spike on a specific rule class (for example, amount-limit violations) indicates a targeted manipulation attempt rather than model drift.
Threats it covers
-
WHY IT HELPS Tool Misuse is the execution of a tool with parameters or in combinations the operator did not intend to permit. A pre-execution gate evaluates each argument against the declared schema and each parameter combination against the policy before the call is forwarded, so an in-scope tool invoked with out-of-scope arguments is refused before any action commits.
Principle coverage
Defence-in-Depth stage: Prevent — and it advances:
- Default / Implicit Deny Pre-execution validation applies default-deny at the tool-call seam: a call proceeds only when both the schema pass and the policy pass return clear, so any argument combination that no policy rule explicitly permits is refused before the tool runs.
- Constrained Generation & Deterministic Guardrails The LLM generates tool-call arguments freely, but those arguments must pass a schema and policy gate before any action is taken. The gate is the enforcement mechanism that makes constrained generation real at the invocation boundary.
- Confused-Deputy Prevention A confused-deputy attack requires the agent to invoke a tool with parameters the operator did not authorise for that agent in that context. The policy pass evaluates the full argument combination against declared business rules, so the agent cannot be induced to forward a call the policy does not permit regardless of how the request was constructed.
- Input/Output Validation Pre-execution validation is the output half of I/O validation at the tool-call seam: it inspects every argument the LLM produces before the tool acts on it, mirroring what input sanitisation does on the inbound path.
- Complete Mediation Complete Mediation requires every access to be checked independently, not only the first. The pre-execution gate evaluates each tool call as a separate two-pass query, so no invocation proceeds on a cached or prior approval.
Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.
Implementation options
Five verified implementation options, each addressing a different deployment model. Mix them: schema enforcement from the SDK, policy enforcement from OPA or application middleware.
Anthropic tool use (strict: true) Set strict: true in each Anthropic tool definition to enforce schema conformance via grammar-constrained sampling. The model is constrained at generation time rather than patched afterward.
Why choose it: Best when using the Anthropic SDK and guaranteed type-safe arguments are required with no additional application-layer parsing. Requires additionalProperties: false and all fields in required. Does not cover business-rule policy (Pass 2).
More details:
OpenAI function calling (strict: true) Set strict: true in each OpenAI function definition. The API enforces the JSON Schema so the response always contains correctly-typed arguments rather than best-effort strings.
Why choose it: Best when using the OpenAI API. Requires additionalProperties: false and all properties marked required; optional fields use union types such as ["string", "null"]. Does not cover business-rule policy (Pass 2).
More details:
OPA pre-execution policy Write Rego policies that accept a tool name and parsed argument map as input and return an allow or deny decision with a reason. Call OPA over its REST API at localhost:8181, or embed the Go library, before every tool invocation.
Why choose it: Best for Pass 2 (business-rule combinations). OPA decouples policy logic from application code, supports hot-reload of policy bundles, and produces structured audit decisions. Adds 1-5 ms over a local Unix socket. Requires Rego authoring; no industry-standard agentic policy library exists yet.
More details:
JSON Schema (Zod / Ajv / jsonschema) Parse raw LLM arguments through a per-tool JSON Schema 2020-12 validator in application code before the tool function runs. Zod, Ajv (Node.js), and jsonschema (Python) all implement the 2020-12 vocabulary.
Why choose it: Best when not using a first-party SDK strict mode, or when validation is needed across multiple LLM providers. Application-layer only, no extra infrastructure, under 1 ms per call. Does not cover policy; pair with OPA or application middleware for Pass 2.
More details:
Pydantic @validate_call Decorate each tool function with @validate_call. Pydantic validates every argument against the function's type annotations before the body executes, raising ValidationError on failure.
Why choose it: Best for Python agent runtimes. Idiomatic, zero extra infrastructure, and integrates with pydantic-ai tool definitions. validate_call supports Field() for range and regex constraints, making it suitable for schema validation (Pass 1). Does not cover business-rule combinations (Pass 2).
More details:
Trade-offs
- Schema validation (Pass 1) via SDK strict mode or a library adds under 1 ms per call and requires no additional infrastructure. The adoption cost is authoring the schema correctly.
- Policy validation (Pass 2) via OPA adds 1-5 ms over a local Unix socket. For ten tool calls per interaction the total overhead is under 60 ms, which is inside the noise of LLM inference time.
- Over-tight schemas that reject legitimate arguments create re-prompt cycles or fall back to human review. Calibrate ranges to actual business bounds rather than arbitrary guards.
- Development effort is low for the schema layer (schemas are required anyway for function calling) and medium for the policy layer (Rego authoring, bundle management, no standard agentic policy library).
When NOT to use
- Do not treat a passing pre-exec gate as the final control for high-stakes irreversible actions such as financial transfers or record deletion. Layer human confirmation on top via m-human-dual-control.
- Low value when the agent's only tools are fully read-only and scoped to the requesting user's own data. The SDK already validates schema and parameter manipulation risk is low.
- Do not skip pre-exec for write tools on the grounds that the model is trusted. Model trust does not remove the need to bound what the model can cause the tool to do.
Limitations
- A parameter that passes schema and policy can still be wrong in intent. The gate prevents out-of-bounds calls, not misused-but-in-bounds calls. Pair with m-intent-attestation when intent-versus-parameter drift matters.
- SDK strict modes cover schema conformance only. Business-rule combinations require a separate policy layer; no production-ready standard agentic policy library exists as of 2026.
- If a tool's JSON Schema is mis-authored (too permissive or with incorrect types), the validation gate passes bad arguments. Pair with m-tool-description-validation to catch schema authoring errors.
Maturity tier reasoning
- Tier 2 (real-composable): function-calling SDKs ship schema validation; OPA ships policy evaluation. Both are production-ready as individual components.
- What keeps this from Tier 1 is the absence of a standard agentic policy library. Every deployment authors its own Rego or equivalent, making the policy layer bespoke rather than commodity.
- The schema layer is closer to Tier 1 readiness: JSON Schema 2020-12 is stable, SDK strict modes are shipping, and validator libraries are well-maintained.
Last verified against upstream docs: 2026-05-30.