Tool Guardrails

What it is

The check applied to a specific invocation after the model has produced it and before the executor performs it, evaluated on the actual argument values with the run's history available. Unlike every check over prose, the object under inspection is structured — fields with types and ranges — and performing it changes something outside the conversation.

Entitlement is decided elsewhere

Whether this caller may use this tool at all is an authorisation question, answered from identity and from rules that existed before the request arrived. This capability takes that answer as given and asks a narrower one: with these particular values, at this point in this run, after everything already done, should the call proceed. A system can be entirely entitled to issue refunds and still be stopped at the thirtieth refund in a minute, or at an amount three orders of magnitude beyond anything it has issued before. The two live in different places for a practical reason — entitlement changes when people and roles change, while these limits change when the agent's behaviour changes — and conflating them produces a rule set that nobody can safely edit.

Why it matters

This is the only guardrail whose verdict prevents an effect rather than a sentence. Everything checked before it concerns what will be said; here the thing being held back deletes records, moves money, sends mail to customers, or rewrites a production configuration, and once dispatched there is no later checkpoint and often no way back. It is also the most tractable check in the domain, because the arguments are typed values rather than language: a rule can be exact, and its false-positive rate can genuinely be zero, which is not available to any classifier over text.

Key decisions

• What the rule tests: the tool name, the argument values, the derived effect of those arguments on the target, or the run's accumulated totals. Only the last two catch the calls that matter.
• Whether evaluation happens on the emitted call or on the final serialised payload, and whether anything is permitted to modify the call between those two points.
• Whether the tool can be asked what it would do — a dry run, a plan, a match count — and how much trust that preview earns given the target may change before execution.
• What a denial returns to the model: a terminal error that ends the run, or a structured refusal it may respond to. The second keeps the agent useful and tells a prober where the edge is.
• Which limits are cumulative rather than per-call — spend, records touched, external messages, calls per interval — where that state is held, and what resets it.
• Whether the result returning from a permitted call is inspected before it re-enters the context, since the call being allowed says nothing about the content coming back.
• How calls are made idempotent, so that a check firing after a partial effect does not turn a retry into a second execution.

Failure modes

• The check is attached to the typed tool wrapper, and the agent reaches the same system through a generic HTTP client, a database query tool, or a shell, where no wrapper exists.
• A rule bounds each call, and the model issues one call whose single list argument contains forty thousand identifiers.
• Validation runs on the arguments the planner produced, the executor fills a template from them, and the string actually sent is not the string that was examined.
• A preview and its execution are separate round trips against a system that changed in between, so the count that was approved and the count that was affected are different numbers.
• An amount is compared as a string, and values arriving with a different scale, a different currency, or in exponent notation order in ways the rule's author never considered.
• The denial is returned as a tool error, the model reads it as a transient fault, and it retries the identical call until the retry budget is gone.
• Cumulative counters are held per process, the service runs twelve replicas, and the effective limit is twelve times the configured one.
• Each step of a long plan is checked and nothing evaluates the plan as a whole, so twenty individually trivial writes compose into a migration nobody authorised.
• A guard rejects a destructive call and the agent achieves the same outcome through a permitted sequence — export, mutate, re-import — that no single rule describes.

Related capabilities

• Action Risk Classification — the score a threshold here can be written against
• Human Approval Gates — where a call too consequential to allow or deny automatically goes
• Fail-closed Behavior — what dispatch does when this check cannot answer
• Tool Permission Management — the entitlement decision this check assumes has already been made
• Tool Execution Sandbox — the containment that bounds what a permitted call can reach

Applies: Production readiness · Design questions