Guardrails and AI Safety
Tool Guardrails — Stack
Tool guardrails › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
The component is on the dispatch path of every invocation, so the questions are about placement, expressiveness over values, and whether it can see state.
- Placement. Whether it can be installed at a point with no bypass, including calls issued by background jobs, retries, and replay tooling.
- Value expressiveness. Whether rules can compare numbers, ranges, set membership, and relationships between arguments, or only match names and literal strings.
- State access. Whether a rule can read a counter scoped to the run, the session, or the tenant, which is what cumulative limits require.
- Evaluation latency. Added time per invocation, multiplied by the number of calls in a multi-step run rather than by the number of requests.
- Rule testability. Whether a rule set can be unit-tested, diffed, versioned, and rolled back like code, or exists only as live configuration.
- Decision transparency. Whether a denial records which rule fired and on which argument, so an agent's blocked run can be explained to the person whose work it was.
- Preview support. Whether the integrated systems can report an effect before performing it, since without that the rule is reasoning about intent rather than consequence.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Policy engines with a dedicated rule language (Open Policy Agent with Rego, Cedar, Casbin) | Argument-level rules that need to be reviewed, tested, and distributed independently of the application | Another language and another deployment; counters and run state usually have to be supplied as input rather than queried |
| Schema and constraint validation at the call boundary (JSON Schema, Pydantic, typed decoders) | Rejecting malformed and out-of-range arguments deterministically at negligible cost | Expresses shape, not consequence; a well-typed argument can still select the entire table |
| Middleware or a proxy in front of tool servers, including MCP server-side interception | Applying one check to every client of a tool regardless of which agent calls it | Sees the wire payload without the reasoning that produced it, which makes intent-dependent rules impossible to write there |
| Workflow engines with explicit gate steps (Temporal, AWS Step Functions, Azure Durable Functions) | Multi-step plans where cumulative state and compensation have to survive restarts | Only governs what runs inside the workflow; a direct call from agent code bypasses the engine entirely |
| Target-system guards (read-only replicas, statement timeouts, row-limit policies, transaction wrappers, budget caps) | The last line that holds even when the agent reaches the system by an unexpected route | Expressed in the target's vocabulary, so the agent receives an error with no useful explanation |
| Reversibility layers (soft delete, staged changes, delayed send, outbox with a hold window) | Actions where a short recall window is worth more than a refusal | Adds a state the product must expose and reconcile; a hold that nobody monitors is just a delay |
| Feature-flag and kill-switch platforms (OpenFeature, LaunchDarkly, Unleash) | Withdrawing a tool or tightening a limit during an incident without a deployment | Flag state becomes an undocumented part of the policy; drift between environments is routine |