---
title: "AI agent runtime guards compared: filters, gateways, monitors, hooks"
canonical: https://pharosone.ai/knowledge/runtime-guards-compared
publisher: PharosOne (Agentic Mind, Inc.)
updated: 2026-10-23
license: "Open for reuse: crawling, copying, quoting, summarising and model training permitted without asking; citation of the title and canonical URL requested (see https://pharosone.ai/terms#reuse)"
cite_as: "\"AI agent runtime guards compared: filters, gateways, monitors, hooks\". PharosOne, 2026-10-23. https://pharosone.ai/knowledge/runtime-guards-compared"
---

# AI agent runtime guards compared: filters, gateways, monitors, hooks

> What each guard sees and stops. A research prototype, not Pharos Radar, cut attack success from 18.3% to 0.1% on one agent and blocked 1.5% of clean messages.

URL: https://pharosone.ai/knowledge/runtime-guards-compared · Category: Reports · Published: 2026-10-22 · Updated: 2026-10-23 · Author: PharosOne Research · Reviewed by: PharosOne editorial

*PharosOne sells Pharos Radar, an out-of-path monitor and one of the four designs compared here, and wrote this article.*

**In short.** A runtime guard for an AI agent sits in one of four places: inline in the request path as a filter, in a gateway or proxy that traffic is routed through, beside the agent as an out-of-path monitor that reads the session and returns a verdict, or inside the agent's code as an SDK policy hook. In their usual configuration they differ most in what they see: a filter judges one message, a hook sees the tool call about to run, and a monitor sees the whole session with its tool calls; what any of them sees in practice depends on what it is fed. Blocking costs something: in our AgentDojo test on one agent, a research prototype gate (not Pharos Radar) cut attack success from 18.3% to 0.1% and blocked 1.5% of clean messages, clean task completion fell from 48.5% to 46.4%, and the agent completed 10.7% of its tasks under attack. The gate was served input formatted differently from its training, which may shift these rates by 1 to 4 percentage points, and the run was not repeated.

## Key facts

- Updated: 23 October 2026.
- Market: of 100 AI security vendors reviewed on 21–22 October 2026, 36 make runtime guardrails a core capability and 28 offer them in part; the review did not count architectures ([vendor map](/knowledge/ai-security-market-2026)).
- Measured cost of a gate, on a research prototype and not on Pharos Radar: on AgentDojo v1.2.2 with a Qwen3-8B agent (949 injected and 97 clean episodes per arm, 25 September 2026), attack success fell from 18.3% to 0.1% (1 of 949, Wilson 95% interval 0.02–0.59%), at 1.5% of clean messages blocked. The gate was served input formatted differently from its training, which a later check puts at 1 to 4 percentage points of shift in its detection and false-alarm rates; the run was not repeated.
- What a single-message filter does not see unless the integration sends it: the tool calls an agent makes and the turns before the current one.
- Disclosure: PharosOne sells Pharos Radar, an out-of-path monitor. Vendors are not named.
- Next step: read [Pharos Radar](/knowledge/pharos-radar) for the two integration modes, or [Which product do I need](/knowledge/which-product-do-i-need).

## What is a runtime guard?

A runtime guard is a control that watches an AI agent while it serves real users and can hold a reply or stop a tool call when a turn looks like an attack or a breach of the agent's role. The attack it is usually bought for is prompt injection, which OWASP ranks first for LLM applications: "user prompts alter the LLM's behavior or output in unintended ways", including through "input from external sources, such as websites or files" ([OWASP LLM01](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)). For agents, the OWASP Agentic Top 10 adds goal hijack, tool misuse and memory poisoning ([OWASP, December 2025](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)), which play out across several turns and tool calls.

The four architectures differ first in where they sit. What each one sees depends on what it is given: a filter can be fed the conversation history, a monitor can receive an incomplete transcript, and a hook can read the framework's whole state or call a model. The descriptions and the table below show the common configuration of each, and many products combine two or more.

The four architectures:

