Exploit Path Search LATS
The agent opens up the whole space of possible attacks and explores it as a tree, inspired by Monte Carlo Tree Search, the same search that powered AlphaGo. Instead of chasing one idea down a dead end, it fans out every credible way into the target at once, follows the branch that keeps getting warmer, and prunes the ones that hit a wall, until one line breaks through to a foothold.
Exploit-Path Search (LATS) is RedAmon's optional, systematic tree search over exploit probes. Instead of the agent committing to one idea and grinding it until something forces a pivot, LATS turns exploitation into an explicit search: it fans out the competing attack paths, runs the most promising one, scores how close each probe got to a foothold, concentrates the budget on the branch that is actually progressing, and backs out of WAF / 403 dead ends instead of hammering them.
Give an autonomous agent a hard target and a quiet limitation shows up: it thinks in a straight line. It forms one hypothesis, commits to it, and grinds until something forces a pivot. That is fine for a simple objective and wasteful on a real one, because it walks straight past the branch that would have worked.
Exploit-Path Search gives the agent a different way to think. Rather than following a single idea, the agent opens up the whole space of possible attacks and searches it: it fans out the competing ways into the target, runs the most promising one, feels how much closer each probe got to a foothold, and pours the remaining budget into the line that is actually opening a door. Promising branches grow deep. Dead ends get pruned after one probe, with the reason recorded so nothing re-runs them. The search is not abstract daydreaming either: every branch is a real probe fired at the live target, and every score comes from the target's real response, so the reasoning is grounded in what the system actually does, not in what the model imagines it might do.
The idea has a well-known pedigree. Exploit-Path Search adapts Monte Carlo Tree Search, the same family of search that powered AlphaGo, into a language-model agent, following the Language Agent Tree Search (LATS) research pattern presented at ICML 2024 (paper). Where a game engine searches board positions, RedAmon searches exploit paths: the "board" is the live target and the "moves" are probes. The agent plays the roles the algorithm needs, proposing the moves and judging how good each one turned out to be, so the search learns from real feedback instead of random simulation.
The pay-off is measurable. On complex, multi-step scenarios, enabling Exploit-Path Search delivers roughly a +30% improvement in efficiency at reaching the flag and completing the solution versus the default straight-line loop, using the same model and the same tools.
Architecture deep dive. This page is the operator-facing guide: what the feature does, what the settings control, what the cards mean. For the full architectural treatment (the value function maths, UCT selection, backpropagation, the hook inside
think_node, the exit conditions, and the algorithm pseudocode with worked calculations) read the RedAmon Agentic System - Technical Whitepaper.
- What Exploit-Path Search Is (and What It Is Not)
- Why It Helps
- How It Works Inside the Agent Orchestrator
- How the Search Works at a High Level
- A Worked Example: Login Page to Account Takeover
- Project Settings - Every Parameter Explained
- What You See in the Chat
- Exploring the Full Tree
- Shadow Mode (Observe-Only)
- Safety Guarantees
- Troubleshooting
- Next Steps
The default agent reasons like a determined human working alone: it forms a hypothesis ("there is SQL injection in the username field"), probes it, and keeps probing it until the productivity engine notices the loop and nudges a pivot. That is a straight line through the problem.
But a real exploit chain is a tree, not a line. From a login page the promising moves fan out at once: default credentials, SQL injection on the username, a password-reset probe, JWT algorithm confusion. Only the branch that keeps yielding signal deserves to grow deeper (reset probe leaks a token, then forge the token, then reset the admin password). Exploit-Path Search makes that tree explicit, scores each executed probe, and drives the budget down the branch that is winning.
What it is not:
- Not always on. It is opt-in per project and, even when enabled, it only engages during exploitation when the agent finds two or more credible attack paths on a surface that already exists. One obvious path is not a search, so it stays off and the normal agent drives.
- Not a new kind of agent or a separate model. It runs inside the existing think step, on the same LLM the agent already uses. No second model, no extra reasoning loop.
- Not autonomous detonation. Every dangerous step it proposes still goes through the exact same approval prompt as any other tool. LATS proposes; you (or the policy) authorize.
- Not a checkpoint rewind. "Backtracking" here does not undo anything against the target (you cannot un-send a request). It simply moves attention to a more promising branch and builds the next probe from there.
- Not the same as Fireteam. Fireteam runs several specialist agents in parallel on independent angles. Exploit-Path Search is one agent searching a single objective's attack tree over successive turns.
- It abandons dead ends after one probe, not five. A 403 / WAF rejection scores low immediately and the branch is pruned with a recorded reason. The default loop can take three or more repeats of the same axis before it registers the dead end.
- It concentrates effort where progress is happening. A probe that leaks a token or reaches a database error scores higher than a generic rejection, so the next turns build on it instead of exploring flat ground.
- It remembers what it ruled out. When a search finishes, the whole tree (best line plus the lessons from every pruned branch) is folded back into the agent's context, so the agent does not re-run probes that already failed, and later searches build on earlier ones.
- It stays cheap and bounded. Selection, scoring, and backtracking are pure computation with no LLM cost; the only added spend is one small structured call each time a node proposes its next probes. Hard caps on probes, depth, and tree size keep the number of real requests against the target predictable.
The agent's core is a think-act loop: the think step reads what happened, decides the next action, and a tool runs it. Exploit-Path Search is a single decision policy that lives inside that think step, after the agent's model has produced its analysis and proposed an action. There is no new stage in the pipeline and no change to how tools run.
On each turn where it is active, the policy does four things around the one model call the turn already makes:
- Evaluate the probe(s) issued last turn, using the agent's own analysis of the outputs as the scoring signal, and push that score up the branch.
- Check for an exit (a foothold reached, the budget spent, or the branches collapsed to one obvious line).
- Select the most promising place to search next and expand it into concrete candidate probes.
- Override the agent's proposed action with the next probe (or a small parallel wave of probes), which then flows through the normal router, the approval gate, and the tool executor unchanged.
Because it only rewrites the chosen action and rides inside the existing state, the whole search survives restarts for free (it is saved with the rest of the session) and disappears completely when the feature is off.
The search is closely related to Deep Think, the agent's strategic-reasoning step. When Deep Think fires, its competing hypotheses seed the first branches of the tree; and while a search is actively driving, Deep Think is paused because the tree search is doing that strategic re-planning.
Before a tree is created, a cheap gate must pass: the feature is enabled, the phase is in scope (exploitation by default), a real attack surface exists, and the objective is not already exploited. When that passes, the agent makes one structured assessment of the situation and only activates if it produces at least Activation sensitivity credible probes (default 2). Within an objective, the search can re-engage when the agent has stalled or its productivity has dropped, with a cooldown so a collapsed search does not immediately rebuild the same dead branches.
Expansion is the agent proposing concrete, executable probes for a given point in the tree. Each proposal is grounded in what the agent has actually learned about this target: the live attack-chain so far (the real endpoints, parameters, and responses it has already hit, not just an abstract recon summary, so a probe targets the real post.php?id= parameter instead of a guessed path), the confirmed findings, the dead ends already tried, the technique playbook for the current vulnerability class (so probes follow proven method rather than ad-hoc guesses), and the lessons from earlier searches this run. It proposes up to Branch width probes (default 6), each a real tool call with real arguments (never a vague plan). Off-phase or malformed probes are dropped before they can run.
Every executed probe gets a value between 0 and 1 (higher means closer to a foothold), with no extra model call. The agent labels each probe's response with a specific, actionable class from a 24-class catalogue that spans the full range of outcomes: a confirmed hit, a leaked database error, a bypassable input filter, a WAF block, an authentication wall, a genuinely missing page, and so on. The label is produced as part of the analysis the agent already writes for every probe. Each class carries its own score and its own next move:
- A confirmed foothold is the maximum reward.
- A class that means real progress (a confirmed hit, a leaked database error, a bypassable filter that a re-encoded payload would slip past) scores high and keeps the branch alive with a note on the next move, for example "same vector, mutate the payload".
- A class that means the vector is closed (a genuinely missing page, a strict whitelist, a duplicate) scores low and the branch is dropped with "abandon and pivot".
- A probe that never actually reached the target (a bad payload, a network error, a tool crash) is scored neutral, not negative, so the search retries it rather than abandoning a possibly-live vector because of a typo.
A probe whose value falls below the Prune aggressiveness floor (default 0.15) is pruned and its one-line lesson recorded. The classes are arranged so that every "keep working this vector" outcome scores above the floor and every "abandon" outcome below it.
The search picks its next move with a standard exploration-versus-exploitation rule (UCT). Each branch's score is combined with a bonus for branches that have been tried less, and the balance between "focus on the best line" and "also develop secondary lines" is the Exploration vs focus knob. A branch that keeps getting rejected accumulates attempts with a low score, so the rule naturally stops choosing it and moves to a better sibling. That is what "backtracking" means here: attention shifts, nothing is undone.
- Foothold reached - the agent continues along the confirmed line to convert it into the objective.
- Branches collapsed or exhausted - when only one credible line remains with nothing left to branch on, or every branch has been explored without a foothold, the search hands back to the normal agent (no reason to keep the search machinery running) and the agent keeps working from what the search learned.
- Budget spent - the Search budget (max live probes) or the Hard node cap is hit.
In every non-foothold case, the finished tree (the best line plus every pruned branch's lesson) is carried back into the agent's context so it keeps working from what the search learned.
Objective: "gain authenticated access to the admin account on https://target/login." The search seeds four competing probes at the root and, over a few turns, concentrates on the one that keeps yielding signal.
graph TD
R["root: /login"] --> A["default creds<br/>value 0.00 - pruned"]
R --> B["SQLi on username<br/>403 WAF, value 0.00 - pruned<br/>lesson: WAF filters quotes"]
R --> C["password-reset probe<br/>200, token leaked<br/>value 0.80 - HOT"]
R --> D["JWT alg-confusion<br/>value 0.10"]
C --> C1["reuse leaked token<br/>value 0.40"]
C --> C2["tamper expiry field<br/>value 0.60"]
C --> C3["forge token (DANGEROUS)<br/>operator-approved<br/>value 1.00 - TERMINAL"]
C3 --> E["reset admin password<br/>FOOTHOLD"]
classDef hot fill:#166534,stroke:#052e16,color:#ffffff;
classDef dead fill:#7f1d1d,stroke:#450a0a,color:#ffffff;
classDef term fill:#a16207,stroke:#422006,color:#ffffff;
class C,C2 hot;
class A,B dead;
class C3,E term;
How the values arise: the SQL injection probe returns a 403, which scores a penalty that clamps to 0.00, below the prune floor, so it is dropped after one probe with the recorded lesson "WAF filters quotes". The password-reset probe returns 200 with a leaked token: the "new information" signal plus a finding at high confidence sum to roughly 0.8, marking the branch hot, so the budget concentrates there. The forged-token probe reaches a real foothold and scores the terminal 1.00. The single irreversible step (forge token) still went through the normal approval prompt. The whole tree stayed around nine nodes rather than exploding, because the exploration rule, the prune floor, and the branch-width cap keep it narrow.
Compared with the default agent, the SQL-injection dead end was abandoned after one probe instead of several repeats, the effort concentrated on the winning branch and drove it three steps deep to a foothold, and nothing detonated without your approval.
Exploit-Path Search is configured per-project in Project Settings → AI Agent Behaviour → Exploit-Path Search (LATS). When enabled it drives by default (the search issues the probes as soon as it activates). Turn on shadow mode if you would rather watch it before letting it take the wheel.
| Setting | Default | What it does | Operational consequence |
|---|---|---|---|
| Exploit-Path Search enabled | Off | Master on/off switch. When off, the feature is completely inert and the agent behaves exactly as before. | Turn on to let the agent use tree search during exploitation. |
| Shadow mode (observe only) | Off | Builds and visualizes the search tree but lets the normal agent drive the actual probes. | Off means the search issues the probes. Turn it on to evaluate the feature safely without letting it act. |
| Search in phases | exploitation | Which phases the search may run in. Post-exploitation is available but experimental. | Leave on exploitation for web-app work; enable post-exploitation only to experiment. |
| Search budget (max live probes) | 50 | Hard cap on the number of real requests one search fires against the target. Range 4-300. | The main cost governor. Lower it for cautious or rate-limited engagements; raise it for hard targets. |
| Max chain depth | 6 | Longest attack chain the search will build from the entry point. Range 2-10. | A ceiling, not the typical depth. Raise it only for genuinely deep multi-step chains. |
| Branch width (probes per step) | 6 | How many candidate probes are weighed at each point in the tree. Range 2-10. | Higher means broader exploration per step (more thorough, slightly more cost per expansion). |
| Activation sensitivity | 2 | How many competing credible probes must exist before the search turns on. Range 2-4. | Higher makes the search more selective, engaging only when the surface clearly branches. |
| Exploration vs focus (Advanced) | 1.4 | Balance between laser-focusing the single best line and developing secondary lines. Range 0.5-2.5. | Low = commit hard to the best branch; high = keep several footholds warm. |
| Prune aggressiveness (Advanced) | 0.15 | The value below which a weak branch is abandoned. Range 0.0-0.5. | Higher gives up on cold branches sooner; lower keeps marginal branches alive longer. |
| Hard node cap (Advanced) | 120 | Absolute ceiling on tree size. Range 10-1000. | A second backstop alongside the search budget; rarely needs changing. |
Where this maps in the code. Every setting corresponds to a
LATS_*key inagentic/project_settings.py, consumed by the self-contained engine inagentic/orchestrator_helpers/lats.py. A few advanced tuning constants are code-level defaults rather than UI controls: the re-activation cooldown, stall threshold, digest size, the score at which the search re-triggers (LATS_SCORE_THRESHOLD, default 3.0), and the expansion-grounding controls (LATS_FULL_CONTEXT, default on, which feeds each expansion the live attack-chain plus the class technique playbook, bounded byLATS_CONTEXT_WINDOW). See the whitepaper for the full parameter reference.
When a search activates, a single Exploit-Path Search card appears in the AI Agent drawer on the right and mutates in place as the search runs. It shows a header with a running badge, the phase, a rollout counter, an "observe-only" badge in shadow mode, and the final outcome when it ends; a small heads-up row with the probe count, depth reached, and node total against their budgets; the tree as a compact indented outline with a glyph per node status; and the current best line pinned at the bottom.
The node glyphs are:
| Glyph | Status | Meaning |
|---|---|---|
· |
proposed | queued, not yet run |
○ |
executing | running now, awaiting output |
◉ |
evaluated | ran and scored |
✗ |
pruned | abandoned (low value / dead end) |
⚑ |
terminal | reached a foothold |
A ! next to a node marks a dangerous probe that will prompt for confirmation before it runs.
The Expand tree button on the card opens a large central modal with the full search rendered as an interactive graph you can pan and zoom, one node per probe, colored by status, with the best line highlighted. Clicking any node opens an inspector that shows the exact probe, why its value is what it is (the score breakdown), and why the search picked it over its sibling (the selection breakdown). A replay slider lets you step through how the search unfolded, turn by turn, from the first branches to the final line.
Shadow mode is the safe way to evaluate the feature. It is off by default (the search drives as soon as it activates); turn it on to observe first. With it on, the search builds and streams the full tree to the card and modal, but it does not change what the agent does: the normal agent still chooses and issues every probe. You can watch which line the search would have taken and compare it to the agent's actual choices before you hand it the wheel by turning shadow mode off again.
| Shadow mode ON | Shadow mode OFF (default) | |
|---|---|---|
| Tree built and visualized | Yes | Yes |
| Issues the actual probes | No (the normal agent drives) | Yes |
| Feeds lessons back into the agent | No | Yes |
A fair question: if shadow mode never issues a probe, how does the tree fill up with executed, scored nodes? Because the tree does not need to run probes of its own — it scores the agent's real probes. The data flows one way, agent → tree:
- The search proposes candidate probes and draws them as pending nodes (
·). Nothing is executed and, importantly, none of these proposals are ever shown to the agent — the agent's prompt contains no search state, so it decides in complete ignorance of the tree. - The normal agent picks and fires whatever probe it reasoned toward. That produces a real request and a real result.
- The search then checks whether the agent's executed probe matches one of its pending proposals (matched by tool). If it does, that node is stamped with the agent's real result and score and lights up as evaluated (
◉) or terminal (⚑). This is why you see executed, scored probes on the tree even though the search issued nothing: those executions were the agent's, and the tree simply photographed and graded them.
Two consequences worth expecting in shadow mode:
-
Lots of pending nodes. Because the agent is choosing freely and cannot see the tree, it will frequently run probes the search did not propose, and skip probes the search did. A proposal the agent never runs stays pending (
·) — it is not marked failed or pruned. Pruned (✗) is reserved for probes that actually ran and scored badly. So "many pending, a few scored" is the normal, expected signature of shadow mode: the search is proposing a plan the agent isn't obeying. - Nothing carries back. In shadow mode the finished tree is never folded into the agent's context (the "Feeds lessons back into the agent" row above). The tree is a downstream scoreboard, not an input to the agent's reasoning.
Turn shadow mode off and the arrow reverses to tree → agent: the search issues its own proposals as the real probes, so nodes it proposes are the nodes that get executed (far fewer languish as pending), and the finished tree's lessons are carried into the agent's context for subsequent turns.
Every safety mechanism that governs the normal agent also governs the search, because the search emits ordinary tool calls through the same pipeline:
- Tool confirmation. Every dangerous probe still requires your approval through the standard prompt. A rejected probe is pruned with the note "operator declined" and the search moves on. The search never removes a tool from the approval gate.
- Phase and tool gating. Proposed probes are restricted to the tools allowed in the current phase, exactly as normal.
- Rules of Engagement and guardrails. Scope guardrails and RoE run before the search ever executes; forbidden tools and out-of-scope targets are blocked identically.
- Bounded cost. The search budget, depth, branch width, and node cap together bound how many real requests a single search can fire.
- Off means off. With the feature disabled, the agent behaves byte-for-byte as it did before.
| Symptom | Likely cause | What to check |
|---|---|---|
| The search never activates | Feature disabled, wrong phase, or fewer than 2 credible paths on the surface | Project Settings → AI Agent Behaviour → Exploit-Path Search: verify Enabled is on, a phase is checked, and you are in exploitation with a discovered surface |
| The tree builds but the agent ignores it | Shadow mode is on | Turn Shadow mode off to let the search drive the probes |
| The search fires too rarely | Activation sensitivity too high, or the surface rarely branches | Lower Activation sensitivity to 2 |
| Too many real requests against the target | Search budget too high | Lower the Search budget (max live probes) |
| The search abandons branches too quickly | Prune aggressiveness too high | Lower Prune aggressiveness so marginal branches survive longer |
| It over-commits to one line and misses alternatives | Exploration vs focus too low | Raise Exploration vs focus to develop secondary branches |
| No card appears at all | Feature off, or the phase is informational | The search runs only in the configured phases (exploitation by default) |
- AI Agent Guide - the full operator guide for the agent, including the timeline cards, the three phases, and approval workflows. See the Exploit-Path Search Cards section for the drawer card in context.
- Fireteam - Parallel Specialists - the other parallel-reasoning feature; several specialist agents on independent angles, versus one agent searching a single attack tree here.
- EvoGraph - Attack Chain Evolution - the persistent attack-chain memory where confirmed findings from a search outlive the tree.
- Rules of Engagement (RoE) - the contract framework the search inherits.
-
Project Settings Reference - full reference for every project parameter, including the
LATS_*group. - RedAmon Agentic System - Technical Whitepaper - the architectural deep dive: value function, UCT, backpropagation, the think-node hook, exits, and the algorithm pseudocode with worked calculations.