Early-access product guide

Understand the workflow model before onboarding.

This guide documents the stable public concepts behind ChaosEngine. Detailed API and operator references will expand as early-access behavior settles.

Overview

ChaosEngine is a security assessment orchestration platform. A workflow describes how an authorized target moves through input, tool, script, agent and output stages. The workflow graph makes dependencies and conditional branches explicit, while workflow approval remains a separate governance decision.

ChaosEngine does not grant authorization to test a target. Users remain responsible for ensuring every target and action is permitted by the applicable owner and engagement scope.

Workflow lifecycle

  1. Draft: compose the workflow and its inputs without treating it as executable.
  2. Validate: check the graph structure and referenced resources.
  3. Approve: record the reviewer decision required before execution.
  4. Execute: submit nodes through the configured execution backend.
  5. Review: inspect statuses, node artifacts and final outputs.

Approval and graph validity do not prove that every external binary is installed. Worker readiness is a separate runtime concern.

Node types

InputIntroduces the authorized target or starting data.
ToolRuns a registered security tool or action.
ScriptPerforms deliberately configured custom logic.
AgentUses an approved agent for analysis inside the workflow.
OutputDefines the terminal result or export contract.

Execution controls

Current product surfaces support conditional edges over structured JSON output, node timeouts and retry policy, scheduled runs, cancellation and resuming from a failed node. The workflow copilot can propose canvas changes and provides an undo path for its latest modification.

Execution activity exposes queue and run status, node-level results, errors, structured table output and available artifacts. These controls do not replace analyst review or prove that an external worker dependency is installed.

Workers and tool availability

Nodes execute through the configured backend. Local execution uses worker infrastructure, while other environments may submit work through the configured batch backend. The selected environment must provide every required tool and dependency.

Before treating a workflow as runnable, confirm:

  • The exact registered tool or action referenced by each node
  • The worker binary and meaningful version output
  • Input validation, timeout and retry expectations
  • Output paths and artifact handling
  • Cancellation and cleanup behavior

Organizations and access

ChaosEngine separates authentication from authorization. Organization-owned resources are scoped to the authenticated organization, while permissions control which operations a user can perform. Approval is a distinct privilege rather than an implication of general access.

Results and evidence

Node outputs remain associated with their execution context. A workflow can expose structured output for review or export, while tool-native artifacts may remain available where the configured storage and retention policy permits.

Do not treat normalized output as a substitute for analyst validation. The final interpretation, severity and customer-facing statement remain human responsibilities.

Prepare an early-access pilot

Bring one workflow that your team already runs. Document its authorized input, current commands or tools, the point where a reviewer should intervene, required worker dependencies and the artifact expected at the end.

Start with one measurable workflow rather than attempting to migrate an entire assessment program at once.

ChaosEngine early access

Bring one real assessment workflow.

We are onboarding a focused group of security teams and helping each one translate an existing process into a governed ChaosEngine workflow.