> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.method.security/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.method.security/_mcp/server.

# Operating the Funnel

> How Targets move through the funnel, what each Agent phase produces, and how to review sessions and Reports.

In the previous modules we covered what Targets are, how the pipeline is configured, and how to launch a Campaign. This module covers what happens once a Campaign is running and Targets need your attention.

## Progressing a Target

As Agents work through Targets, each stage produces a Report summarizing what the Agent found. When a Target reaches a Stage Policy gate, it stops and waits for you to review that Report before it can move to the next stage.

Targets waiting for your review appear under **Required input** in the Targets tab. Each Target card shows a summary of what the Agent found, the underlying Object, the Environment, and two options: **Proceed** to advance the Target or **Abort** to stop work.

![Targets tab showing Required input section in the left sidebar, with Target cards displaying Agent session summaries and Proceed/Abort buttons.](/_fern-img/52fea0a6395642d8dce123462a94c742d0433930cc44f549fdd7f65a09ad1c45.webp)

Clicking a Target opens its detail view, where you can review the completed Agent session and its Report. When ready to advance, you select which Agent to send the Target to next.

![Target detail view showing Process timeline, Targeted Object, Selected for Targeting, completed Research Agent session, and Continue section with Send to Research Agent, Send to Pentest Agent, Send to Compromise Agent, and Send to Operator options.](/_fern-img/d50697caf5f14c17120f3a59b1d0d55ef721eb96295412ee70af960bdf4dda13.webp)

Once a session starts, you can watch the Agent work in real time and use the chat to ask it questions during the session. Active sessions are visible under **In progress** in the left navigation.

![Live Agent session view showing the conversation with tool calls, interim notes, and a chat input for asking the Agent questions.](/_fern-img/068b3ec42e585f1c4fdd091e244a3f87b0dc32ed286a56875eb7287203fde75c.webp)

## Reviewing Agent sessions

When reviewing a Report, you are checking what the Agent found and whether its output is sufficient to move the Target forward.

### Research

![Research Agent session showing the conversation, key results, and prioritized downstream handoff.](/_fern-img/ec055eac20d31a218b7bb4af743b1eb6275ab167c612789a9b4786ff4c49f10f.webp)

The Research Agent figures out what a Target is and what is reachable on it. It probes the Target and produces a characterization that includes the technology stack, reachable paths, parameters, and the authentication surface.

At the bottom of the Report is the **prioritized downstream handoff**, a ranked list telling the Pentest Agent what to test first and why. The Pentest Agent works through this list in order.

### Pentest

![Pentest Agent session showing the verdict table, session outcome, and viability assessment.](/_fern-img/8eea3437ba67f4286bfbe3ade6ca0f8d37d5576dc8db8300605e6d747b362793.webp)

The Pentest Agent reads the surface that Research produced and builds a list of testable inputs from it.

It then works through each input, testing every applicable vulnerability class. The Report includes a **per-vector verdict table** with one row per vulnerability class the Agent was granted, so you can see exactly what was tested.

The Pentest Agent does not demonstrate impact, chain Findings, or use credentials it recovered. That happens in the next phase.

### Compromise

The Compromise Agent takes a confirmed Finding from Pentest and determines how far it can go. It needs four things from the Pentest Report: the vector, the sink, the identity setup, and a working proof of concept. If any of those is missing, it stops.

It always starts by re-running the proof of concept against the live Target. If that no longer works, the Target does not advance.

From there it escalates the vulnerability as far as it can go, proving the full extent of the impact.

Every action the Compromise Agent takes is classified before it runs.

| Class                        | What it means                                                                                                                                       |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| `READ_OWN`                   | Read data belonging to the Agent's own test accounts. Always allowed.                                                                               |
| `READ_FOREIGN`               | Read another identity's data through the confirmed vulnerability. Allowed, capped at 10 records per rung.                                           |
| `WRITE_OWN`                  | Change the Agent's own test account state. Allowed, reverted where possible.                                                                        |
| `WRITE_FOREIGN`              | Change another identity's state. Only between two test accounts the Agent created itself. Never against real user data.                             |
| `WRITE_PERSISTENT`           | Create state that outlasts the session, like a new admin account. Requires your approval. Default is to document it as reachable without executing. |
| `EXECUTION`                  | Run a command on the Target through the vulnerability. One read-only command (like `whoami`) as proof.                                              |
| `CONTROL_PLANE_REACHABILITY` | Show a privileged operation is reachable without invoking it. Always allowed.                                                                       |
| `DESTRUCTIVE`                | Mass delete, drop tables, email real users, modify billing. Never permitted. The Agent documents that it is reachable.                              |

Escalating through the confirmed vulnerability counts as the same Finding. Reaching a different vulnerability does not. A SQL injection that reaches command execution is one Finding at its ceiling. If the Agent happens to discover an unrelated vulnerability along the way, it writes it up and hands it back to Pentest to confirm separately.

## Session controls

![Live Agent session with the End Session button highlighted in the top right.](/_fern-img/03669f59ca7ff25e16a7aacc6afb1bb13535c62ba8ed86ff96c7a9fefea1ecbf.webp)

* **End Session** - Stops the currently running Agent session. You can find it in the top right of any active session. The Agent stops working and the Target stays at its current status.
* **Abort** - Stops work on a Target entirely. You can find it on the Target card in the Targets tab. The Target moves to Deferred status.

## The generated Report

![A generated Final Report showing the summary, findings, and evidence.](/_fern-img/588a6d515330271ec7bf8fe9a6b6fcd9fa61b47d09e2352551300c1e1a9d1220.webp)

After a Compromise Agent completes its work, the Target has a Final Report and one or more [Findings](/platform/core-platform/findings) attached to it. The Report is generated automatically and can be saved as a PDF.

## Knowledge check

**Question:** What four items must the Pentest Agent hand to the Compromise Agent for it to start?

#### Check your answer

The Vector (the vulnerability class), the exact Sink (endpoint, method, and parameter), the identity setup used to reach it, and a working proof of concept. If any of those four is missing, the Compromise Agent stops rather than reconstructing the gap.

**Question:** A Pentest Agent tried every applicable technique and found nothing reproducible. Is the Target Blocked or Exhausted?

#### Check your answer

Exhausted. The Agent completed the full permitted job and the answer was no. Blocked means the Agent could not reach an answer either way - something prevented it from completing the work.

## Course summary

This course covered the complete Targeting workflow, from how Targets are selected and how Packages, Triggers, Agents, and Rules of Engagement configure the pipeline, to launching a Campaign and triaging the Targets it produces. You should now be able to set up a Campaign, review Agent sessions at each stage, and decide when to advance, defer, or stop work on a Target.