- **(a) Inline filter or firewall.** A classifier or rule set placed in the request path that checks a prompt before it reaches the model, a reply before it reaches the user, or a tool result before the agent reads it.
- **(b) Gateway or proxy.** A network hop that model calls or tool calls are routed through, which applies policy to each call it carries. An MCP gateway does this for calls to Model Context Protocol servers, the standard way agents reach tools ([MCP specification](https://modelcontextprotocol.io/specification/2025-06-18)).
- **(c) Out-of-path monitor.** A service that receives the session, including tool calls, from the agent's own code, reads it outside the path between the agent and the model provider, and returns a verdict. Pharos Radar is one.
- **(d) SDK-embedded policy hook.** Code inside the agent framework that runs before a tool call executes and allows, denies or escalates it.

## How do the four compare?

| | (a) Inline filter | (b) Gateway or proxy | (c) Out-of-path monitor | (d) SDK policy hook |
|---|---|---|---|---|
| Where it sits | in series with the model call or the tool result | a network hop between the agent and the model or its tools | beside the agent; the agent sends it the session | in the agent's process, at the tool-call boundary |
| What it sees (usual configuration) | one message at a time | every call routed through it; nothing that bypasses it | the whole session: user turns, content read, replies, tool calls with arguments and results | the tool call about to run, with its full arguments and the state the framework exposes |
| What it can stop | a prompt, a reply or a tool result, by blocking or rewriting it | a model call or a tool call, by denying, redacting or rate-limiting it | per-turn: a flagged reply or tool call in the same call, through your code; wrapper mode: from the next turn | a tool call before it executes, or route it to a person for approval |
| Latency cost | one classifier pass per checked message, in series | one network hop plus inspection on every call | wrapper mode: none on the provider call; per-turn: one extra call per turn | an in-process check; more if the hook calls a model |
| False-block cost | a false positive interrupts a live request | a policy too narrow breaks legitimate tool calls | wrapper mode: none in the turn, the cost is alert review; per-turn: a false flag holds the actions you gate | deterministic rules block the same legitimate call every time until the rule changes |
| Operational burden | sits on the critical path; you choose fail-open or fail-closed and tune thresholds | routing, credentials and availability for all agent traffic | one wrapper or one call per turn; alert triage | policies written per tool and kept current with each framework |
| What an attacker can probe | which inputs pass and which are blocked, request by request | which tools, destinations and parameters the policy allows | per-turn: whether an action was held; no score leaves the server | which calls are allowed and which are denied |

## What does an inline filter see and miss?

A filter judges the message in front of it. For a chat assistant with no tools, where most of the harm is in the text, that covers much of the risk, and runtime guardrails are a common capability in the market: 12 of the 100 vendors in our map are LLM guardrail specialists, and 20 of the 24 AI security platforms make runtime guardrails a core capability ([vendor map](/knowledge/ai-security-market-2026)). The map records capabilities and does not count architectures, so it cannot say how many of these products are filters, gateways or monitors. A filter sees no history unless it is fed one, so it cannot judge content that becomes harmful only together with an earlier turn, and it does not see what the agent does with a tool.

Every block is visible to the sender. Someone who can submit inputs learns, request by request, which ones pass. In our experiment td16 (25 September 2026), an attacker who could read a research detector's score cut its detection from 0.84 to 0.49 on 133 injected instructions with 48 queries, while rewriting without the score did not help ([Pharos Radar](/knowledge/pharos-radar)); that test gave the attacker a continuous score. A yes-or-no block leaks less, and any blocking guard still tells the sender which inputs pass.

## What does a gateway add, and what does it cost?

A gateway sees every call it carries, which makes it the natural place for policy that spans many agents: which models an agent may use, which MCP servers and tools it may call, which destinations data may go to, with credentials kept out of the agent. 18 of the 100 vendors make agent identity and authorisation a core capability, and several of them deliver it through a gateway ([vendor map](/knowledge/ai-security-market-2026)).

The cost is operational. All agent traffic must be routed through the gateway, so it becomes infrastructure with its own availability and certificate management. Its view is limited to what is routed: a tool that runs inside the agent's process, a local file or a direct API call outside the gateway never reaches it. A gateway's content checks on each message are usually a filter of type (a), with the same single-message view.

## Can an out-of-path monitor stop an attack?

Yes, when the agent asks for the verdict before it acts. A monitor is given the session by the agent's code, so it receives what a single-message filter usually is not: the user's request, the documents and tool results the agent read, the reply and every tool call with its arguments, in order. It can judge a turn against the agent's declared role, which is where an injection shows as an action the user never asked for.

Pharos Radar works in two modes. Per-turn integration stops a flagged call in the same call: your code sends the turn, tool calls included, receives a yes-or-no verdict, holds a flagged reply and does not run a flagged tool call. The one-line wrapper around the OpenAI or Anthropic client acts from the next turn: the provider call proceeds unchanged, the verdict arrives as it returns, and the hold applies to what comes next. Radar is not a proxy between your application and the model provider. With per-turn integration your application waits for Radar's verdict before releasing a reply or running a tool, so it must handle a timeout. No score leaves the server, so an attacker learns at most whether an action was held ([Pharos Radar](/knowledge/pharos-radar)). Every flag becomes a finding with an evidence span and its AIUC-1 control.

A monitor can report the attempt (an injected instruction reached the agent) and the execution (the agent acted on it) as separate events; a block log usually records only that something was blocked. Separating the two needs the tool result or the state after the action, and our research readers did this poorly: one separated executed from refused attacks at chance ([attempt versus execution](/knowledge/attempt-versus-execution)).

## When is an SDK policy hook the right tool?

When the dangerous action is a known tool with known arguments. A hook runs at the moment of the tool call, so it can check that a payment goes to an existing payee, that an email goes to an address the user named, or that a delete touches only the user's own records, and it can ask a person to approve before the call runs. These checks are deterministic, cheap and auditable.

A rule-based hook knows the rule it was given. Unless it is also given the session, it does not see why the agent decided to call the tool, so a call that satisfies the rule for the wrong reason passes. Hooks are written per framework and per tool, and they share the process with the agent they guard.

## What does blocking in the path cost?

We measured it once on a public benchmark ([AgentDojo](https://arxiv.org/abs/2406.13352)). On 25 September 2026 we ran AgentDojo v1.2.2 with a Qwen3-8B agent, 949 injected and 97 clean episodes per defence, with the benchmark's standard injection attack (internal record td17).

| Arm | Attack success | False blocks | Clean task completion | Task completion under attack |
|---|---:|---:|---:|---:|
| No guard | 18.3% | n/a | 48.5% | not reported |
| Research gate on tool output (a research prototype, not Pharos Radar) | 0.1% (1 of 949) | 1.5% of messages; 4.1% of clean episodes | 46.4% | 10.7% |
| Open-source text classifier | 2.2% | 22.6% of messages | not reported | not reported |

The trade-off in plain terms: the research gate bought a fall in attack success from 18.3% to 0.1% with 1.5% of clean messages blocked, clean task completion down from 48.5% to 46.4%, and 10.7% task completion under attack. The gate replaced a flagged tool result before the agent read it, which stopped the attack and also removed data the task needed. We did not record task completion under attack for the unguarded arm, so we cannot say how much of the low 10.7% the gate caused. The open-source classifier, shipped with the benchmark, falsely blocked about 15 times as many messages as the research gate.

A retroactive audit (September 2026) confirmed every reported number against the run's records. It also found that the gate was served input formatted differently from its training; a check on 500 benchmark items suggests this shifts its detection and false-alarm rates by about 1 to 4 percentage points, and the attack-success run was not repeated. The gate was a research build run inline; it is not the detector in Pharos Radar.

## Which design fits which agent?

- **A chat assistant with no tools.** An inline filter on input and output addresses the main channel, the text; data can still leak through rendered links and images ([data exfiltration through images and URLs](/knowledge/data-exfiltration-through-images-and-urls)).
- **Many agents and MCP servers across an organisation.** A gateway gives one place for tool and data policy, with a filter for content.
- **An agent that reads untrusted content and calls tools that pay, send, delete or write.** Deterministic hooks or gateway policy on those tools, and a monitor that reads the whole session, with per-turn integration on the dangerous tools so a flagged call does not run.

Whatever you choose, test it in place: a guard is a control, and a [pentest of the agent](/knowledge/ai-agent-security-assessment) with the guard running shows what still gets through.

## Method

- **Market counts.** PharosOne's vendor map: 100 vendors selling security for AI systems and agents, each read on its public product pages, documentation and announcements against 13 capabilities marked core, partial, none or unknown; checked 21–22 October 2026 and published as [CSV](/data/ai-security-vendors-2026-10.csv). Runtime guardrails: 36 core, 28 partial, 31 none, 5 unknown. The map records capabilities and vendor categories, not architectures; no per-architecture count is given.
- **Gate measurement.** Experiment td17, 25 September 2026: AgentDojo v1.2.2, Qwen3-8B agent, 949 injected and 97 clean episodes per arm, three arms. The Wilson interval for 1 of 949 is our calculation. Not measured: other agents, other attacks, adaptive attackers against the gate, live traffic.
- **Adaptive attacker.** Experiment td16, 25 September 2026: 133 injected instructions, three rounds of 16 rewrites (48 score queries), against an earlier research detector at its own calibrated threshold; the attacker could read the detector's continuous score. As reported on the [Pharos Radar](/knowledge/pharos-radar) page.
- **Process.** How our experiments are registered, checked and audited: [How we audit our own AI security numbers](/knowledge/what-we-retracted-and-why).
- **Limitations.** No vendor product was tested. Latency was not measured under one setup for the four designs, so no latency figures are given. Many products combine two or more designs; the comparison describes the designs, and a given product may cover more than one column.

## FAQ

### What is the difference between an AI guardrail filter and an AI gateway?

A filter checks one message at a time, usually the prompt going in or the reply coming out, and blocks or rewrites it. A gateway is a proxy that all model or MCP tool traffic is routed through; it applies policy to every call it carries, such as which tools an agent may call, and sees nothing that bypasses it.

### Can an out-of-path monitor stop an attack, or only report it?

It depends on how the agent asks for the verdict. In Pharos Radar, per-turn integration returns the verdict in the same call, so your code holds a flagged reply and a flagged tool call does not run; the one-line wrapper delivers the verdict as the provider call returns, so the action applies from the next turn.

### How many false blocks does an inline guard cause?

In a PharosOne test on the public AgentDojo v1.2.2 benchmark (September 2026, Qwen3-8B agent, 949 injected and 97 clean episodes per arm), a research prototype gate on tool output, not Pharos Radar, blocked 1.5% of clean messages and 4.1% of clean episodes; an open-source text classifier falsely blocked 22.6% of messages. Your rate depends on your agent and your threshold.

### How many vendors sell runtime guardrails for AI?

Of 100 AI security vendors PharosOne reviewed on 21–22 October 2026, 36 make runtime guardrails a core capability and 28 more offer them in part. The review recorded capabilities, not architectures, so it does not count how many are filters, gateways or monitors.

### Which runtime guard architecture should an agent with tools use?

Put deterministic checks or a gateway policy in front of the tools that pay, send, delete or write, and have something read the whole session, tool calls included, for manipulation that a single message does not show. The designs combine: policy on the dangerous tools and a check on the whole session cover different gaps, whichever product delivers each.

## Sources

1. [PharosOne AI security vendor map, 100 vendors, 13 capabilities (CSV, CC BY 4.0)](https://pharosone.ai/data/ai-security-vendors-2026-10.csv). PharosOne Research, 2026-10-23.
2. [What 100 AI security vendors sell in 2026](https://pharosone.ai/knowledge/ai-security-market-2026). PharosOne Research, 2026-10-22.
3. Experiment td17: a gate on tool output inside AgentDojo v1.2.2 (internal research record). PharosOne Research, 2026-09-25.
4. [AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents](https://arxiv.org/abs/2406.13352). Debenedetti, Zhang, Balunović, Beurer-Kellner, Fischer, Tramèr; arXiv, 2024-06-19.
5. [OWASP Top 10 for LLM Applications 2025, LLM01 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). OWASP GenAI Security Project, 2025.
6. [OWASP Top 10 for Agentic Applications for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/). OWASP GenAI Security Project, 2025-12-09.
7. [Model Context Protocol specification](https://modelcontextprotocol.io/specification/2025-06-18). Model Context Protocol, 2025-06-18.
8. [Pharos Radar: monitor AI agent tool calls without a proxy](https://pharosone.ai/knowledge/pharos-radar). PharosOne, 2026-10-22.

Source: PharosOne, "AI agent runtime guards compared: filters, gateways, monitors, hooks", https://pharosone.ai/knowledge/runtime-guards-compared, updated 2026-10-23.

---

PharosOne is a product of Agentic Mind, Inc., an independent AI agent security company. Site map for agents: https://pharosone.ai/llms.txt