h5i: a Rust browser for AI agents that logs every request it refuses

The problem h5i is aimed at, and the two audiences it splits between

Giving an AI agent a browser means handing it a channel that returns untrusted text and a process that can reach any host on the network. h5i's README frames the goal as reducing the risks of giving agents web access, and names four controls: network policies, sandboxing, credential isolation, and auditable sessions. The same controls are then pointed in the other direction, at authorized security testing, CTFs, and red teaming. So one binary serves an agent browsing docs.rs and an operator replaying a request against a target they own. That is an unusual pairing, and it is the first thing to weigh. The agent-facing side wants a small, predictable surface that a model can call. The testing side wants to edit and resend arbitrary HTTP. h5i reconciles them by making the browser own its own network layer, which is what lets it both refuse a request and record the refusal. If you only need one of those two jobs, part of the CLI is dead weight for you, and the README does not say which parts are optional beyond the two plugins.

Pure Rust with no Chromium or V8, and what that costs

The README states the project is pure Rust and carries no Chromium or V8. The comparison table on the repository page claims roughly 3x faster and roughly 86% less memory, and links to a design document at docs/design/design-browser.md. Those numbers come from the project's own benchmarks, not from an independent run, and the README does not describe the machine, the pages, or the workload behind them. Treat them as a claim to reproduce on your own corpus. The architectural consequence is more interesting than the number. Without a JavaScript engine, h5i cannot execute page scripts, so the `snapshot` and `markdown` commands can only report what the fetched documents and bundles contain. For scraping server-rendered pages or documentation sites, that is sufficient and the memory profile is the payoff. For an application that renders its content client-side, the page outline will be thin. The README does not state how much JavaScript, if any, h5i evaluates, and I could not confirm that from the supplied material.

Sessions: one page state, one cookie jar, one policy, one request record

The unit of work in h5i is a session. The README defines it as combining one page state, a cookie jar, a network policy, and a request record. That bundling is the design decision everything else rests on. Because the policy and the request log live inside the same session as the page, `h5i browser requests` can show both what the page asked for and what was refused, and `h5i browser audit` can report the whole session: verbs, fetches, handovers, and the ending. A stateless fetch API cannot produce that artifact, because there is no session to attribute a refusal to. The same structure serves the testing commands, where `h5i websec requests` lists captured messages with IDs and `h5i websec show req_42 --raw` prints one. Sessions are also bounded by construction: `h5i browser open` takes an `--allow` flag, and the README's example passes a single host. `h5i browser close` ends the session. There is a one-shot alternative, `h5i browser read`, for a single page without a persistent session, but the README does not say whether that path records requests the same way.

Policy, sandboxing and the audit trail

This is the part that distinguishes h5i from a general automation library, and also the part where the README is thinnest. The README says web content is untrusted input to an AI agent, and that h5i applies a network policy and records both allowed and denied requests. The commands are concrete: `h5i browser requests` for allowed and denied network requests, `h5i browser audit` for actions, fetches, handovers and session ending, and `h5i browser status` for isolation, policy digest and network placement. The `--allow docs.rs` flag on `open` shows the allow-list is set per session. What the README does not give is the policy file format, whether allow rules match by host, origin or path, whether a denied request fails the command or returns an error the agent can read, and what a policy digest is computed over. The skill command `h5i skill show policy` is described as a way to read a page, which suggests the policy semantics are documented in the shipped skill rather than in the repository README. If you are evaluating h5i for a security decision, that skill page is the document you need, and you should read it before trusting the word sandboxing. The README also describes credential isolation as a control but does not show the command or config key that implements it.

Getting it running: installer, cargo, and the two plugins

