agent eval tools with runtime guardrails

Where Can an Agent Guardrail Run?

A guardrail can only inspect traffic that passes through it. Before choosing a product, decide which part of the agent you need to control.

• Model input and output. A scanner reads the prompt going in and the completion coming out - PII, jailbreak attempts, toxic text. It sees language, not actions.
• The gateway. Every model call goes through a proxy, so the proxy sees the tool calls the model asks for and can refuse to pass them on. It sees only traffic routed through it.
• The agent hook layer. The harness running the agent - Claude Code, Codex, Cursor - asks a hook before it executes a tool. The hook sees the actual command, file path or edit, including local shell and file actions that never touch a network.

A support bot may only need checks on prompts and responses. A gateway works when every model and tool call passes through the same proxy. Coding agents need protection at the hook layer because local shell commands and file edits may never reach a gateway.

Which Tools Can Block an Agent Action?

How the Three Runtime Guardrails Differ

Galileo: Agent Control, Plus Hosted Guardrails on Enterprise

Galileo - which, per its release notes, has been Splunk Agent Observability since August 7, 2026 - launched Agent Control in March 2026 as an Apache-2.0 project with Python and TypeScript SDKs. It evaluates "LLM and tool inputs and outputs", and its decisions are "deny, steer, warn, log, or allow". Launch partners included Cisco AI Defense, CrewAI, Strands Agents SDK, Glean, Rubrik and ServiceNow. You deploy and run the open-source version yourself; a centrally managed Agent Control for enterprise customers shipped in June 2026. Its public material does not say whether a check can run before a tool executes, so ask if that is what you need. Galileo's older Protect product was deprecated in June 2026, and its docs send new users to Agent Control; the pricing page still lists "Real-time guardrails" under Enterprise. Galileo's strength is that the same company offers 20+ built-in evals, so the checks you enforce can come from metrics you already trust.

Future AGI: Protect in the Gateway

Protect blocks, warns, masks or logs model input and output across text, image and audio, with 18 built-in scanners and 15 vendor adapters including Lakera, Presidio and Llama Guard. It runs inline in the Agent Command Center gateway or as an SDK. In the gateway, a Tool Permissions scanner blocks tool calls and MCP Security inspects MCP calls. That coverage is for traffic routed through the gateway; ask Future AGI about actions that never pass through it. Its strength is breadth on the model side: scanners across modalities, plus adapters for guardrail vendors you may already use.

Failproof AI: Policies at the Hook Layer

The open-source failproofai CLI installs hooks into twelve harnesses: Claude Code, Codex, GitHub Copilot CLI, Cursor, OpenCode, Pi, Factory Droid, Devin CLI, Antigravity CLI and Goose, plus the Hermes and OpenClaw chat gateways; blocking a tool call before it runs is verified on all twelve. A policy at PreToolUse returns allow, instruct (guidance, never a safety boundary) or deny. The maintained coding agent pack has 38 policies, 10 on by default - among them block-sudo, block-env-files and five sanitize-* redactors for secrets in tool output - and custom policies are a few lines of JavaScript. Failproof AI Cloud adds the scoring side: code checks, LLM judges and the eval set you already have, all run in the cloud; audits whose findings carry a recommendation; and alerts. From an issue, generate policy drafts a policy, and backtest replays the draft against calls your fleet already made to count the working calls it would interrupt. It is not a model-I/O scanner - for PII or jailbreak screening of the prompt itself, Protect or Agent Control is the tool built for it.

npm install -g failproofai
failproofai policies --install                  # wire hooks into your agent CLIs; enables no policy
failproofai policies add FailproofAI/policies   # the coding agent pack, 10 policies on by default
failproofai policies                            # list what is enabled

Which Tools Detect Failures Without Blocking Them?

Judgment Labs, Raindrop and Latitude all score after the fact, off the agent's hot path. Judgment Labs' Agent Behavior Monitoring runs judges on the "completed traces" an instrumented agent sends; its measures cover "traces the judge evaluated, not necessarily every trace sent to the project", and its automations "notify a team or trigger an action" - a notification, a webhook, a dataset action or a further evaluation. The judgeval README describes scoring "live production traffic server-side with no latency impact". Raindrop detects issues and alerts in Slack; its PII Guard redacts at ingestion, which protects the stored data but does not stop the agent. Latitude's evaluations score sessions after they complete and never block or change a response; its "guardrails" limit what Agent Dispatch may do, not your traffic.

Keeping evaluation off the execution path avoids adding judge latency to every tool call. Judgment Labs is strongest at rubric-based judging, Raindrop compares cohorts of production traffic, and Latitude can open fix PRs through Agent Dispatch. You can keep one of these tools for detection and add a separate runtime check for failures that must be blocked.

How Do You Roll Out a Runtime Guardrail Safely?

A broad rule can block legitimate work. Start with a failure you have already observed, test the rule against past traffic, and enforce it only after you know what it catches.

1. Start with the failures a monitor has already shown you, not hypothetical ones.
2. Write the narrowest check that catches them - one tool, one pattern.
3. Backtest it. In Failproof AI Cloud, backtest replays a draft against calls your fleet already made - by default every agent over the last 30 days - and counts the working calls it would interrupt.
4. Run it in observe mode first. In Failproof AI Cloud, Admin → enforcement deploys a published version in observe before you switch it to enforce.
5. Prefer instruct over deny where a human handoff is the right outcome, and keep deny for actions you never want.

When Is Monitoring Enough?

If your agent has no side effects - it drafts text a human sends, answers questions from a read-only index, or proposes changes that go through review - a bad run costs a worse answer, and a score after the fact is the right tool. The same holds when every consequential action already waits for human approval. Add enforcement when an agent can act on its own and one bad action costs more than the engineering time to write the policy. Evals vs guardrails covers the split in more depth.