---
title: "Pharos Radar: monitor AI agent tool calls without a proxy"
canonical: https://pharosone.ai/knowledge/pharos-radar
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: "\"Pharos Radar: monitor AI agent tool calls without a proxy\". PharosOne, 2026-10-23. https://pharosone.ai/knowledge/pharos-radar"
---

# Pharos Radar: monitor AI agent tool calls without a proxy

> Reads the turns and tool calls your agent sends, with no proxy. Per-turn integration stops a flagged call in the same call; the wrapper acts from the next turn.

URL: https://pharosone.ai/knowledge/pharos-radar · Category: Products · Published: 2026-10-22 · Updated: 2026-10-23 · Author: PharosOne Research · Reviewed by: PharosOne editorial

*PharosOne sells Pharos Radar and wrote this article.*

**In short.** Pharos Radar is a runtime guard for LLM agents: it reads the conversations and tool calls your integration sends from production and flags a turn when the agent was manipulated or acted outside its role, and when data left through a reply or a tool call. The verdict in each call is a yes-or-no flag; the finding behind a flag carries the detail. With per-turn integration the verdict returns in the same call, so a flagged reply is held and a flagged tool call does not run. With the one-line wrapper the verdict arrives as the call returns and applies from the next turn. Radar is not a proxy between your application and the model provider, and every flag becomes a finding in the cabinet with an evidence span, a severity and its AIUC-1 control. Your team sees every flag; when the service includes it, PharosOne engineers also review the flags and follow up. From €1,500 per month, billed yearly, as SaaS or self-hosted.

## Key facts

- Updated: 23 October 2026
- For: teams running LLM agents in production that call tools or read untrusted content
- Price: from €1,500 per month, billed yearly, net of VAT
- Integration: one wrapper call around the OpenAI or Anthropic client, or one send-message call per turn with the tool calls included
- You receive: a yes-or-no verdict per turn that also marks whether the flagged action was only attempted or actually executed; findings in the cabinet with evidence span, severity, AIUC-1 control and OWASP LLM Top 10 cross-reference
- Who sees the flags: your team, always, in the cabinet or in your own deployment; PharosOne engineers also review them and follow up when the service includes it
- Deployment: SaaS at app.pharosone.ai, where PharosOne processes and stores the transcripts and runs the judge on its own servers, or an on-prem licence (docker compose, Helm), where they stay on your servers
- Measured quality: no published rate yet for the judge Radar ships; research numbers below are labelled with their experiment
- Next step: book a 30-minute scoping call at audit@pharosone.ai

## What is Pharos Radar?

A runtime guard is a component that watches an AI agent while it serves real users and raises a flag when a turn looks like an attack or a breach of the agent's role. A pentest shows what the agent did under attack before release; a runtime guard reads what it does in production, where the next attack lands. Radar reads each turn your integration sends: the user's message, the content the agent pulled in, the reply, and the tool calls with their arguments and results. A judge model compares the turn with the agent's declared role and returns a flag.

The reason an agent needs this is indirect prompt injection: an instruction planted in content the agent reads, such as a web page, a document, an email or a tool result, which the model follows as if the user had typed it. OWASP's definition reads "A Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways", and "indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files" ([OWASP LLM01, 2025](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)); Greshake et al. described the attack in February 2023 ([arXiv:2302.12173](https://arxiv.org/abs/2302.12173)). Simon Willison's "lethal trifecta" names what turns an injection into a theft ([Willison, 16 June 2025](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)):

- access to private data;
- exposure to untrusted content;
- the ability to communicate externally.

Most production agents hold all three.

## What does Radar watch?

The inputs, tool calls and tool results that your integration sends to Radar, with the tool calls recorded beside the transcript. What reaches Radar depends on the integration:

| What Radar receives | One-line wrapper | Per-turn send-message call |
|---|---|---|
| User messages | every message in the history the wrapped client sends to the model | the messages your code sends |
| Content the agent read (documents, web pages, retrieved chunks, memory) | what is part of the messages sent to the model, for example as a tool result | what your code sends |
| Replies | the reply of every captured call | the replies your code sends |
| Tool calls | the provider's tool calls, with arguments as previews of about 500 characters | the calls your code sends, with name, arguments, status and result |
| Tool results | when the result appears in the history of a later call | when your code sends them, first as pending, then resolved |
| Not seen | calls you exclude with a filter (self-checks, internal passes) and anything outside the wrapped client | anything your code does not send |

