Targeting | Method Platform

How Method identifies, validates, and tracks attack paths across your environment.

What is Targeting?

Targeting is Method’s mechanism for identifying and pursuing real attack vectors: the assets the platform believes an adversary could exploit. It is distinct from Issues, which track known vulnerability classes (CVEs, misconfigurations, exposures). A Target is selected because it represents a plausible attack path, not just a known risk pattern.

Where Issues answer “what is wrong,” Targets answer “what an adversary can exploit.” Method’s Agents work a Target from initial selection through validation, exploitation, and remediation, with controls you define over how far automation proceeds at each status. See Review and act on Targets to learn how to triage and act on findings.

How Targeting works

Diagram of the Method Targeting engine showing the full pipeline: Inputs, Map, Objects, Qualify, Targets, Validate, Validated Targets, Interrogate, Exploitable Targets, Exploit, Proven Paths — The Targeting pipeline: from seed data inputs to proven attack paths

Method’s Targeting engine moves selected Objects through five stages. Each stage narrows the population and increases confidence that what remains represents a genuine, exploitable attack path.

Map

How Targeting works diagram with the Map stage highlighted, explaining that seed data is modeled into 30-plus object types and cloud agents continuously hydrate Objects — Map: Method scans seed data and builds a structured data set of your attack surface

You provide seed data (FQDNs and CIDRs) and connect integrations. Method scans each identifier continuously, models discoveries into 30-plus typed Object types in its cyber ontology, and hydrates the ontology as new data arrives. This is the raw material the rest of the pipeline acts on.

Qualify

Method applies the selection criteria defined in your Targeting Packages to the Objects discovered in the mapping process. Objects that match a Package’s Triggers enter the funnel as Potential Targets. This step turns a large constellation of discovered Objects into a prioritized set of Targets worth pursuing.

Validate

A Validation Agent investigates each Target to confirm it is real, accessible, and accurately characterized. Targets that hold up move to Validated. Targets that do not are marked Invalidated and removed from the active pipeline. This stage filters false positives at scale before any offensive action runs.

Interrogate

A Pentest Agent systematically tests the Validated Target across every applicable vector to determine whether a vulnerability is present and reachable. Agents operate under the Rules of Engagement you set. Targets that clear this stage move to Exploitable.

Exploit

An Exploit Agent starts from a confirmed pentest finding and demonstrates impact within a bounded blast radius, always operating within your defined Rules of Engagement. Proven paths are delivered with evidence for remediation and reporting.

Findings

Findings are the exploited attack paths Method has proven. A Finding represents a complete chain from initial Target through validated pentest and demonstrated exploitation, with evidence the platform collected along the way.

Each Finding corresponds to a Target that reached the Exploited status. The Finding captures the full record: the path taken, the evidence gathered, and the report the Exploit Agent produced. Use Findings to prioritize remediation, share evidence with stakeholders, and track what has been proven versus what is still being pursued.

Targets

The Targeting funnel

Targets move sequentially through a defined set of statuses, each reflecting how far Agent work has progressed on that asset. A Target holds one status at a time and advances as it clears each stage.

Targeting funnel showing statuses from Potential Target through Exploited — Targeting funnel

Status	Description
Potential Target	Object matches Trigger criteria. Method queues it for Agent action; no Agent is assigned yet.
Targeted	Method has assigned an Agent and work is underway.
Validated	Agent has confirmed the Target is real and accessible.
Invalidated	Terminal status. Agent investigation determined the Target is not accessible or exploitable as initially suspected.
Exploitable	Pentest confirmed a vulnerability is present and reachable.
Exploited	Exploit Agent has demonstrated impact.
Remediated	Target is addressed and closed.
Deferred	Target is deprioritized but not closed: still tracked, not actively worked.

Blocked is not a status but a flag that can appear at Validated, Exploitable, or Exploited. A blocked Target is waiting on user input before work can continue. That might be an Agent that needs direction on how to proceed, or a Rules of Engagement gate that requires human approval. Blocked Targets surface on the dashboard under Need User Input.

Configure

All Targeting configuration flows through Packages. A Package answers two questions: why is this asset being targeted, and how is Targeting performed? Packages, Triggers, Environments, Agents, and Rules of Engagement work together to define what gets targeted, by whom, and under what constraints.

Packages

Packages are the top-level configuration object for Targeting. Each Package bundles the Triggers that select assets, the Agents that work them, and the Rules of Engagement that control how far automation proceeds.

Method ships a set of native Packages covering common attack surface categories: Web, Network, Cloud, Known Software, and Identity. Each native Package includes pre-configured Triggers, Agents, and per-stage coverage across Map, Validate, Interrogate, and Exploit.

