Run an authorized web security test with an AI agent
An offensive-security agent needs room to investigate and a hard edge around the assignment. This workflow gives it both: one target-scoped session, a bounded discovery ledger, an HTTP workbench, and a record you can review.
Before you start: write down authorization
Use this guide only for a CTF target, lab, bug-bounty asset, or application whose owner has authorized the test. Record the permitted hosts, accounts, techniques, request rate, and time window before running an agent. h5i can enforce destinations and bound a crawl, but it cannot decide whether you have permission.
This walkthrough uses https://target.example as a placeholder. Replace it only with an in-scope host. Start conservatively: a single origin, four requests per second, and no path wordlist until the target rules allow it.
1. Install the HTTP and recon plugins
$ curl -fsSL https://h5i.dev/install.sh | sh -s -- --websec --recon
$ h5i plugin listCheck: the list identifies websec as the HTTP workbench and recon as the endpoint ledger. They are optional plugins, so a default h5i install does not imply they are present.
2. Open a captured, target-scoped session
$ h5i browser open https://target.example --capture --allow target.example
$ h5i browser status--capture keeps request and response bodies because replay needs the exact message. That store can contain credentials and personal data. Treat it as sensitive test evidence and do not export it casually.
Check: status names the intended target and the request log. If the application legitimately uses another origin, add that origin explicitly after confirming it is in scope; do not replace the allowlist with unrestricted egress.
3. Observe before you enumerate
$ h5i browser snapshot
$ h5i recon extract
$ h5i recon known
$ h5i recon endpoints --jsonextract reads URLs already disclosed by pages and bundles. known checks conventional files such as robots.txt, sitemap.xml, and security.txt. Discovery and testing remain separate: a candidate endpoint is not called a vulnerability.
Check: every observed endpoint names the message that supports it. A candidate is only a lead; confirmed means its answer differs from the calibrated missing-path response.
4. Run bounded reconnaissance
$ h5i recon crawl --max-requests 200 --rate 4
$ h5i recon triage --calibrate
$ h5i recon endpoints --state confirmed --jsonThe request ceiling and rate are part of the test, not tuning trivia. They prevent an autonomous crawler from silently turning a small assessment into a load event. h5i ships no payloads or wordlists; if the rules permit path discovery, you provide the reviewed input with recon paths --wordlist.
Check: inspect h5i recon jobs list and the endpoint states. A refused row means policy declined the request; it does not mean the endpoint is absent or safe.
5. Inspect and replay one HTTP request
$ h5i websec requests
$ h5i websec show req_42 --raw
$ h5i websec replay req_42 --set query.id=456
$ h5i websec diff res_42 res_43
$ h5i websec match res_43 --status 200 --contains okChoose a request permitted by the rules of engagement and change one field at a time. Replay travels through the same session policy and record as browsing; it is not a side channel around scope. The response diff is evidence of a difference, not proof of impact.
Check: verify the replay appears in the session and that the destination did not change. Escalate only after a person confirms the observation and the next action remains authorized.
6. Audit, report, and stop
$ h5i browser audit
$ h5i recon export --out endpoints.jsonl
$ h5i browser closeKeep three categories distinct in the report: observed HTTP facts, recon state, and the agent's interpretation. Include request identifiers so another reviewer can trace a claim back to a message. Redact captured secrets before sharing any artifact.
Stopping point: the session is closed, no new requests can be issued under its identity, and its ending is recorded. Do not leave a captured authenticated session live after the authorization window ends.
What this workflow does not do
- It does not grant authorization or infer scope from a URL.
- It does not provide a vulnerability scanner, exploit library, payload generator, or built-in wordlist.
- It does not make agent conclusions trustworthy. Message records support observations; severity and exploitability still require review.
- It does not match every browser API. Run Chromium inside an h5i box when compatibility matters more than engine-level capture.
Reference
- HTTP workbench commands
- Recon ledger and endpoint states
- Browser session policy and audit
- AI pentesting tools compared
- Burp Suite vs h5i for AI agents
Questions that come up
Can I use h5i for CTFs?
Is h5i a vulnerability scanner?
Can h5i enforce a pentest scope?
Burp Suite vs h5i for AI agents
Compare a mature human-led proxy platform with an agent-native, policy-controlled session.
Test only what you are allowed to test
Start with one origin, an explicit request budget, and a captured session you can audit.