Jackal and the Courier Protocol

How Jackal security agents are designed, and how Courier moves commands and telemetry between them and the platform.


Overview

Jackal is Method’s security agent: a minimalist, runtime-configurable agent built to run across cloud, on-premises, and constrained network environments. The Courier protocol is the protocol through which Jackals communicate with the platform. Courier defines the message format that carries workflows, results, and telemetry, and the frame format and transports that move those messages back and forth.

The following three ideas guide how Jackal and Courier are designed:

  • Minimalist and self-equipping: Jackal ships with no built-in scanners or security logic. It fetches the binaries or scripts it needs at runtime, and can rely on tools already present on a host (Living off the Land).
  • Capability-based: A Jackal advertises what it can do, and the platform only assigns it work that matches. A Jackal’s Capabilities can change as a Jackal is updated.
  • Extensible by design: Beyond the actions defined in the Courier specification, developers can implement their own Courier Jackal, add new capabilities, or wire up custom transports.

The rest of this page walks through three views of that architecture: the C2 infrastructure that moves Courier frames between the platform and a Jackal, the capability model that governs what a Jackal is allowed to do, and how custom transports extend Jackal, including into environments the platform’s built-in interfaces don’t reach.

C2 infrastructure

Diagram showing upstream platform systems and middleware assembling Courier frames, sent through an interface to a Jackal
Courier C2 infrastructure

Work and data bound for a Jackal originate in several upstream platform systems: Workflow and Result Management, Identity Management, Encryption, Daemons, Configuration Management, and Telemetry Handling. Each produces something that the Jackal eventually needs, whether that’s a Courier workflow to execute, a credential to use, or configuration to apply.

Everything from those upstreams passes through a shared middleware layer. A Frame Handler packages it into Courier frames, using Identity, Encryption, and Compression Helpers along the way. Courier frames are Method’s own wire format. That format lets frames be split into pieces as small as the spec’s minimum size and reassembled predictably, including over the constrained channels described in Custom transports.

Frames enter and leave the platform through an interface. Today, the HTTPS endpoint is what Jackals use in production. Dynamic DNS, WebSockets, and user-defined custom interfaces are in development. Whichever interface is active, a Jackal exchanges Courier frames with it bidirectionally: polling for work, executing it, and reporting results back.

Jackals are provisioned, monitored, and decommissioned through the Administration application.

Capabilities and custom actions

Diagram showing a Jackal advertising capabilities to the platform, and a Tool exercising a matching capability
How capabilities gate Tool execution on a Jackal

A Jackal tells the platform what it can do by advertising its capabilities. When an Operation assigns a Tool to a Jackal, the platform checks the Tool’s requirements against that Jackal’s advertised capabilities before allowing the Tool to run. This keeps work from being routed to a Jackal that can’t actually do it, and it means capabilities aren’t fixed: updating a Jackal can add or remove what it advertises.

The standard set of Courier actions covers most cases, but the model doesn’t stop there. A developer can build a Jackal with custom tradecraft behind a custom action ID, then pair it with a matching operator-defined Tool that issues that action. At Operation time, the platform’s compiler validates that the target Jackal actually advertises the matching custom capability before the Tool is ever sent, the same check it runs for standard actions. For the Courier actions, Signals, and compiler details Tool authors need, see the Tool authoring reference.

Custom transports

Diagram of a Jackal and the platform exchanging Courier frames through a custom interface over a custom transport
A custom interface carrying Courier frames over a custom transport

Courier frames don’t assume any particular network stack. Anything capable of moving a frame from one point to another, in both directions, can carry Courier traffic. This is what backs the “user-defined custom” interface from the C2 infrastructure diagram: a custom interface adapts an arbitrary transport (IP, RF, or another physical medium) into something that can pass Courier frames to and from a Jackal.

Because the only requirement is the ability to move a frame, a Jackal can be controlled across network environments the platform’s built-in interfaces don’t reach, as long as some link exists between the two ends.


For a deployment guide, see Install and configure a Jackal.