Matrix showing Method's Native Targeting Packages with rows for Web, Network, Cloud, Known Software, and Identity, and columns for Shared discovery and enumeration, Map, Validate, Interrogate, and Exploit, with specific capabilities listed in each cell — Method's native Targeting Packages, showing coverage by surface category and pipeline stage

Native Packages are a starting point, not a fixed configuration. Every Package is customizable: you can tune a native Package or build one from scratch. You can enable or disable Packages at will, and a single Package can apply across all Environments or target a specific subset.

When multiple Packages operate over the same Environments and Triggers, Method surfaces an overlap warning. You can choose to keep both (creating separate Targets for each Package) or consolidate to a single Package for that combination.

Environments

Environments bound the set of assets a Package operates over. An Environment can represent a business unit, an AWS account, a scoped engagement, a region, or any other meaningful asset grouping.

Environment here does not mean development, staging, or production in the software delivery sense. In Targeting, the production stack is called “the stack.” An Environment is a bounded asset scope: the unit over which a Package applies.

A Package can apply to all Environments or to a specific subset. The more Environments a Package covers, the more Targets it generates. Environments that have scheduled scans already configured cannot have additional scan schedules added via a Campaign: each Environment supports one scan setup at a time.

Triggers

Triggers are deterministic searches over the structured data discovered in an Environment. They decide which assets become Potential Targets.

Each Package declares one or more Triggers. Triggers can be broad or specific:

Broad: select an entire class of assets (e.g., “all externally exposed databases”). Broader Triggers generate more Targets but may include assets that require more filtering downstream.
Specific: select assets that match a precise condition on a particular asset type (e.g., “S3 buckets with public ACLs”). More specific Triggers produce a smaller, higher-confidence set of Targets.

The more Triggers a Package declares, the more Targets it generates. Use Explorer to query your Environment’s Objects before finalizing Trigger selection to estimate how many Targets a given combination will produce. See Explorer for details.

Agents

Agents execute each stage of the Targeting lifecycle against the Targets a Package generates. A Package has three Agent slots, one per stage:

Validation Agent: confirms the Target is real and accessible, performing basic enumeration and filtering false positives before any offensive action runs.
Pentest Agent: systematically tests the validated Target across every applicable vector to confirm whether a vulnerability class is present, without demonstrating impact.
Exploit Agent: starts from a confirmed pentest finding and climbs the corresponding impact ladder to prove consequence and severity within a bounded blast radius.

Each stage only triggers if the previous stage succeeds. A large top-of-funnel narrows quickly as Agents filter at each step. When building a Package, you select an Agent for each slot. Method surfaces pre-built Agents compatible with the Package’s Triggers, or you can build a custom Agent to encode your own tradecraft.

For a full walkthrough of Agent configuration, see Create an Agent.

Rules of Engagement

Rules of Engagement (RoE) define how far automation proceeds before a human signs off. Configure them at the Package level:

Full auto: Agents run through validation, pentest, and exploitation without stopping.
Stop after Validation: Validation runs automatically; you approve before any pentest or exploit activity runs.
Stop after Pentest: Validation and pentest run automatically; you approve before exploitation.
Manual only: Every transition requires explicit approval, starting with validation.

When a Target hits a RoE gate, Method flags it as blocked. It cannot advance until you approve the next action from the Target detail view. RoE gates are composable with per-Agent Tool Policies, which let you control how individual Tools are used within each Agent session.

Targeting Overview

The Targeting Overview tab shows the distribution of RoE settings across all enabled Packages. Use it to see which Packages are running fully automated, which require human approval at specific stages, and whether any gaps exist in coverage. This is a read-only summary view; configure RoE settings within each Package.

Campaigns

A Campaign deploys a Package against an Environment and puts Targeting into motion. For a full walkthrough, see Start a new Campaign. Packages, Triggers, and Rules of Engagement define the configuration. A Campaign runs that configuration against a scope of assets.

The Campaign wizard walks through six stages:

Environment: pick or create the Environment where the Campaign runs
Input data: seed the Campaign with Critical Domains and CIDR Ranges
Intel & no-strike: upload intelligence and define No Strike List Protection Rules
Scan setup: set how often Method runs scans and where scan tasks execute
Targeting: choose which Packages apply to every matching asset, or build a new one inline
Review: confirm the configuration and launch

New Campaign wizard on the Targeting stage, selecting existing and custom packages — Selecting Packages in the Targeting stage of a new Campaign

As a Campaign runs, its Triggers evaluate the Environment’s Objects and select matches as Potential Targets. Those Targets populate the Targeting funnel and advance through it as Agents work them.

For step-by-step guidance on setting up a Campaign, building a Package, or reviewing Targets, see the Targeting guides.