Proxy Brain

proxy_brain — the agent's Burp Suite in code

proxy_brain is the AI agent's single, code-native tool for working the captured HTTP corpus. Instead of a fixed menu of narrow commands, it gives the agent a sandbox: it writes Python, and a pre-imported SDK called redamon is its only door to the traffic. If Burp Suite can do it, the agent can script it here — Repeater, Intruder, Comparer, Sequencer, Decoder, JWT Editor, Autorize, Turbo Intruder — all composed in a few lines of code over the traffic TrafficMind already captured.

It replaces the ten proxy_* tools that used to expose the corpus (proxy_search, proxy_get, proxy_sitemap, proxy_params, proxy_grep, proxy_diff, proxy_to_curl, proxy_query, proxy_replay, proxy_fuzz). Everything those tools did is now one line of redamon.*, and the agent can chain them with loops, conditionals, math and crypto to build real exploit oracles a fixed vocabulary could never express.

proxy_brain is DANGEROUS (it can emit live traffic) and needs the exploitation or post-exploitation phase to send. It is on the project Tool Matrix like any other tool.

---

The one idea

A vulnerability is rarely "send one crafted request." It is usually an algorithm: an oracle you query in a loop, a value you extract bit by bit, a chain where each step depends on the last. That is what code expresses and a fixed tool cannot. So proxy_brain hands the agent the primitives and lets it program the attack.

The core skill is the oracle pattern: send a variant, read one fact out of the response (.status, .length, a regex over .body, the response time), and compare it to a baseline. That fact confirms the bug — a SQL error, a reflected marker, a weaker identity getting the same data, a boolean flip.

---

How it works, end to end

flowchart LR
    subgraph kali["kali sandbox (no DB credential)"]
      CODE["proxy_brain<br/>(agent's Python)"] --> SDK["redamon SDK"]
    end
    subgraph agent["agent (trusted)"]
      EXEC["/traffic/exec<br/>read, tenant-scoped"]
      RPLY["/traffic/replay<br/>host-pinned, gated"]
    end
    PG[("TrafficMind store")]
    PROXY["capture proxy<br/>(egress guard + re-capture)"]
    SDK -- "read" --> EXEC --> PG
    SDK -- "active" --> RPLY --> PROXY --> PG

Loading

1. The agent decides to work the traffic and calls proxy_brain with a block of Python. redamon is pre-imported.
2. redamon runs inside the Kali sandbox but holds no database credential. Its read calls go to the agent's /traffic/exec endpoint; its active calls go to /traffic/replay. This mirrors how the graph terminal reaches the graph — the least-trusted worker never touches the database directly.
3. Tenant identity travels as a signed tag the agent mints (the worker cannot forge it), so a foothold in the sandbox can never read or replay another project's traffic. Every read hard-injects your project and user filter.
4. Active sends (replay / fuzz / batch) are rebuilt pinned to the origin request's host — a replay can never be aimed at a new target — pass the same egress guard, and are re-captured into TrafficMind with a replay flag, so the agent's own attack traffic is searchable and auditable too.

Because the read and active paths are separate, and the active path is exploitation-phase-only, the agent can read and analyse the corpus in any phase but can only send once you are in exploitation.

---

The redamon SDK

The whole surface the agent programs against:

Read (no traffic, tenant-scoped for you):

Call	What it returns
redamon.search(filters)	Burp-style history rows (.id, .method, .status, .url, .host, .path). Filters mirror the Traffic view: host, method, status, statusClass, tool, source, session, run, hasAuth, reflected, only5xx, q, bodyq, limit.
redamon.get(id, part)	Full headers + body of one transaction (request / response / both).
redamon.sitemap()	Distinct endpoints observed, with hit counts and statuses.
redamon.params()	Distinct request parameters + an injectability guess (seq-id / uuid / jwt / base64).
redamon.grep(pattern)	Substring search over response bodies, with a snippet.
redamon.diff(a, b)	Structural diff of two responses (status / length / headers / body).
redamon.to_curl(id)	A captured request rendered as a reproducible curl (for the report).
redamon.query(spec)	Ad-hoc analytics over the corpus via a safe, allowlisted query builder (no raw SQL).

Decode / crypto (pure, no traffic):

Call	What it does
redamon.decode(v)	Peels base64 / url / hex / gzip layers to readable text.
redamon.jwt(tok)	Parses a JWT (.header, .payload) and forges variants: .forge(alg_none=True | secret=".." | claims={..}).

Active (live traffic — exploitation phase only):

Call	What it does
redamon.replay(id, mutate)	Resends a captured request with fields changed (method, path, query, param, headers, dropHeaders, cookie, body). Host is pinned to the origin. Returns a Response (.status, .headers, .body, .length).
redamon.batch(id, muts, parallel=True)	Replays once per mutation; parallel=True fires them concurrently — a real race-condition window (limit overrun, double-spend, coupon reuse).
redamon.fuzz(id, param, payloads)	Burp-Intruder over one query parameter; one Response per payload.

