The chain module (Documentation Index
Fetch the complete documentation index at: https://docs.q-uestionable.ai/llms.txt
Use this file to discover all available pages before exploring further.
q_ai.chain) executes YAML-defined multi-step attack chains. It supports dry-run tracing, live execution against real targets, blast radius analysis, and detection rule generation.
Module Structure
Chain Definitions
Chains are YAML files with sequential steps. Each step specifies a module, technique, trust boundary, and dependencies. Key fields onChainStep: id, name, module (audit/inject), technique, trust_boundary, on_success (next step), terminal (boolean), inputs (variable references).
ChainCategory values: rag_pipeline, agent_delegation, mcp_ecosystem, hybrid.
Execution Modes
Dry run (--dry-run, default): trace_chain() walks the step graph without executing anything. Outputs the success-path execution order, trust boundaries crossed, and per-step technique details.
Live execution (--no-dry-run): execute_chain() runs each step against real targets. The executor dispatches to five module executors:
| Module | Executor | What It Does |
|---|---|---|
audit | execute_audit_step() | Connects to MCP server, runs scanner |
inject | execute_inject_step() | Loads template, runs single-round campaign |
ipi | execute_ipi_step() | Generates poisoned documents, builds deployment guidance |
cxp | execute_cxp_step() | Builds poisoned context file repo, builds deployment guidance |
rxp | execute_rxp_step() | Runs retrieval validation against embedding model |
build_ipi_guidance() / build_cxp_guidance() functions as standalone runs) and store it in the step’s artifacts. This guidance renders in the web UI when viewing chain execution detail.
Manual Gates
Steps withmanual_gate: true in their inputs pause after execution and wait for the researcher to perform a manual action. The executor calls a gate_callback function that blocks until the operator resumes (via the web UI “Resume” button or equivalent). If no gate callback is configured (e.g., running from CLI without web UI), manual gate steps fail with a clear error message.
Key Data Models
ChainResult — returned by bothtrace_chain() and execute_chain():
chain_name,success(boolean),step_outputs(list of StepOutput)trust_boundaries_crossed(ordered list)started_at,finished_at
step_id,module,technique,ordersuccess,error,artifacts(dict with step-specific data likefinding_count,best_outcome, andguidancefor IPI/CXP manual gate steps)trust_boundary,started_at,finished_at
chain-targets.yaml:
- Audit connection details (transport, command/URL)
- Inject model (provider/model format, falls back to
QAI_MODELenv var) - Override via
--inject-modelCLI flag
Blast Radius
qai chain blast-radius --results <file> reads a chain execution report and produces an attack path analysis: what data was reached, which systems were touched, which trust boundaries were crossed, and the ordered attack path. Output formats: JSON or HTML.
Detection Rules
qai chain detect --results <file> generates detection rules from successful execution steps. Supported formats: Sigma (YAML) and Wazuh (XML). Rules include technique identification and are generated only for steps that succeeded.
Adapter
ChainAdapter wraps chain execution for orchestrator workflows. Uses fail_fast error handling — if any step fails, the chain stops. Findings are emitted for each failed step. The adapter provides a gate_callback that integrates with the orchestrator’s wait_for_user() mechanism for manual gate steps.
Proxy Correlation
Proxy sessions can be correlated with chain execution viachain_run_id and chain_step_id fields on SessionStore. When a chain runs audit steps that go through the proxy, the captured traffic is tagged with the chain execution context. This enables post-execution analysis of which network traffic was generated by which chain step.