Glossary
Definitions for the main concepts in the Method Platform.
Core primitives
| Term | Definition | Learn more |
|---|---|---|
| Environment | An Environment is a logical, secure container for data, credentials, and context. Environments can be scoped to an organization, a stage (such as prod or staging), or a business unit. Environments bound the set of Objects Method works over. | Create a new Environment |
| Ontology | Method’s strongly typed data knowledge graph of Objects and the links between them. It adds a semantic layer to your data so that both users and AI can understand and act on your entities and risks. | Objects |
| Object type | An Object type is the opinionated schema that classifies an Object under a cybersecurity lens, defining its typed properties and the kinds of links it can have to other Objects. Object types include FQDNs, IP Addresses, Software Applications, and dozens more. | Objects |
| Object | An Object is any instance of a data entity modeled in Method’s Ontology: a typed, uniquely identifiable entity with defined properties and relationships. | Objects |
| Jackal | A Jackal is Method’s security agent: a minimalist, runtime-configurable agent that executes Tools to perform security actions and retrieve data. Jackals can be cloud-managed or deployed across cloud, on-premises, and air-gapped environments, self-equipping at runtime with the binaries they need. | Jackal C2 |
| Issue type | An Issue type is an opinionated categorization of risks in the Ontology. Method ships dozens of its own Issue types and also ingests findings from third-party integrations. | Issues |
| Issue | An Issue represents an instance of a security risk in the Ontology, such as an exposure, misconfiguration, or vulnerability. Each Issue carries a severity, description, linked Objects, remediation guidance, and history, and follows a lifecycle from open to closed. | Issues |
| Target | A Target is an entity Method believes an adversary could actually exploit, selected because it represents a plausible attack path rather than just a known risk pattern. Targets advance through the Targeting funnel from Potential Target to Exploited as Agents validate and exploit them. | Targeting |
| Agent | An Agent is an AI agent that investigates, validates, escalates, or performs actions on Objects, Targets, Issues, or within Operations. Each Agent is defined by a system prompt, a model, its targets, and the MCP Tools it can use, and its behavior is governed by Policies. | Agents |
| Agent session | An Agent session is a single run or chat session of an Agent. | Agents |
| Tool | A Tool is an atomic security action in Method that wraps an API, scanner, or custom CLI to perform one specific task. Every Tool execution feeds the Ledger and updates the Ontology. | Tools |
| MCP Tool | An MCP Tool is a Tool exposed to Agents through the Model Context Protocol (MCP). You browse MCP Tools in the Tools app and attach them to an Agent to define the capabilities it is authorized to use. | Tools |
| Task | A Task is a discrete, repeatable workflow that orchestrates one or more Tools to assess entities or accomplish a security goal. You build Tasks, save, and schedule them in Automator, and each execution of a Task is a Task Run. | Automations |
| Operation | An Operation is a coordinated sequence of security actions performed against a target, either investigative or offensive in nature. You run Operations in Operator for red team missions, adversary emulation, training, or live investigation. | Operations |
| Overwatch session | An Overwatch session is a recorded terminal session run through the Overwatch CLI, capturing every command, output, and relevant metadata for playback and review. | Run an Overwatch session |
| Report | A Report is a markdown document used to capture Operation Notes, After Action Reports, Issue Details, or anything else in the platform. Reports can be exported to PDF for sharing off-platform. |
Operations
| Term | Definition | Learn more |
|---|---|---|
| Overwatch session | An Overwatch session is a recorded terminal session run through the Overwatch CLI, capturing every command, output, and relevant metadata for playback and review. | Run an Overwatch session |
| Operation | An Operation is a coordinated sequence of security actions performed against a target, either investigative or offensive in nature. You run Operations in Operator for red team missions, adversary emulation, training, or live investigation. | Operations |
| Tool graph | The Tool graph is the central canvas in the Operator workspace that visualizes an Operation as a graph. Nodes represent Tool executions and edges show the data types flowing between them, letting you trace an Operation’s full lineage. | Operations |
| Network map | The Network map is a tab in the Operator workspace that shows the target network for Operations run inside a network rather than the open web. It updates as discovery progresses during the Operation. | Operations |
| Operator AI | Operator AI is the set of AI agents and subagents that power Operator’s Co-pilot and Full Auto modes. A main agent orchestrates the Operation and delegates specialized work to the Data Analyst, Quartermaster, and Pathfinder subagents. | Operator AI |
| Auto mode | Full Auto mode is an Operator mode where Operator AI runs the Operation autonomously, executing Tools on its own within the Rules of Engagement and guardrails you define. You can switch to Co-pilot or Manual mode at any time. | Operator AI |
| Co-pilot mode | Co-pilot mode is a human-in-the-loop Operator mode where Operator AI suggests Tool recommendations based on the objective, recent findings, environmental context, and adversary intelligence. You accept or decline each recommendation before it executes. | Operator AI |
| Manual mode | Manual mode is the fully operator-driven Operator mode, with no AI suggestions or autonomous actions. You select and run every Tool yourself, and can switch to Co-pilot or Full Auto mode at any time to bring in Operator AI. | Operator AI |
| Adversary emulation | Adversary emulation is an Operation type in which Operator AI adopts a selected Adversary’s tactics, techniques, and behavioral patterns to simulate how that threat actor would operate against your Environment. It can run in Co-pilot or Full Auto mode, bounded by the plan and Rules of Engagement you approve. | At Scale Adversary Emulation |
| Adversary | An Adversary is a custom threat profile built from intelligence you upload, used to emulate a specific threat actor during an Operation. When you attach an Adversary, Operator AI adopts that threat actor’s tactics, techniques, and behavioral patterns against your targets. | Create an Adversary |
| Rules of Engagement | Rules of Engagement are configurable guardrails that bound how far automation proceeds before a human signs off. In Operations they enforce safety boundaries like No Strike lists, restricted Tool executions, and operational risk controls. (They also exist in Targeting, where they set status-based gates per Package.) | Rules of Engagement |
| No Strike list | A No Strike list is a Rules of Engagement control that names targets an Operation must not act against. It enforces a safety boundary so Tools are never executed against off-limits systems during a run. | Rules of Engagement |
Targets
| Term | Definition | Learn more |
|---|---|---|
| Target | A Target is an entity Method believes an adversary could actually exploit, selected because it represents a plausible attack path rather than just a known risk pattern. Targets advance through the Targeting funnel from Potential Target to Exploited as Agents validate and exploit them. | Targeting |
| Package | A Package is the top-level Targeting configuration object that answers why an entity is being targeted and how. Each Package bundles Triggers (which entities it selects), Rules of Engagement (how far automation proceeds before needing approval), and the Agents that run against matching entities. | Targeting |
| Campaign | A Campaign deploys a Package against an Environment and puts targeting into motion, running the configured Triggers, Rules of Engagement, and Agents against a real scope of entities. You set one up through a short guided flow covering the Environment, scan setup, Targeting, and review. | Targeting |
| Trigger | A Trigger is a deterministic search over the structured data discovered in an Environment that decides which entities become Potential Targets. Triggers can be broad (an entire class of entities) or specific (entities that match a precise condition on a particular Object type). | Targeting |
| Targeting funnel | The Targeting funnel is the ordered set of statuses every Target moves through: Potential Target, Targeted, Map, Validated, Invalidated, Exploitable, Exploited, Remediated, and Deferred. A Target holds one status at a time and advances as Agent work progresses. | Targeting |
| Potential Target | A Potential Target is the first status in the Targeting funnel: an entity that matches a Trigger’s criteria and is queued for Agent action, with no Agent assigned yet. | Targeting |
| Map | Map is a pre-funnel step where Method continuously identifies and maps externally visible entities, their relationships, and potential exposure points from an attacker’s perspective. It builds the outside-in view that the Targeting funnel steps act on. | Targeting |
| Validated | Validated is the funnel status a Target reaches once an Agent has confirmed it is real and accessible. A Target here can be blocked, waiting on your approval before an Agent proceeds to pentesting. | Targeting |
| Exploitable | Exploitable is the funnel status a Target reaches once a pentest has confirmed a vulnerability is present and reachable. A Target here can be blocked at a Rules of Engagement gate, waiting on your approval before exploitation. | Targeting |
| Exploited | Exploited is the funnel status a Target reaches once an Exploit Agent has demonstrated impact on the entity. | Targeting |
Agents
| Term | Definition | Learn more |
|---|---|---|
| Agent | An Agent is an AI agent that investigates, validates, escalates, or performs actions on Objects, Targets, Issues, or within Operations. Each Agent is defined by a system prompt, a model, its targets, and the MCP Tools it can use, and its behavior is governed by Policies. | Agents |
| Subagent | A subagent is a specialized AI agent that a main agent delegates focused work to. In Operator AI the main agent calls three subagents: the Data Analyst to triage results, the Quartermaster to select and configure Tools, and the Pathfinder to plan Tool chains. | Operator AI |
| Adversary | An Adversary is a custom threat profile built from intelligence you upload, used to emulate a specific threat actor during an Operation. When you attach an Adversary, Operator AI adopts that threat actor’s tactics, techniques, and behavioral patterns against your targets. | Create an Adversary |
| Agent Fleet | The Agent Fleet is the application where you create, view, and manage your Agents. Use it to configure Agents, attach MCP Tools, adjust system prompts and models, and apply the Policies that govern their behavior. | Agents |
| Agent session | An Agent session is a single run or chat session of an Agent. | Agents |
| System prompt | A system prompt is the set of instructions that define an Agent’s role and behavior. Along with its model, targets, and MCP Tools, the system prompt shapes what an Agent can do. | Agents |
| Model | A model is the AI model an Agent uses for reasoning. Method routes every request through a model provider you configure in AI Inference, and each Agent either pins a specific model or resolves to a Large, Medium, or Small model default. | AI Inference |
| MCP Tool | An MCP Tool is a Tool exposed to Agents through the Model Context Protocol (MCP). You browse MCP Tools in the Tools app and attach them to an Agent to define the capabilities it is authorized to use. | MCP Tools |
| Policy | A Policy is a governance rule that controls where and under what conditions an Agent can act. Each Policy applies an Allow, Deny, or Require Approval effect, scoped to a specific Agent, Environment, MCP Tool, or Agent session. | Create a Policy |
Objects
| Term | Definition | Learn more |
|---|---|---|
| Object type | An Object type is the opinionated schema that classifies an Object under a cybersecurity lens, defining its typed properties and the kinds of links it can have to other Objects. Object types include FQDNs, IP Addresses, Software Applications, and dozens more. | Objects |
| Object | An Object is any instance of a data entity modeled in Method’s Ontology: a typed, uniquely identifiable entity with defined properties and relationships. | Objects |
| Linked object | A linked object is an Object connected to another Object through a typed relationship in the Ontology. For example, a Web Application links to its Web Endpoints, Web Pages, URLs, and Software Applications. | Objects |
| Source | A Source records how a given Object property was discovered, including the command and target that produced the output and a link to the Task Run that generated it. | Objects |
Access controls
| Term | Definition | Learn more |
|---|---|---|
| Owner | An Owner is the user or group with full administrative control over a resource, including the ability to modify its settings and delete it. On an Environment, this maps to the Administrator access level. | Managing permissions |
| User | A user is a member of your Method instance who gains access to platform resources through group membership. Group membership is synced from your identity provider via SCIM or managed in the platform by an administrator, and it determines what each user can access. | Managing permissions |
| Role | A Role is the level of access a group is assigned on a resource. On an Environment, the available levels are Viewer (see the Environment and its data), Editor (generate new data, for example by running a Task or Operation), and Administrator (full control, including settings and deletion). | Managing permissions |
| Permission | A permission is a grant that defines the access a group has to a platform resource. Method uses Relationship Based Access Control (ReBAC), so one group can hold different permissions on different resources, for example read access to some Environments and edit access to others. | Managing permissions |