The README gives three install paths. The default is `curl -fsSL https://h5i.dev/install.sh | sh`. If you would rather not add a domain to the chain, the README offers the same script from raw.githubusercontent.com, or `cargo install --path .` to build from source. The agent-facing interface is distributed separately as a skill: `npx skills add h5i-dev/h5i` if you do not have the binary yet, or `h5i skill install` to write it where your runtime looks. The `websec` and `recon` plugins ship as their own archives and are not part of the base install. To get them in the same pass, the README shows `curl -fsSL https://h5i.dev/install.sh | sh -s -- --websec --recon`, after which `h5i plugin list` reports what is installed. That split matters for maintenance: three artifacts (the binary, the skill, and each plugin archive) can move independently, and the README does not state whether plugin versions are pinned to the core binary. The piping-to-shell installer is a normal pattern for this kind of tool and still means you are executing a remote script; the README's own alternative, building with cargo, avoids that.

The websec plugin and what it replaces

The README's claim for the testing side is that because h5i owns the browser's network layer, agents can capture, inspect, edit, replay and compare HTTP traffic without a MITM proxy, CA certificate, or separate repeater. That is a real difference from the common setup, where an intercepting proxy sits between the browser and the target and you install a CA certificate so the proxy can read TLS. h5i removes the proxy from the path because it is already the client. The commands are `h5i websec requests` to list messages and IDs, `h5i websec show req_42 --raw`, `h5i websec replay req_42 --set query.id=456` to edit and resend, `h5i websec diff res_42 res_43` to compare two responses, `h5i websec match res_43 --status 200 --contains "ok"` to assert a condition, and `h5i websec sequence flow.json` to run a multi-step test. The trade-off is the mirror image of the proxy: a proxy sees traffic from any client you point at it, while h5i only sees traffic from h5i. If your test needs a mobile app, a native client, or a browser h5i cannot render, the proxy remains the tool. The README also repeats an authorization warning around this section, which is the right place for it.

Recon keeps discovery separate from testing, and says why

The recon plugin is deliberately kept apart from websec. The README's phrasing is that recon says what exists and how it knows. The mechanism behind that phrase is provenance: `h5i recon endpoints --state confirmed --json` returns an inventory where each row names the message that proves the endpoint exists. That is a stronger design than an endpoint list on its own, because a finding you cannot attribute to a captured request is a finding you cannot defend in a report. The commands are `h5i recon extract` for endpoints disclosed by pages and bundles, `h5i recon known` for robots.txt, sitemap.xml and security.txt, `h5i recon crawl --max-requests 200` to walk the site under the session's login, and `h5i recon triage --calibrate` to fold soft 404s and confirm the rest. The bounded crawl is the notable constraint: `--max-requests` and `--rate` cap the walk, and the README's example uses 200 requests at 4 per second. The calibration step is the one to scrutinize, since it is what separates a confirmed endpoint from a page that returns 200 for everything. The README does not describe the calibration method, so you cannot tell from this material how it distinguishes a soft 404 from a real page.

Where h5i is the wrong tool, and what to check before adopting

Two cases point away from h5i. The first is a JavaScript-heavy application where the rendered DOM is the thing you need. With no V8 or Chromium, the page outline and markdown output depend on what the server sent, and the README does not claim otherwise. The second is any workflow already built on the Chrome DevTools Protocol or on an existing Playwright or Puppeteer suite. h5i exposes a CLI surface with its own verbs, `@e3` element handles, and session model; there is no indication in the README that it speaks CDP, so existing scripts would need rewriting against a different interface. On maintenance, the release cadence visible in the supplied material is three releases in eight days in September 2026, which suggests active development and also a moving interface at 0.x. The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant; that is a permissive licence, and it is not legal advice. Two things to verify first. Read `h5i skill show policy` and confirm the allow-list semantics match your threat model, since the README shows the flag but not the rules. Then run `h5i plugin list` after `--websec --recon` and check whether the plugin versions track the core binary or drift, because the README does not say.

Editorial conclusion

Adopt h5i if you need an agent to reach the web under a policy you can read back afterwards, or if you are doing authorized testing and want capture and replay without standing up a MITM proxy. Do not adopt it if you need a full rendering engine for a JavaScript-heavy application or a browser you can drive through the Chrome DevTools Protocol. Before installing, verify the policy semantics in the README's `policy` skill page, confirm whether the `websec` and `recon` plugin archives are versioned in step with the core binary, and check what the installer writes to disk when you pass `--websec --recon`.

Official sources

1. h5i-dev/h5i on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases