Guide 06 / Web security · 2026-09-09

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.

Outcome. You will create a session for a system you own or are explicitly authorized to test, inventory its exposed endpoints, change and replay one captured request, compare the response, and close the session with its evidence intact.
An authorized target is reached through a policy-controlled browser session while credentials, localhost services, and unrelated sites remain outside its authority
Scope should be executable, not a sentence in a prompt. The session policy decides which origins the browser can reach; the ledger records what it learned inside that boundary.

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

host
$ curl -fsSL https://h5i.dev/install.sh | sh -s -- --websec --recon
$ h5i plugin list

Check: 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

host
$ 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

host
$ h5i browser snapshot
$ h5i recon extract
$ h5i recon known
$ h5i recon endpoints --json

extract 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

host
$ h5i recon crawl --max-requests 200 --rate 4
$ h5i recon triage --calibrate
$ h5i recon endpoints --state confirmed --json

The 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

host
$ 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 ok

Choose 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

host
$ h5i browser audit
$ h5i recon export --out endpoints.jsonl
$ h5i browser close

Keep 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

Reference

Questions that come up

Can I use h5i for CTFs?
Yes, when the CTF rules permit automation. A target-scoped session, bounded crawl, endpoint ledger, and request replay fit web challenges particularly well.
Is h5i a vulnerability scanner?
No. It records browsing, discovery, and HTTP experiments. It deliberately ships no scanner, exploit library, payload generator, or wordlist.
Can h5i enforce a pentest scope?
It can enforce allowed network destinations and request budgets, but it cannot encode every rule of engagement or establish legal authorization.
Choose the workbench

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.