Skip to main content

Operations

An operation is Cracken's core unit of work: an AI-driven security assessment that runs inside a realm. The agent reasons, proposes actions, and executes them under the level of oversight you choose — and every step is recorded in one live ledger you can watch, pause, and steer.

At a glance​

  • What it is — an AI-driven security assessment that runs inside a realm, recorded in one live, steerable ledger.
  • When to use it — start one to run an assessment against defined targets, from a playbook or from scratch.
  • Inputs — a realm, a starting point (playbook or task description), scoped targets (hosts/IPs/domains/apps), an autonomy mode (Manual/Semi/Auto), an optional model choice.
  • Outputs — a ledger of reasoning, actions, and results; findings, artifacts, generated files/reports, and Cybergraph data; sub-operations for parallel workstreams.
  • Related objects — Realms, Semi-Autonomous Policy, Vessels, Reporting, File System, Cybergraph.
  • Common actions — Create, Approve, Deny, Pause, Resume, Interrupt, Archive, Restore, Delete.
  • API / tool links — REST can create operations with POST /api/v1/operations; MCP tools include create_operation, list_operations, get_operation, get_current_approval_request, approve_approval_request, and deny_approval_request — see the External API and MCP.

What an operation is​

You define what to test; the agent plans and works; you approve or deny actions according to the operation's autonomy mode. An operation runs in a single realm and produces findings, artifacts, and Cybergraph data as it goes.

Create an operation​

  1. Open your realm and select New operation.
  2. Optional: Attach a playbook or multiple playbooks if you want repeatable methodology that guides the assessment.
  3. Describe the task specifying the hosts, IPs, domains, etc.
  4. Start the operation. The agent begins reasoning and proposing its first actions.

The operation ledger​

An operation is an ordered, live ledger of everything that happens, in sequence:

  • The agent's reasoning about the current state and what to do next.
  • Each proposed tool action and its result — a command, script, or browser step run in a Vessel.
  • Streamed output while an action runs.
  • Requests for your input when the agent needs a decision.
  • Generated files, findings, and reports.
  • Child operations spawned for parallel workstreams.

You read the ledger top to bottom to follow exactly what the agent did, and why.

Follow live activity​

The activity bar sits at the top of the lower control card, below the ledger. It shows the operation's current work or the decision it needs from you. Working states include Reasoning, Generating, Running, and Retrying. Waiting, paused, and completed operations keep their last confirmed state visible.

When the operation needs input, the bar names the action, such as Review & approve, Answer question, Approve or reject, Approve delegated operation, or Respond to monitor. Activate its action to focus the matching control or composer in the lower card. For a configuration proposal, it reveals the matching record in the ledger instead.

The elapsed time is active operation time. It advances while work is live and holds while the operation is paused or waiting. If the browser reconnects, the bar dims and freezes at the last confirmed state until a fresh status arrives.

Stay in control​

How much the agent does on its own is set per operation:

  • Manual — every proposed action waits for your decision. Approve it, deny it (the agent replans), or approve it and add the result to the Cybergraph for persistent tracking.
  • Semi — the agent runs actions allowed by your autonomy policy and asks before anything risky.
  • Auto — the agent runs without stopping for each action.

While an operation is active you can:

  • Pause it — the agent stops proposing new actions until you resume.
  • Resume it — pick up from where it stopped.
  • Interrupt it — stop the current action mid-flight and take back control.

When the selected operation has sub-operations, a scope switch beside the controls decides whether Pause, Resume, and autonomy changes apply only to that operation or cascade to its sub-operation tree. It defaults on when sub-operations exist; turn it off to act on the selected operation alone.

Cracken also scans your operation input for likely secrets before sending it to the agent — if a message contains a potential secret it is rejected so you can store or remove it first.

Choose a model​

You can choose which model an operation runs on — both when you launch it and while it is running — from the models your Cracken instance makes available. Sub-operations and playbooks can carry their own choice; otherwise an operation uses a sensible default.

Some models are gated behind a plan feature. The Red model, for example, is available only to plans that include it — for other plans it appears in the picker locked, with a Talk to sales option instead of being selectable, and is never bundled into a plan (it is enabled only on request through sales). Explicitly selecting a gated model your plan does not include is rejected, while a gated model reached implicitly (pinned by a playbook, inherited from a parent, or the deployment default) is transparently downgraded to your plan's best entitled model rather than failing. The external API's model list is likewise scoped to the calling key's plan.

See Models for each selector model's purpose and estimated credit use.

Sub-operations​

An operation can spawn child operations to pursue several lines of investigation at once. Each sub-operation runs in its parent's context with its own thread, and reports its results back to the parent when it finishes.

You can create a sub-operation yourself from the operation tree:

In Manual mode, the agent can also propose one blocking delegated operation per response. The parent waits at Approve delegated operation until you decide. Approve creates and starts the child; Reject declines the proposed delegation and leaves no child running. This gate applies only to blocking delegation requests; background delegation continues without it.

Or, running on Auto, the agent delegates independent workstreams into their own sub-operations on its own — spawning several in parallel and waiting on them before it continues:

Lifecycle​

An operation moves through a few states as it works: the agent is thinking or generating, waiting for approval on a proposed action, executing an action, or suspended while it waits on a monitor — which costs nothing while parked. It ends as completed, failed, or cancelled. Completed is usually not final — sending a follow-up message to a finished operation reopens it and continues from where it left off, and a follow-up to a sub-operation is reported back to its parent. Three kinds stay closed: archived operations, operations frozen and owned by another operation, and operations with a final output contract that have already produced their result — reopening one of those would rewrite an answer someone has already been handed. You can pause an operation at any point and archive it once it is done.

Archiving, restoring, and deleting​

Archiving an operation moves it out of the active list without losing its history. Archiving a parent archives its sub-operations with it.

Open Archived from the operations list to review archived operations, search them by name, restore them, or delete them permanently:

  • Restore returns an operation to the active list. Restoring a parent restores its sub-operations too.
  • Delete permanently removes an operation and asks you to confirm first, because it cannot be undone. Deleting a parent re-parents its sub-operations rather than deleting them.

To act on several at once, select the rows you want, then use Restore selected or Delete selected. Select all selects every result when the full result set is loaded; Select loaded selects the operations loaded so far when more pages remain. The selected count is the number of rows queued directly. Restoring a selected parent also restores its sub-operations, even when those descendants are not selected separately.

Batch requests are independent rather than atomic. Successful rows leave the selection, while failed rows remain selected so you can retry them. A bulk delete asks for one confirmation before sending the requests and requires the Owner or Admin role's operation:delete permission. Operations that are inspect-only (for example a frozen sub-operation owned by a tabular operation) cannot be selected, restored, or deleted from here.

Next steps​

  • Realms — the scope an operation runs inside.
  • Autonomy — how Semi and Auto decide which actions run on their own.
  • Vessels — where an operation's actions execute.
  • Reporting — turn an operation's findings into a report.