13 Milliseconds: Giving Browser Agents a Safety Net

Browser agents are filling in a long-missing piece of infrastructure: pre-execution verification.

The open-source project Hwatu, which recently appeared on Show HN, attempts to add a real-time inspection layer between agents and browser executors. Its headline metric is that it can inspect a call within a window of approximately 13ms, consolidating verification into a single call rather than requiring developers to assemble another complex approval workflow.

This direction deserves attention. Over the past year, browser agents have advanced rapidly: reading the DOM, interpreting screenshots, clicking buttons, filling out forms, downloading files, and even executing page scripts are no longer particularly difficult. What remains unresolved is who constrains the agent once it gains these capabilities.

Prompts are not a security boundary, and neither is model self-reflection.

The value of a 13ms check goes beyond speed

Based on the information currently available, Hwatu is positioned not as another browser automation framework, but as a verification browser for AI agents—that is, a browser verification layer. It focuses on the brief window after an agent issues a call but before the browser actually executes it.

A typical browser agent pipeline looks like this:

Page state → Model reasoning → Action generation → Browser execution → New state returned

With a verification layer added, the pipeline becomes:

Page state → Model reasoning → Action generation
                    ↓
          Real-time verification and approval
                    ↓
          Browser execution or rejection

It may look like only one extra step, but its engineering significance is substantial.

Browser operations inherently have side effects. Reading a page and clicking “Place Order” are not actions of the same risk level, nor are opening a document and downloading an executable file. As soon as an agent can access an authenticated session, it effectively inherits some of the user’s permissions on that website. A single erroneous click could mean publishing a post, making a payment, deleting data, changing permissions, or submitting sensitive information to a third-party page.

Verification must therefore occur as close to the execution point as possible. If the check happens too early, the page state may already have changed; if it happens too late, the side effect has already occurred. Hwatu’s emphasis on 13ms essentially suggests that this inspection layer could operate in the agent’s hot path rather than serving only as an audit tool after a task is complete.

However, this number should be interpreted cautiously. The 13ms figure is more likely the verification latency for a specific type of call in a specific environment than the end-to-end latency of a complete browser task. It does not mean that a page loads in 13ms, nor that a model can understand complex business semantics within 13ms. The project is still at an early stage, and until its benchmarking methodology, concurrency conditions, machine configuration, and inspection rules are disclosed in greater detail, a single latency figure should not be treated as a production-grade performance guarantee.

Even so, it raises the right question: if every security check requires an additional call to a remote large language model and a wait of hundreds of milliseconds or even several seconds, it will be difficult to cover every step an agent takes. A target on the order of 13ms means the verification layer must be lightweight enough to truly “inspect every call.”

A one-call check does not mean checking the entire task only once

A more reasonable interpretation of “one-call check” is that a single agent tool call can be inspected through one verification endpoint—not that an entire multi-step task is deemed safe all at once.

The distinction is significant.

Suppose a user asks an agent to log in to an enterprise admin portal, export this month’s report, and send it to the finance department. This task includes at least the following steps:

1. Open the admin portal domain;
2. Use the existing authenticated session;
3. Navigate to the reports page;
4. Select the date range;
5. Click Export;
6. Download the file;
7. Open an email or instant messaging tool;
8. Upload the attachment and send it.

Asking “Is this safe?” once at the beginning of the task is almost meaningless. The actual risks are distributed across each action: whether the exported file contains data beyond the authorized scope, whether the recipient is correct, whether prompt injection has been embedded in the page, and whether the download URL redirects to another domain.

Per-call verification is closer to a reference monitor in an operating system: every sensitive operation passes through the same checkpoint, which then decides whether to allow it, reject it, or escalate it for human confirmation. Conceptually, it can be written as:

for each browser_action:
    context = current_page + session + action + policy
    verdict = verify(context)

    if verdict == allow:
        execute(browser_action)
    else if verdict == confirm:
        request_human_approval()
    else:
        block_and_log()

This is not Hwatu’s actual API or configuration syntax, but rather the execution model it represents. The key is not simply wrapping calls in another function. The verifier must have sufficiently complete context while remaining resistant to malicious content on the webpage.

The most dangerous input to a browser agent comes from the web itself

Browser agents have a structural problem: the objects they observe are inherently untrusted.

Webpages can embed instructions in body text, hidden nodes, images, ARIA labels, or even dynamic scripts—for example, telling the model to ignore the original task, read information from other tabs, or send page data to an external site. From the model’s perspective, both user instructions and webpage text may ultimately enter the same context. If the tool layer does not label their origins, prompt injection is no longer merely a matter of “the model giving the wrong answer”; it can directly translate into browser actions.

More mature browser agent tools have begun to provide several kinds of boundary controls:

• Using content-boundary markers to distinguish tool output from untrusted webpage content;
• Restricting cross-site access through domain allowlists;
• Constraining sensitive actions such as downloads and script execution with static policies;
• Requiring human confirmation for high-risk operations;
• Limiting the length of page output to prevent malicious content from flooding the context.

These capabilities are useful, but most are static guardrails. Static rules are good at determining whether a domain may be accessed or whether downloads are allowed. They are less effective at understanding whether a particular download aligns with the current task or whether a specific submit button will send data to an unintended recipient.

The value of the real-time verification approach represented by Hwatu lies in its attempt to evaluate the action, page state, and task context together. It does not replace allowlists; it supplements the dynamic coverage that allowlists cannot provide.

