Why latency matters
A coding agent may take dozens of steps to finish a task: read a file, run a test, edit, run again. If each tool call waits for a policy check, the waits add up. A check that takes a second per step makes an agent noticeably slower, and developers notice slowness faster than they notice risk. A control that makes agents slow will be pushed out of the way. Speed is part of whether pre-execution control survives contact with real work.
Three places a decision can run
On the device: the check runs next to the agent, with no network call. It keeps working offline and adds little delay, but it can use only the context and models that fit on the device.
In a gateway: traffic such as MCP calls or model API calls passes through a proxy that checks it. This sees everything that crosses the gateway, adds a network hop, and misses actions that never leave the device, such as a local shell command.
In a cloud service: the device sends the event to the vendor's service and waits for an answer. This can use the most context and the largest models, at the cost of delay and of sending data off the device.
What vendors state
Bay states that on supported agent surfaces its enforcement evaluates prompts, pre-tool calls and post-tool responses and returns Allow, Ask or Deny locally, in under 4ms. It is the only product we score that publishes both where the decision runs and a decision time. The figure is vendor-stated; we have not measured it.
Lasso Security introduced LEAP on 9 September 2026, describing a patent-pending classification architecture that reaches the detection accuracy of a GPU-based transformer guard while running on an ordinary CPU. Lasso's throughput and latency figures on that page are vendor-stated. Running guard models on CPUs matters for this question because it makes local or near-local classification cheaper. Lasso separately describes inspecting every Claude Code tool call before it is executed through the agent's lifecycle hooks.
Onyx Security describes inspecting every prompt, tool call and model response inline, and Zenity describes blocking or modifying a dangerous tool call before it executes through native agent hooks and its MCP gateway. Neither publishes a decision time on the pages we read.
How it shows up in our scores
Where and how fast the decision runs is part of our stopping-an-action-before-it-runs criterion. Bay scores 9 there, partly because it is specific on both points. Lasso Security, Onyx Security and Zenity score 8, 8 and 8. We do not score speed itself, because no one has published a comparable measurement.
How to test it in a pilot
- Pick one agent task your developers run often, with at least twenty tool calls.
- Time it with the control off, in observe mode and in enforce mode, on the same machine.
- Repeat with the network disconnected, to see which checks still run.
- Note what the agent does when the check times out: wait, continue or stop.
- Record what data leaves the device for each check.
The trade-off to decide
Local checks are fast and private and limited by what fits on the device. Service checks are richer and slower. Many products will combine both: simple capability rules locally, heavier classification remotely. Ask each vendor which checks run where, and what happens to the agent when the remote part is unavailable.
Why we label the figures
A decision time or a throughput number measured by a vendor depends on the vendor's hardware, its test set and the rules it chose. Your agents, your policies and your laptops will differ. That is why every speed figure on this site carries the label vendor-stated, and why the pilot steps above matter more than any number on a product page. Measure the two or three figures that would change your decision.