Build a custom Package
A Package bundles Triggers, Rules of Engagement, and Agents into a reusable Targeting configuration. Build one from scratch or clone an existing Package as a starting point.
For background on Packages and how they fit into Targeting, see Targeting.
Build a custom Package
Open the Packages tab
From the Targeting application, select the Configuration tab in the top navigation, then click Packages.
Create a new blank Package
Click the + New dropdown on the left side of the screen and select New blank package. Method creates the Package, adds it to your list, and opens it in edit mode.
To start from an existing configuration instead, select Clone an existing package and choose a Package to copy.
Name and describe the Package
In the Basics section, give the Package a clear name and an optional description that explains what it targets and why.
For this example:
- Name:
Cloud Bucket Targeting Package - Description:
Targets vulnerabilities in cloud buckets.
Select Triggers
Select one or more Triggers using the Select dropdown. Triggers are the filters that decide which assets this Package enrolls as Targets. For the full list of available Triggers, see Targeting.
For this cloud bucket Package, select:
- Cloud Bucket: cloud storage buckets discovered in the Environment
- Exposed Database: databases with externally accessible interfaces
- Known Software Application: assets running software versions with known vulnerabilities
- Cloud Bucket with Open Access: cloud buckets with publicly accessible permissions
Trigger breadth and target volume
Triggers vary in how specifically they select assets. A broader Trigger (for example, “all web applications”) matches a large surface area and generates more Targets, but may include assets that need more filtering downstream. A more specific Trigger (for example, “web applications running a known vulnerable version”) produces a smaller, higher-confidence set.
The more Triggers a Package declares, the more Targets it generates. Each Trigger runs independently, so adding Triggers compounds target volume across every matching Environment.
Before finalizing your Trigger selection, use Explorer to run queries against your Environment’s Objects and see how many assets a given condition would match. This gives you a concrete estimate of target volume before you commit. See Explorer for details.
Set Environments
Set which Environments this Package runs against. Leave the All environments toggle on to apply the Package wherever its Triggers match, including Environments added later.
To focus the Package on a specific scope, turn off All environments and add Environments by tag. Tag selections add the Environments currently carrying that tag. Future Environments with the tag are not included unless you set the Package back to All environments.
The more Environments a Package covers, the more Targets it generates. A Package scoped to every Environment runs its Triggers against Objects across your entire attack surface. Scoping to a specific subset limits coverage to a defined business unit, account, or engagement.
Set Rules of Engagement
Rules of Engagement control how much autonomy Method has and what it must avoid. They span four controls. Two are set on the Package: the Stage Policy and the No Strike List. The other two are set per Agent: Risk Axes and the Agent Tool Policy. You configure the Package-level controls here, then the per-Agent controls after you assign Agents below.
Stage Policy
The Stage Policy controls how far automation proceeds before requiring your approval:
- Full auto: No gates. Agents run through Research, Pentest, and Compromise without stopping.
- Stop after Research: Auto-research, then wait for your approval before the Pentest or Compromise Agent runs.
- Stop after Pentest: Auto-research and auto-pentest, then wait for your approval before Compromise.
- Manual only: Every transition requires explicit approval, starting with Research.
The core trade-off is autonomy versus manual work. More automation means faster coverage and fewer decisions to make at each stage. Less automation means more control, but at high scale, requiring manual approval at every transition is not practical to maintain. For most use cases, Stop after Research is a reasonable starting point: the Research Agent runs automatically to filter false positives, and you review what remains before any Pentest or Compromise activity runs.
Rules of Engagement and Environment scope work together to bound blast radius. A permissive mode like Full auto lets Agents pentest and compromise without a gate, so the Environments a Package covers define where that activity is authorized to run. The more automation you grant, the more deliberate your Environment scope should be.
For this Package, select Stop after Research. The Research Agent runs automatically, and the funnel pauses for your approval before any Pentest or Compromise activity runs.
No Strike List
In the No-strike list section, click Set up no-strike list to add Protection Rules by filter (such as a domain pattern) or by individual Object.
The No Strike List defines the Objects and filters that every Agent in this Package must avoid, regardless of Stage Policy. Anything it covers is excluded from this Package’s automated activity, whether Research, Pentest, or Compromise.
Agent Tool Policy
Unlike the other three controls, the Agent Tool Policy is configured on the Agent itself rather than in the Package. It limits which Tools an Agent is allowed to use, regardless of which Package runs it. Set it when you build or edit an Agent. See Create an Agent for details.
For a full reference on Rules of Engagement and how these four controls work together, see Targeting.
Assign Agents
Select the Agents that run against assets this Package enrolls as Targets. The Package has three slots: Research Agent, Pentest Agent, and Compromise Agent. Each slot corresponds to a stage in the Targeting funnel and only runs if your Rules of Engagement allow it to proceed.
Method surfaces pre-built Agents in two categories when you open the Agent selector:
- Compatible: Agents built for the Trigger types this Package declares. Their tools, prompts, and context are already matched to the assets this Package targets. Start here.
- Extendable: Agents that can work with this Package’s Triggers but may need adjustment to be fully effective. Select one as a starting point and customize it, or use it as a reference when building your own.
Search for an Agent or browse the suggestions. For this Package, select Cloud Research Agent as the Research Agent.
If no existing Agent fits your needs, build one that encodes your own tradecraft for this attack surface. See Create an Agent for a full walkthrough.
Set Risk Axes
Risk Axes constrain what an Agent in this Package is allowed to do while it runs. Restricted actions require your approval before the Agent takes them, so you can grant autonomy on safe behavior and gate anything riskier. You set them per Agent, for each of the Agents you assigned above.
Risk Axes are grouped along two dimensions:
- Stealth: how visible and noisy the Agent’s activity is, covering detection surface (such as reducing log noise or restricting non-native executables) and network exposure (such as limiting network footprint or exfiltration).
- Denial of Service: how much the Agent’s actions risk host stability and availability, covering privilege and persistence, operational safety, and host resource impact.
Set Risk Axes for each stage (Research, Pentest, Compromise) so every Agent operates within the boundaries you define.
Next steps
- Start a new Campaign: deploy this Package against an Environment
- Review and act on Targets: triage funnel results once the Campaign is running
- Create an Agent: build a custom Agent to assign to this Package