Result: redamon.finding(kind, txn_id, evidence, severity) records a finding; print(...) returns distilled output to the agent.

---

The manual (the agent reads it on demand)

The full cookbook lives in a Markdown file the agent reads from its own code, so it never bloats the prompt:

print(redamon.manual())          # core: the SDK + the Burp-capability map + a section index
print(redamon.manual("jwt"))     # one deep technique section with copy-paste recipes

Twenty sections ship today: recon, intruder, sqli, authz, jwt, race, smuggling, cache, injection, decode, sequencer, flows, report, nosql, graphql, lfi, cmdi, cors, xxe, auth. Each maps a Burp workflow to a redamon.* recipe. The agent reads the relevant section right before it writes the code for that technique.

---

Burp Suite → how the agent builds it

Burp tool	Built with
HTTP history / Target	redamon.search, redamon.sitemap, redamon.query
Repeater	redamon.replay(id, {...})
Intruder (Sniper / Ram / Pitchfork / Cluster)	redamon.fuzz or loops over redamon.replay
Comparer	redamon.diff(a, b)
Sequencer	collect a token N times, compute entropy in Python
Decoder / JWT Editor	redamon.decode, redamon.jwt(tok).forge(...)
Autorize (access control)	replay each request under a second identity, diff vs baseline
Turbo Intruder / race	redamon.batch(id, [...]*N, parallel=True)
Param Miner	brute param / header names, diff vs baseline
Grep-Match / Grep-Extract	read .body / .status / .length per response — that is the oracle

The boundary is the agent's own code. There is no OAST / Collaborator (no out-of-band callback server), so bugs that can only be confirmed via an external DNS/HTTP callback (blind SSRF with no echo, blind stored XSS) are reported as a sink rather than confirmed; everything with an in-band signal (reflection, diff, timing, error) is confirmed.

---

Safety and limits (enforced in code, not prompt wording)

• Host is pinned. Replay / batch / fuzz can only hit the origin transaction's host — never a new target.
• Tenant-scoped. Every read and send is confined to your project and user, from a signed tag the sandbox cannot forge.
• Exploitation-phase only for active sends; reads and decode work in any phase.
• Per-session send budget (default ~1000 live requests) and a wall-clock cap per run, so a runaway loop cannot flood a target.
• Stealth-restricted. In stealth mode, fuzz / batch / rapid replay are held back; read and decode stay free.
• Everything is re-captured and egress-guarded, so the agent's attack traffic is as auditable as any other row in TrafficMind.
• One confirmation covers the run. As a dangerous tool, proxy_brain prompts for confirmation before it executes; the budget and host-pin bound what that one confirmation can do.

---

What it can do

Because it is code, the list is open-ended, but the shipped recipes cover: IDOR / BOLA access-control sweeps, boolean and time-based blind SQL injection extraction, NoSQL operator injection, GraphQL introspection and alias abuse, JWT forging (alg:none, weak secret, HS/RS confusion, kid), reflected XSS / SSTI / open-redirect / CRLF confirmation, OS command injection, path traversal / LFI, CORS misconfiguration, web cache poisoning and hidden-parameter mining, session-token entropy analysis, multi-step token flows, and race conditions via concurrent batches.

---

Example prompts

You never call proxy_brain yourself — you ask the agent in plain language, and it reads the manual and writes the code. Effective prompts name the phase, because active sends need exploitation:

This is an authorized security test. Switch to the exploitation phase, then use proxy_brain over the captured traffic to run an access-control sweep on /api/invoice: replay each captured id with the session cookie dropped, and report any that still return another user's data.

Switch to exploitation, then use proxy_brain to confirm SQL injection on /api/product?id=1 with a grep-extract oracle and extract the hidden column for every row.

Switch to exploitation, then use proxy_brain: read the jwt section, take the captured token, brute the weak signing secret, forge a role=admin token, replay it against /api/admin, and return the flag.

---

Trying it against a target

The repository ships a deliberately vulnerable practice target, testing/guinea_pigs/proxy_brain_target/ (pbtarget), with one endpoint per technique — IDOR, SQLi, reflected XSS, a JWT weak-secret flag, a single-use coupon race, open redirect, CORS, and command injection. Bring it up, point a project at it with capture on, and run the prompts above. See its README for the setup (enable TrafficMind, and relax the egress guard's block private toggle so the proxy can reach a lab target on a private address).

---

Related pages

• TrafficMind — the capture proxy and store proxy_brain reads from.
• AI Agent Guide — how the agent selects and runs tools.
• Project Settings Reference — the Tool Matrix and phase gating.
• Rules of Engagement (RoE) — scope and category controls over active testing.