> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.method.security/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.method.security/_mcp/server. # Jackal and the Courier Protocol > The design and architecture of the Jackal security agent and the Courier protocol used to communicate with the Method Platform. 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](/platform/core-platform/tools/living-off-the-land-tools)). * **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](/_fern-img/d55e06553baf15ad40e2c4f84ab6d9183677177d7d07025e5638d4f0ed3ed145.webp) 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](#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](/platform/core-platform/administration) application. ## Capabilities and custom actions ![Diagram showing a Jackal advertising capabilities to the platform, and a Tool exercising a matching capability](/_fern-img/37b72e15dda862a97590adb1feec9d83bc3c2d4e258efe2329a6c66faa25606a.webp) 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](/platform/architecture/developer) can build a Jackal with custom tradecraft behind a custom action ID, then pair it with a matching [operator-defined Tool](/guides/best-practices/developer/operator-defined-tools) 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](/platform/core-platform/tools/tool-authoring-reference#courier-tool). ## Custom transports ![Diagram of a Jackal and the platform exchanging Courier frames through a custom interface over a custom transport](/_fern-img/106020655457cf24e3455fb540318195cdeab9f32c49296910e1e178839e6438.webp) 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](#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. --- > **Note** > > For a deployment guide, see [Install and configure a Jackal](/guides/platform-setup/install-a-jackal).