Security1 publisher2 min readPublished
Check Point moves the agent guardrail into the tool-call path at a claimed sub-100ms cost
The vendor's sidecar reads an agent's execution trace and blocks each tool call before it runs. Check Point says the check adds under 100 milliseconds because the expensive context work happens while the agent is still working.
The Watch · Security desk
What happened
- Check Point splits its agent monitor into two phases: context accumulation, which it calls expensive and runs asynchronously during the agent's execution, and tool call classification, which it calls cheap and runs synchronously.
- Classification is done against all accumulated past turns of the agent trace, which the company says lets the monitor catch harms that spread across several steps rather than one call.
- The worked example has production logs in a variable named LOG holding a database password, and an agent then opening a GitHub issue that references $LOG, which exposes the password.
- Check Point says OpenAI began investing more heavily in monitoring safety tools after the Hugging Face incident, including asynchronous monitors that flag misalignment mid-run and surface or pause the session.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- cost When an agent has already posted a credential, the deployer pays in rotation and third-party notification, and a monitor that flags after execution does not reduce that bill.
- exposure Any agent that can read a secret in one step and write to an external service in another is reachable under a per-action classifier, because each call looks ordinary on its own.
- decision Teams running agents now choose where to spend: latency on every tool call, or incident response on the calls that turn out to be leaks.
- constraint The blocking figure only bounds what a buyer cares about if accumulation keeps pace with the agent, and that behaviour is not documented in the post.
The figure holds regardless of how long the agent has been running, according to Check Point, because almost all the compute is finished before the tool call arrives: the monitor is sampled once, against context it has already ingested [5][3]. At 100 milliseconds a call, a run with 20 tool calls adds at most two seconds of wall clock [13]. The compute is still spent, only earlier. A high-parameter monitor model runs continuously beside the agent for the whole session [5][12].
The demo in the post streams an agent trace generated at 30 tokens per second [12]. That is one token every 33 milliseconds, so a 100-millisecond classification costs roughly the time the demo agent spends emitting three tokens [14].
Check Point says the monitor combines information from previous steps into its verdicts, recognises that LOG holds a database password, and denies the call that would post it [10]. It also says the system steers the agent once harm is detected [11].
This is the vendor's account of its own system. The post reports per-event latencies from a demo [12]. It withholds false-positive rates, and it says nothing about what the monitor does when accumulation falls behind the agent. The second point bears on the design claim, because a verdict is only as good as the turns already in context at the moment of the call [4].
A buyer can test the harm model without Check Point's numbers: a two-step trace where a secret enters a variable in one step and leaves through a tool call in the next, and whether the second call is denied [10].
What to watch
- Latency and false-positive numbers for a blocking monitor measured by someone other than the vendor selling it.
- Whether Check Point prices the continuously running context accumulation phase per agent-hour.
- Whether OpenAI or other agent vendors move their monitors out of flagging and into the blocking path.