TrafficMind
TrafficMind is RedAmon's AI-aware HTTP capture layer. It records every HTTP
request and response that your reconnaissance tools and your AI agent send to a
target, tags each one with the scan run and tool that produced it, and gives you a
searchable history you can browse, export, and hand to the agent. What sets it
apart from a plain proxy log is the mind: the same captured corpus is wired into
the AI agent through ten proxy_* tools, so it can reason over the traffic,
search and diff responses, and even replay and fuzz requests. Think of it as a
built-in Burp Suite HTTP history that turns itself on with a toggle, attributes
every request to its source, and is queryable, and actionable, by the agent
itself.
Operator guide vs. technical whitepaper. This page is the operator-facing guide: what the feature does, how to turn it on, what each setting means, and how to use the
/trafficview and the agent's traffic tools. If you want the architectural deep dive (the credential-free capture proxy, the signed context tag, the append-only spool, the trusted ingest worker, the database schema, the full trust model, and every code reference) read the TrafficMind: Technical Reference in the project repository.
When capture is on, RedAmon routes your offensive tools through an internal man-in-the-middle proxy. For every transaction the proxy records:
- The full request: method, URL, headers, and body.
- The full response: status, headers, body (up to a size cap), and timing.
- Attribution: which project, which scan run or agent session, and which tool produced it (recon or agent, katana / nuclei / curl / httpx / playwright, and so on).
- Passive findings, for free: reflected parameters (an XSS / SSTI / open-redirect lead), missing security headers, cookie-flag problems, and whether the request carried authentication.
Everything lands in a TrafficMind view you reach from the top navigation, where you
can filter, inspect, export, and delete. The same corpus is exposed to the AI
agent through a set of proxy_* tools so it can review, hunt, and even replay
requests without leaving the platform.
Capture is off by default. Nothing is recorded until you explicitly enable it.
flowchart LR
TOOLS["your tools<br/>(recon crawlers + agent)"] --> PROXY["capture proxy"]
PROXY --> TARGET["target"]
TARGET --> PROXY
PROXY --> STORE[("TrafficMind store")]
STORE --> UI["TrafficMind view<br/>(you)"]
STORE --> AGENT["proxy_* tools<br/>(the agent)"]
Capture uses a two-level switch. Both levels must be on for a project to be recorded. This lets you keep the machinery running once while choosing capture project by project.
Go to Global Settings and find the TrafficMind card. Flip the master toggle on. This starts the capture proxy and ingest containers. Turning it off stops them.
When enabled, a row of runtime options appears (see the settings table below).
Routing is decided per project: it controls whether this project's traffic is sent through the running proxy. Enable or disable it per project in Global Settings → TrafficMind → Per-project routing: a matrix of all your projects, each with its own toggle. It appears when the master switch is on, and is admin-only (like the rest of the TrafficMind card).
The TrafficMind page top bar shows the current project's capture status (Enabled / Disabled), read-only. When it is disabled, it points you to Global Settings to turn it on for that project.
Changes apply immediately and take effect on the project's next session.
Rule of thumb: the master switch runs the proxy; the per-project toggle decides which projects use it. If you enable a project but the master switch is off, nothing is captured.
All settings live in the TrafficMind card in Global Settings. The card is admin-only: it is hidden from non-admin operators, and the API rejects capture-config writes from non-admins (defense in depth).
These are global settings. There is a single shared capture proxy serving every user and every project, so the master switch, container config, and egress guard propagate to all of them. A change here applies to everyone, and the last save wins. The one exception is the per-project routing matrix, which is per-project (see below).
| Setting | Default | What it controls |
|---|---|---|
| TrafficMind (master) | Off | Starts / stops the capture proxy and ingest containers. |
| Listen port | 8888 | The port the proxy listens on. Change only if 8888 conflicts. |
| Scope | Recon + Agent | Which producers route through the proxy: Recon + Agent, Recon only, or Agent only. |
| Inline body cap (KB) | 64 | Bodies at or below this size are stored inline; larger ones are offloaded to a content-addressed blob store and referenced by hash. |
| Retention (days) | 14 | How long transactions are kept before the maintenance job purges them. Set to 0 (or less) to keep forever. See the retention note below. |
| Store bodies | On | When off, only sizes and hashes are kept, never the body content. Use this if you want the metadata trail without storing payloads. |
| Redact secrets | On | Replaces sensitive header values (Authorization, Cookie, Set-Cookie, API keys) with a salted hash before storage, so identical secrets still correlate without keeping the plaintext. |
| Passive detections | On | Computes the reflected-parameter / security-header / cookie-flag signals on each response. Turn off to reduce processing on very high-volume scans. |
The per-project routing toggle (in the Per-project routing matrix under this same card) has no sub-options: it is purely the on/off routing gate for that project. The TrafficMind page top bar only displays that project's routing status (Enabled / Disabled); it is read-only.
The capture proxy is a new outbound path, so it ships with an egress guard
that stops it being abused as an SSRF
pivot into RedAmon's own internal network (its database, the cloud metadata
endpoint, etc.). Any request the guard refuses gets a synthetic 403 and is
never forwarded; the attempt is still recorded for the audit trail.
The Egress guard block (shown under the TrafficMind card when the master switch is on) exposes each block condition as its own toggle. Every toggle defaults to block: out of the box the guard behaves exactly as before. Turn one off only to deliberately allow that class of destination. Each toggle carries an info tooltip explaining precisely what it refuses.
| Toggle | Default | Blocks (when on) |
|---|---|---|
| Private IPs (RFC1918) ⚠ | Block |
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, IPv6 ULA. Turn off to reach an internal / lab target on a private network (e.g. a container on a 172.x Docker bridge). See the warning below. |
| Link-local IPs | Block |
169.254.0.0/16, fe80::/10. Includes the cloud metadata endpoint 169.254.169.254, a classic credential-theft SSRF target. |
| Loopback IPs | Block |
127.0.0.0/8, ::1 (the proxy host itself). |
| CGNAT (100.64/10) | Block |
100.64.0.0/10 carrier-grade NAT space. |
| Reserved ranges | Block | IANA-reserved address ranges. |
| Multicast | Block |
224.0.0.0/4, ff00::/8. |
| Unspecified (0.0.0.0 / ::) | Block | The unspecified addresses. |
| Sensitive hostnames | Block |
.gov / .mil / .edu / .int domains + the built-in hard-guardrail denylist. |
| Unresolvable hosts | Block | Hosts that do not resolve / have a bad IDNA label. Structural: with no IP there is nothing to connect to, so these are never forwarded regardless. |
| Empty host | Block | Requests with no Host. Structural, as above. |
| Fail closed on guard error ⚠ | Block | If the guard itself errors, refuse (safe). Turning this off makes it fail-open: forwarding without vetting or IP pinning. Dangerous; leave on. |
⚠ Security: the private-IP toggle. The guard cannot tell an authorized private target (a lab box on
172.x) from RedAmon's own services on the same ranges. When you turn off Private IPs, the proxy can reach any private address it can resolve, including RedAmon's database and other internal services. Before relaxing it, pin RedAmon's own service IPs in the environment denylistCAPTURE_BLOCKED_IPS(that denylist is always enforced, regardless of these toggles), so unblocking private targets can never turn the proxy into an SSRF pivot into RedAmon itself. Relax the narrowest set of checks you need, and turn them back on when the engagement is done.
Toggles are applied to the running proxy when you Save: the orchestrator recreates the proxy container with the new policy (a few seconds).
Open TrafficMind from the top navigation. You get a paginated, Burp-style table of every captured transaction for the current project.
Time, Source (a recon or agent badge), Tool, Method, Host, Path, Status
(colored by class, or BLK if the proxy blocked it), Length, response Time, and
Flags (chips for reflected input, set-cookie, replay, and out-of-scope).
- Date range (From / To)
- Source: both, recon, or agent
- Tool and Host (populated from what you actually captured)
- Method and Status class (2xx / 3xx / 4xx / 5xx)
- Run: narrow to a single scan run
-
Search URL (
q): substring match on the URL -
Search bodies (
bodyq): substring match inside response bodies - Set-Cookie and 5xx only checkboxes
Click any row to open a detail drawer with the full request and response (headers and body). Response bodies are always rendered as inert text, never as live HTML, because they come from the target and are untrusted. Use Copy as curl to grab a reproducible command for the request.
Export the current filtered set as CSV or JSON. Exports are capped (50,000 rows) and the file is marked if it was truncated, so you always know whether you have the whole set. CSV values are guarded against spreadsheet formula injection.
Delete selected rows, or delete everything matching your current filters. Deleting a transaction also cleans up its offloaded body blobs (reference-counted, so a body shared by another kept transaction is not removed).
When capture is active for a project, RedAmon adds a proxy setting plus a signed attribution tag to each supported tool. The tag identifies the tenant and is verified before anything is stored, so a target can never forge or read it.
Recon tools routed: katana, nuclei, ffuf, hakrawler, kiterunner, arjun.
Agent tools routed: execute_curl, execute_httpx, execute_playwright,
execute_nuclei, execute_katana, execute_ffuf, execute_arjun,
execute_wpscan. So when the agent crawls, fuzzes, or scans a target, that
traffic is captured too, and becomes searchable and replayable through the
proxy_* tools. OSINT and passive tools (subfinder, naabu, gau, web search, graph
queries) are not routed and produce no traffic records, by design.
Not captured: kali_shell and execute_code run arbitrary commands or code,
so the platform cannot force their traffic through the proxy. If you need a
request captured, prefer a first-class tool (execute_curl, execute_httpx,
execute_nuclei, and so on) over a raw shell command.
Fail-open: if the proxy is enabled but unreachable, tools run directly against the target and simply are not captured. A scan is never blocked or slowed by capture. The tradeoff is that an unreachable proxy is a silent gap in the record, not an error, so if you expect capture and see nothing, check that the master switch is on and the proxy is running.
HTTPS: the proxy intercepts TLS with its own certificate authority. Most offensive tools skip certificate verification against arbitrary targets, so interception works out of the box.
The AI agent works the captured corpus through ten tools. Eight are read-only analysis tools; two are active tools that resend traffic and are treated as dangerous. You do not call these directly: you ask the agent in plain language and it chooses the tool. All of them are strictly scoped to your project and user, so the agent can never read or replay another tenant's traffic.
You can see the whole group, and enable or disable each tool per phase, in the Tool Matrix of the project settings. The two active tools carry a warning glyph.
| Tool | What it gives the agent |
|---|---|
proxy_search |
The Burp-style history as summaries (no bodies), with the same filters as the UI. |
proxy_get |
The full request or response of one transaction, on demand. |
proxy_sitemap |
The distinct endpoints observed (host + path + method) with hit counts and statuses. |
proxy_params |
Distinct request parameters with sample values and an injectability guess (sequential id / uuid / jwt / base64). |
proxy_grep |
Substring search across response bodies, with a snippet around each match. |
proxy_diff |
A structural diff of two responses (status, length, headers, body). |
proxy_to_curl |
A captured request rendered as a reproducible curl command. |
proxy_query |
Ad-hoc aggregate questions over the corpus (counts, group-bys) via a safe, allowlisted query builder. |
| Tool | What it does |
|---|---|
proxy_replay |
Resends a captured request with fields you change (method, path, query, params, headers, cookie, body). The target host is locked to the original and cannot be changed, so a replay can never be aimed at a new host. Supports auth-context swaps (drop or change the Cookie / Authorization) for IDOR, BOLA, and privilege-escalation testing. Each replay is recorded as a new transaction with a replay flag. |
proxy_fuzz |
Burp-Intruder style: replays one captured request while iterating a list of payloads over a chosen query parameter (capped at 50), returning a per-payload status and length summary so anomalies stand out. |
Because the active tools send traffic, they are gated: allowed only in the
exploitation and post-exploitation phases, flagged as dangerous in the Tool Matrix,
and restricted in stealth mode (proxy_fuzz is fully disabled in stealth,
proxy_replay is restricted). Replayed requests go back through the capture proxy,
so they are scope-checked and recorded just like any other traffic.
"Show me every 500 response we captured against the target."
"Search the captured bodies for anything that looks like an API key or a stack trace."
"List the distinct parameters we've seen and flag the ones that look like object IDs."
"Replay transaction without the session cookie and tell me if we still get a 200."
"Fuzz the
idparameter on transaction with the values 1 through 20 and show me which ones return different lengths."
"Diff the response of transaction A against transaction B."
- The proxy holds no secrets. The target-facing proxy has no database access and no signing key. It only forwards and records. Attribution is verified by a separate trusted component before anything is stored.
- Tenant isolation is enforced everywhere. The TrafficMind view, the API, and every agent tool are locked to your project and user; there is no way to read across tenants.
- Secret redaction is on by default (see settings). Sensitive header values are hashed, not stored in the clear.
- Bodies are attacker-controlled. They are always displayed as text, never rendered, and the agent's tools never build raw database queries from body content.
- Scope safety. The proxy refuses to reach internal or private addresses, and agent replays are locked to the original target host, so capture cannot become a pivot into your own infrastructure or a way to hit an out-of-scope host.
Transactions are kept for the Retention (days) you set (default 14). Set it to
0 to keep them indefinitely. Bodies larger than the inline cap are stored once in
a shared, hash-addressed blob store and reused across identical bodies to save
space.
Important: the retention and per-project size-cap cleanup runs as a maintenance job that must be triggered on a schedule. If your deployment does not yet have that trigger wired, the retention setting has no effect and the corpus grows until you delete rows manually from the TrafficMind view. Deleting from the UI always works and reclaims blob storage immediately. This is a known operational gap noted in the technical reference.
Check both levels of the switch: the master toggle in Global Settings must be on (it starts the proxy), and the per-project routing must be on for that project. Flip it in the Per-project routing matrix in Global Settings (admin-only); the TrafficMind page top bar shows the current status but does not change it. If only one level is on, nothing is captured.
Only specific tools are routed (see How routing works). OSINT
and passive tools are intentionally not captured. Also check the Scope setting:
Recon only or Agent only will exclude one side.
The feature fails open: if the proxy becomes unreachable, tools continue directly against the target and are not captured. The scan still completes. Re-check that the proxy container is running.
Either Store bodies is off (only sizes and hashes are kept), or the body was
larger than the inline cap and offloaded. Offloaded bodies are still available in
the TrafficMind view detail drawer; the agent's proxy_get reports when a body was
offloaded rather than inlined.
The active tools are phase-gated (exploitation and post-exploitation only) and
restricted in stealth mode. Confirm the project is in a phase that allows them and
that stealth mode is not blocking proxy_fuzz.
For the full architecture (the credential-free proxy, the HMAC context tag, the append-only spool, the trusted ingest worker with an insert-only database role, the complete schema, the trust-boundary model, and every code reference), read the TrafficMind: Technical Reference.
- Global Settings: where the master switch, runtime options, and the per-project routing matrix live
-
Project Settings Reference: the Tool Matrix (which
proxy_*tools are routed) -
AI Agent Guide: how the agent uses tools like the
proxy_*set - Rules of Engagement (RoE): scope enforcement that also governs captured traffic
- Running Reconnaissance: the recon runs that generate captured traffic