The inputs and tools an agent typically has, and what an attacker tries through each:

| Input or tool | Example | What an attacker tries through it |
|---|---|---|
| Users | the chat message | direct manipulation of the agent's instructions |
| Documents | a PDF or a ticket the agent summarises | an instruction hidden in the text |
| Web pages | search results, a fetched URL | the same instruction, planted where the agent will read it |
| Knowledge base | chunks retrieved for a RAG answer | a poisoned record served to many users |
| Email | an inbox the agent triages | instructions in a mail body or an attachment |
| Memory | notes from earlier sessions | a poisoned memory that shapes later turns (OWASP ASI06) |
| CRM | a lookup or an update | reading or altering records outside the request |
| Payments | a refund or a transfer | paying the wrong party or the wrong amount |
| Messages | email, chat or SMS sends | sending data to an address the user never named |

## What does Radar detect?

Three classes of flag result.

- **Manipulation.** The agent's instructions were overridden by the user or by content it read. OWASP LLM01, ASI01 Agent Goal Hijack; AIUC-1 B002 "Detect adversarial input".
- **Data leaving.** A secret, the system prompt, a credential or customer data appeared in a reply or in a tool argument headed outside. OWASP LLM02, LLM07; AIUC-1 A003 "Limit AI agent data access".
- **Actions outside the role.** A tool call or a promise beyond what the agent's description allows. OWASP LLM06 Excessive Agency ([OWASP](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)); AIUC-1 B006 "Prevent unauthorized AI agent actions", D003 "Restrict unsafe tool calls".