Ideally, the two should be used together:

| Layer | Best suited to handling | Characteristics | |---|---|---| | Browser sandbox | File, process, and network isolation | Lowest level, with clear boundaries | | Static policies | Domains, action types, and permission scopes | Fast and auditable | | Real-time verification | Whether the current action aligns with the task intent | Richer context | | Human confirmation | Irreversible actions such as payments, sending, and deletion | Expensive, but with clear accountability | | Post-hoc auditing | Tracing behavior and reviewing incidents | Cannot prevent side effects that have already occurred |

Entrusting every problem to a single verifier model is no more reliable than entrusting every problem to the primary agent.

13ms also reveals another reality

If a check can truly be kept consistently within 13ms, it is unlikely to rely on full remote inference by a large language model. Ordinary network round trips, queuing, and model generation alone could easily exceed that figure.

This means low-latency verification is more likely to depend on one or more of the following mechanisms:

• Local or in-process rule matching;
• Structured validation of call parameters;
• Policy decisions based on domains, actions, and permissions;
• Caching previously verified contexts and policy results;
• Small classifiers or other lightweight decision modules;
• Reserving complex semantic verification for a small number of high-risk actions.

This is, in fact, a more realistic architecture. A security system should not use an expensive large model to inspect every scroll, focus event, and routine click. A more sensible approach is to perform fast risk classification first, then send high-risk calls to a slower, more capable verifier.

For example, reading a public webpage could be allowed immediately; visiting a new domain could require a quick check; uploading a file could trigger semantic verification; and final actions such as sending, paying, or deleting should require human confirmation. This preserves the agent’s operating speed while preventing verification costs from scaling uncontrollably with the number of actions.

The real challenge is not latency, but what the verifier can see

For Hwatu, 13ms is a highly shareable metric, but four questions matter more.

1. Can it resist prompt injection?

If the verifier and the executing agent read the same unsegregated webpage content, they may both be compromised. Having a second model review the first model does not inherently create a security boundary.

The verifier must clearly distinguish among the user’s objective, system policies, webpage data, and the action proposed by the agent. Webpage content may serve only as evidence; it must not have the authority to modify the verification rules.

2. Can it prevent state changes between inspection and execution?

If a button points to A during verification but a page script replaces it with B before execution, that is a classic time-of-check to time-of-use inconsistency, or TOCTOU problem.

For the verification layer to be genuinely reliable, it should bind its decision to a specific page state, element reference, and set of call parameters, then confirm before execution that no critical state has changed. Otherwise, even the fastest check may verify an object that no longer exists.

3. Does it cover indirect side effects?

A seemingly ordinary click may trigger a redirect, download, clipboard write, or background request. If the verifier reviews only the surface-level click instruction without observing the actual network and browser side effects, its coverage will be very limited.

4. Does it allow or deny by default when errors occur?

In production environments, verifier timeouts, crashes, and uncertain results are not uncommon. High-risk actions should fail closed, meaning they should be denied when verification fails. Low-risk read actions may degrade gracefully depending on business requirements. Applying one rule to every action will make the agent either unsafe or unusable.

It is not competing in the same category as existing browser automation tools

AI-native browser tools such as Vercel’s agent-browser focus on helping agents observe and control browsers more efficiently: compressing the DOM into structured snapshots, locating elements through stable references, reducing multi-turn call overhead through batching, and providing domain and action policies.

Hwatu’s entry point is narrower and later in the pipeline: rather than helping the agent understand the page, it reviews what the agent intends to do next.

The two types of tools do not conflict. A complete browser agent stack may require all of the following:

• A browser runtime for actual execution;
• A page abstraction layer for compressing the DOM, screenshots, and accessibility tree;
• An agent control layer for the Observe → Think → Act loop;
• A verification layer that inspects tool calls individually;
• An audit layer that records page state, decision rationale, and execution results.

Judging by industry progress, the first three layers are already relatively crowded, while the last two are only beginning to emerge as standalone products. As agents move from web testing into enterprise administration, customer service, procurement, and financial workflows, verification and auditing will no longer be optional features—they will become procurement requirements.

Is it worth integrating now? Try it, but do not rush to entrust it with production permissions

As of July 29, Hwatu appears more like a promising early-stage open-source project worth evaluating than security infrastructure that has been proven in large-scale production deployments.

Developers should focus on testing three questions:

1. Under their own action distributions, what are the P50, P95, and P99 latencies—not just the single 13ms figure?
2. For prompt injection, cross-domain redirects, file uploads, and irreversible operations, what are the false-allow and false-block rates?
3. Can verification results be reproduced consistently, and do they provide sufficiently clear audit records?

Our assessment is that the direction matters more than the number.

Competition among browser agents has so far focused primarily on success rates—whether they can click the right elements and complete tasks. The next stage of competition will shift toward controllability—why the agent clicked something, which actions it must never take, and whether it can stop before side effects occur when something goes wrong.

The 13ms figure does not prove that Hwatu has solved browser agent security. But placing verification in the hot path of every tool call is a more credible engineering direction than simply “asking the model to reflect again.” For agents that only search public webpages, this layer may seem unnecessary. For agents that hold real authenticated sessions and can download files and submit forms, it will eventually become standard.

References

• Hwatu GitHub repository: Project code, design documentation, and the latest development updates; the primary source for the article’s information about the 13ms window and one-call checks.