Exploit Path Search LATS
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.
The name LATS comes from the research pattern it implements, Language Agent Tree Search. In the product it is labelled Exploit-Path Search (LATS) everywhere.
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, grounded in the recon surface, the confirmed findings, the dead ends already tried, 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), derived from signals the agent already produces, with no extra model call:
- A confirmed foothold is the maximum reward.
- Evidence that the probe made progress (new information, a leaked secret, a database-level error that means the input reached real logic) pushes the value up.
- A genuine rejection by the application (a 403, a WAF block, a duplicate, or no progress) pushes it down.
- 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 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). It ships off and, when first enabled, defaults to shadow mode so you can watch it before letting it drive.
| 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) | On | Builds and visualizes the search tree but lets the normal agent drive the actual probes. | Keep on to evaluate the feature safely; turn off to let the search issue the probes. |
| 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 (re-activation cooldown, stall threshold, digest size) are code-level defaults rather than UI controls. 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. With it on, the search runs and streams the full tree to the card and modal exactly as it would when driving, 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.
| Shadow mode ON (default) | Shadow mode OFF | |
|---|---|---|
| Tree built and visualized | Yes | Yes |
| Issues the actual probes | No (the normal agent drives) | Yes |
| Feeds lessons back into the agent | No | Yes |
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.