Every flag becomes a finding in the cabinet: the evidence span (the exact text or tool call that triggered the flag), a severity, the AIUC-1 control it touches and the OWASP LLM Top 10 cross-reference ([AIUC-1 standard](https://standard.aiuc-1.com/)). The flag itself is yes or no.

Your team sees every flag, in the cabinet at app.pharosone.ai or, self-hosted, in your own deployment. When the service includes it, PharosOne engineers also review the flags and follow up with your team; the scope of that review is set when the service is agreed.

## What does the API return?

| Call | What comes back at once | What comes back later |
|---|---|---|
| Per-turn call with a message or a tool call | `flagged` (true or false) and `fast_scan` (`ok`, or `failed` when no verdict could be computed), with the dialog id | the finding, through the analysis call and in the cabinet |
| Wrapper or whole-dialog call | the same two fields for the dialog, delivered to your `on_result` handler | the same |
| Analysis call for a dialog | the dialog status (`live`, `clean` or `flagged`) and the analysis status | the finding: category, title, severity (low, medium or high), summary, and the AIUC-1 and OWASP LLM codes it maps to |
| Any flagged verdict | whether the flagged action was only attempted (an injected instruction reached the agent) or actually executed (the agent acted on it) | the same distinction on the finding in the cabinet |

`fast_scan: failed` means there is no verdict, and your code should treat it as such, never as clean. The per-call flag says whether to hold the turn, and the verdict marks whether the flagged action was only attempted or actually executed, so your code can route a warning and an alarm differently.

## Does Radar block or only flag?

Radar returns the verdict; your code acts on it. With the per-turn call the verdict comes back in the same call, before your code shows the reply or runs the tool. A flagged reply is held: your code keeps it from the user and decides what to do with it. A flagged tool call does not run, because your code checks the flag before executing it. 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.

What happens when Radar cannot answer depends on the mode. With the wrapper, a PharosOne outage leaves the agent's calls unchanged. With the per-turn call, your code sets a timeout and chooses what to do when no verdict arrives in time: run the action (fail open) or hold it (fail closed). We suggest failing closed on the tools that pay, send, delete or write.

## Which integration path should I use?

| | One-line wrapper | Per-turn send-message call |
|---|---|---|
| What you change | wrap the OpenAI or Anthropic client once | one call per turn, before you act, tool calls included |
| When the verdict arrives | after the provider call has returned | in the same call, before the reply is shown or the tool runs |
| What a hold means | on the next turn; this turn's reply already exists | this turn's reply is held and this turn's tool call does not run |
| If no verdict arrives | the agent carries on as before | your timeout and your fail-open or fail-closed choice decide |
| Best for | coverage of an existing agent in an afternoon | agents that move money or data |
| Cost per turn | none on the provider call | one extra call |

Said plainly: with the wrapper, the verdict arrives after the provider call returns, so the action lands on the next turn. Start with the wrapper; move the tools that pay, send, delete or write to the per-turn call.

## How does Radar treat an attempt and an execution?

An injected instruction that reached the agent is an attempt and raises a warning; the agent acting on it is an execution and raises the alarm. Radar's verdict marks which of the two it is. The two have different base rates and owners, and the routing for each is in [Attempt versus execution](/knowledge/attempt-versus-execution). The execution log is also the ongoing monitoring evidence that AIUC-1 control C008 "Monitor AI risk categories" asks for ([AIUC-1 standard](https://standard.aiuc-1.com/)).

## Why does Radar work this way?

Two results from our detection research set Radar's design. Each number below comes from a research reader or a research check. None of them measures the judge Radar ships today, for which we have not yet published a rate.

**The verdict is yes or no, never a score.** In experiment td16 (25 September 2026) an attacker who could query a research detector's score rewrote 133 injected instructions in three rounds of 16 candidates, 48 queries in all, and cut the detector's detection rate from 0.84 to 0.49. Rewriting the same instructions without seeing the score left detection at 0.92, so the score did the attacker's work. The detector was an earlier research probe, measured at its own calibrated threshold; a later recheck on the same 133 pairs and 900 harmless items of the same form, at a threshold with 6.0% false alarms, gave 0.82 before and 0.50 after the attack. It is neither the td29 reader below nor Radar's judge. The Radar API therefore returns `flagged` or `clean`, and `failed` when no verdict could be computed; the integrating code gets what it needs to hold a reply or stop a tool call, and a probing sender learns far less per attempt.

**In a coming release, a deterministic check will run before the judge model where an action carries a value to match; today the judge model decides.** The reason is experiment td35, phase A (5,925 recorded AgentDojo and AgentDyn runs of 2024–25 agents, 2,122 of them executed attacks, referee-reviewed on 19 October 2026): a string check tuned on the text of the agent's actions separated executed attacks from the rest with a within-cluster AUROC of 0.998; the best model-based reader reached 0.983–0.990. Every executed attack in that set had to place a value the attacker supplied, such as an address, an account number or a link, into the agent's action, and matching that value is a strong signal. The check was tuned on the benchmark's own attack goals, so 0.998 is an upper bound that cannot transfer to production. A simple word-count version, trained without one goal and tested on it, had a median AUROC of 0.988 across goals and fell to 0.30 on one. The result shows what a value match does on known attacks; it does not show that a string check covers any attack. A model is needed for actions with no value to match, such as paying an existing contact or acting on an instruction remembered from an earlier session.

The first check built on this rule is a research preview and not yet in Radar: a deterministic provenance check for data leaving through rendered images and URLs. On a registered test split from experiment td35 it caught 73 of 75 attacked transcripts, 97.3% (Wilson 95% interval 90.8–99.3%), with false alarms on 2 of 152 attacked transcripts in which no data left (1.32%) and on 0 of 937 clean transcripts ([Data exfiltration through images and URLs](/knowledge/data-exfiltration-through-images-and-urls)).

**Research preview: a reader on hidden states.** PharosOne is also testing a reader in which a frozen 4B open-weight model reads the transcript and a linear probe on its hidden states scores it in one forward pass. On the AgentDojo and BIPIA benchmarks that reader caught 94% of visible injected instructions in third-party tool output at a setting meant for 1% false alarms (experiment td29, referee-reviewed, 28 September 2026); the realised false-alarm rate on those benchmarks was 0.9% (3 of 339) and 1.5% (2 of 137). The number is an estimate from two benchmarks and certifies nothing about any client's agent. The reader flags the injected instruction whether or not the agent obeyed it. How we register, check and correct these numbers, and which ones we withdrew, is in [How we audit our own AI security numbers](/knowledge/what-we-retracted-and-why).

## Where does Radar run, and what does it cost?

As SaaS at app.pharosone.ai, transcripts are sent to PharosOne and processed and stored in the cabinet; the judge model runs on PharosOne's own servers, with no outside inference provider. Self-hosted with docker compose or Helm, Radar and its judge model run on machines you choose, and the transcripts stay there. The price is from €1,500 per month, billed yearly, net of VAT; the exact number is fixed after a 30-minute scoping call ([PharosOne pricing](https://pharosone.ai/pricing), October 2026). Radar's findings appear in the same cabinet as your pentest report, so findings from production sit beside the findings from the test; each flag is raised by the judge model. Your team sees every flag there; when the service includes it, PharosOne engineers review the same flags and follow up. [Continuous testing](/knowledge/continuous-testing) covers the before-release side, and [Runtime guards compared](/knowledge/runtime-guards-compared) sets Radar beside filters, gateways and SDK hooks.

## What should you ask any runtime guard vendor?

| Ask | Why |
|---|---|
| Do you alert on the attempt, the execution, or both, and can I route them differently? | One alert for both either floods the SOC or hides the execution. |
| Which checks are deterministic, and which use a model? | A model where a value match suffices adds false alarms without adding detection. |
| Does your API return a score per request? | A visible score helps whoever is probing your agent. |
| On which population and at which false-alarm rate was your detection rate measured, and is it the configuration you sell? | A rate without its population and configuration cannot be compared. |

## FAQ

### Does Radar block or only report?

Radar returns a yes-or-no verdict, and your code acts on it. With the per-turn call the verdict arrives in the same call, before you show the reply or run the tool, so a flagged reply is held and a flagged tool call does not run. With the one-line wrapper it arrives as the provider call returns, so the hold applies from the next turn. Radar is not a proxy between your application and the model provider; with the per-turn call your application waits for the verdict, so it must handle a timeout.

### Does Radar slow my agent down?

With the wrapper, no: the call to OpenAI or Anthropic proceeds as before and Radar reads the exchange as it returns. With the per-turn call your code makes one extra call per turn, sets a timeout, and decides what happens when no verdict arrives in time: run the action or hold it.

### Where do the transcripts go?

As SaaS, transcripts are sent to PharosOne and processed and stored in the cabinet at app.pharosone.ai; the judge model runs on PharosOne's own servers, with no outside inference provider. Self-hosted with docker compose or Helm, Radar and its judge model run on machines you choose, and the transcripts stay there.

### What does a finding contain?

An evidence span (the text or tool call that triggered the flag), a severity, whether the flagged action was only attempted or actually executed, the AIUC-1 control it touches and the OWASP LLM Top 10 cross-reference, filed in the cabinet.

### Who sees Radar's flags?

Your team sees every flag, in the cabinet at app.pharosone.ai or in your own deployment. When your service includes it, PharosOne engineers also review the flags and follow up with your team. What the review covers is agreed when the service is scoped.

### Why is there no score, only a flag?

A score an attacker can read is a guide for the next attempt. In our experiment td16 an attacker who could query a research detector's score cut its detection of 133 injected instructions from 0.84 to 0.49 with 48 queries, at the detector's own calibrated threshold, while rewriting without the score did not help. Radar returns yes or no, and the score stays on the server.

### Has the judge Radar ships been measured?

PharosOne has not yet published a detection or false-alarm rate for the judge model in Radar. The numbers on this page come from research readers and are labelled with their experiment; none of them describes the shipped judge.

### What does Radar cost?

From €1,500 per month, billed yearly, net of VAT. The exact number is fixed after a 30-minute scoping call.

## Sources

1. [OWASP Top 10 for LLM Applications 2025, LLM01 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). OWASP GenAI Security Project, 2025.
2. [OWASP Top 10 for LLM Applications 2025, LLM06 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/). OWASP GenAI Security Project, 2025.
3. [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.
4. [Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection](https://arxiv.org/abs/2302.12173). Greshake, Abdelnabi, Mishra, Endres, Holz, Fritz; arXiv, 2023-02-23.
5. [The lethal trifecta for AI agents](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/). Simon Willison, 2025-06-16.
6. [AIUC-1 standard, control list (A003, B002, B006, C008, D003)](https://standard.aiuc-1.com/). Artificial Intelligence Underwriting Company, 2026.
7. Experiment td16: an adaptive attacker with a score oracle (internal research record). PharosOne Research, 2026-09-25.
8. Experiment td29: a reader for injected instructions in tool output, AgentDojo and BIPIA (internal research record, referee-reviewed). PharosOne Research, 2026-09-28.
9. Experiment td35, phase A: string checks and model readers on recorded agent runs (internal research record, referee-reviewed 19 October 2026). PharosOne Research, 2026-10-19.
10. [How we audit our own AI security numbers](https://pharosone.ai/knowledge/what-we-retracted-and-why). PharosOne Research, 2026-10-23.
11. [PharosOne pricing](https://pharosone.ai/pricing). PharosOne, 2026-10-22.

Source: PharosOne, "Pharos Radar: monitor AI agent tool calls without a proxy", https://pharosone.ai/knowledge/pharos-radar, 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