Targeting | Method Platform

How Method identifies, validates, and tracks actual 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 can actually be exploited.” 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.

Findings

Dashboard

The Targeting dashboard gives you a live view of targeting activity across all Environments. It shows the current distribution of Targets across the funnel, recent status transitions, and which Targets are blocked pending human approval.

Use the dashboard to answer questions like:

How many assets are currently under active Agent investigation?
Which Targets have been validated but not yet moved to exploitation?
Are any Targets blocked by a Rules of Engagement gate?

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; as it advances, it leaves the prior status and enters the next.

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

Status	Description
Potential Target	Asset 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 does not hold up: it 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	Terminal-adjacent status. 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

You configure targeting behavior through four building blocks: Rules of Engagement, Packages, Environments, and Triggers. Together they define what gets targeted, how, and under what constraints. The Targeting Overview tab sits alongside them as a read-only summary of how those settings are applied across the stack.

Targeting configuration tabs showing Overview, Rules of Engagement, Packages, Environments, and Triggers — Targeting configuration

Targeting Overview

The Targeting Overview tab shows the distribution of Rules of Engagement settings across all enabled Packages. Use it to understand the current automation posture at a glance: which Packages are running fully automated, which require human approval at specific statuses, and whether any gaps exist in coverage.

This is a read-only summary view. Configure individual ROE settings within each Package.

Rules of Engagement

Rules of Engagement (ROE) define status-based automation controls. They answer: “How far should Method go automatically, and where does a human need to sign off?”

Configure ROE settings at the Package level, and combine them with per-Agent tool and parameter policies. Examples:

Stop all Agent action after pentest validation
Require human approval before moving from Exploitable to Exploited
Allow full automation through exploitation but block at remediation

When a Target hits an ROE gate, Method flags it as blocked, and it cannot advance until you approve the next action. An ROE gate is only one of the reasons a Target ends up blocked. See The Targeting funnel for the full picture.

Packages

Packages are the top-level configuration object for Targeting. A Package answers two questions: “why is this asset being targeted?” and “how is targeting being performed?”

Method ships a set of pre-built Packages covering common attack surface categories:

General: broad coverage across asset types
Web App: web-facing applications and APIs
Network: exposed network services and infrastructure
Known Software: assets with known software versions that may be vulnerable
Cloud: cloud provider resources and configurations
Identity: identity infrastructure, credentials, and access patterns

Targeting Packages view showing pre-built and custom packages — Targeting Packages

These pre-built Packages are a starting point, not a fixed set. Every Package is customizable to your environment and needs. You can tune a shipped Package or build your own from scratch, and on each one you control:

Triggers: which assets the Package selects for targeting
Rules of Engagement: how far automation proceeds before it needs your approval
Agents: which Agents run against the assets the Package claims

Build custom Packages via Campaigns to scope targeting to a specific assessment or time-boxed engagement. You can enable or disable Packages at will. When enabled, a Package can apply across all Environments or target a specific subset.

Environments

Environments bound the set of assets a Package operates over. An Environment can represent a business unit, an AWS account, a scoped campaign, 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 just called “the stack.” An Environment is simply a bounded asset scope: the unit over which a Package applies.

Packages can target a single Environment or span multiple, giving you precise control over blast radius.

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”)
Specific: select assets that match a precise condition on a particular asset type (e.g., “S3 buckets with public ACLs in accounts tagged production”)

When an asset matches a Trigger, it enters the funnel as a Potential Target, and Method queues it for Agent assignment.

Campaigns

A Campaign deploys a Package against an Environment and puts targeting into motion. Packages, Triggers, and Rules of Engagement define the configuration. A Campaign runs that configuration against a real scope of assets.

A Campaign is a short guided flow with four stages:

Environment: pick or create the Environment where the Campaign runs
Scan setup: set how often Method runs and what it collects
Targeting: choose which Packages apply to every matching asset, or build a new one
Review: confirm the configuration and launch

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

As a Campaign runs, its Triggers evaluate the Environment’s assets and select matches as Potential Targets. Those Targets populate the Targeting funnel and advance through it as Agents work them. The same activity feeds the priority dashboard, so newly discovered Targets surface for triage as they appear.

For step-by-step guidance on setting up a Package, configuring Rules of Engagement, or reviewing blocked Targets, see the Targeting guides.