Corvus Technology · Architecture Reference

Corvus, Red-Team Kill-Chain Orchestrator

A target-agnostic, human-in-the-loop, multi-agent red-team framework driven by a local LLM, executing real offensive tooling under full operator control. Architecture reference.

The engagement is data (a playbook). Three local-LLM roles plan and adapt; a single deterministic gate enforces scope, risk tiers, approvals and audit on every action. Techniques run real offensive tooling through a config-driven toolpack, network and Active-Directory tooling, a web-application tier, pivoting/tunneling, and live HTTP against AI targets. The same engine drives a full Active-Directory forest compromise, a web-application foothold that pivots into the internal network, an AI-application breach, and an AI-model robustness assessment, switched by which playbook is loaded.

Runtime loop

Loop: Planner chooses the next eligible technique (recon/discovery run exhaustively first; the kill chain is selective) → Operator fills its args from state → gate (scope → risk tier → human approval if Tier ≥ 2 → audit) → toolpack runs the real tool → its redacted output lands in the ledger → Analyst derives insights + a recommendation. Every LLM role reads the ledger, so choices adapt to what actually happened. Repeats until the success condition, a stop, or an abort.

The design invariant

The LLM proposes; deterministic code disposes. Every action any agent takes passes through one choke point, the gate. It checks the target against a hard scope allowlist before execution (per-host, even for a multi-host sweep), classifies the action into a risk tier, pauses for human approval on Tier ≥ 2, and audits everything. The LLM's input is the ledger; its output (technique + args, or pivot/stop) is always gated and logged. The three roles add adaptivity; none can widen scope, skip a gate, or act unlogged. The gate's decision logic has not changed since the first slice, every later capability, including live tool execution, was built around it, never through it.

Components

Component	Role
State machine	drives the `supervisor → execute → analyst` loop with a checkpointer; enforces exhaustive discovery before the selective kill chain
The gate	the single choke point every action passes through (scope → tier → human approval → audit → execute)
Scope / risk / audit guardrails	deterministic controls: a hard allowlist (per-host, multi-target aware), the risk-tier classifier, and an append-only audit sink with redacted output
Tool runner	config-driven executor: substitutes synthesized args into a declared command, runs it live (or replays a fixture), parses output into loot, and redacts secrets in stored output
Eligibility engine	findings-driven predicates, techniques become eligible only from what recon actually found
Engagement state	merges loot and maintains the ledger digest fed to every LLM role
Planner role	chooses the next eligible technique (local LLM, with deterministic fallback)
Operator role	synthesizes a technique's tool args from discovered state (including multi-host enumeration); the LLM cannot override a scope-pinned target
Analyst role	derives attack-path insights, ranks eligible techniques, and summarizes state
Playbook loader	loads and validates a playbook: authorization gate, phase ordering, tier resolution, and success/coverage criteria
Tool manifest	each tool declared once as a command template, a capture pattern, and a replay fixture (held internally, shared under NDA)
Least-privilege executors	per-call, sandboxed processes that dispatch the declared tools

Live vs. sim execution

Every tool is declared once in the manifest as a command template, a capture pattern, and a replay fixture. A single switch selects the mode:

Live, the tool runner actually executes the command against the authorized lab and parses real output into loot.
Sim (default), the same command is not executed; its fixture is replayed and parsed identically. Nothing hits the network, so the full chain is testable offline and safe to demo.

Adding a capability is a manifest entry, not code. The gate, scope, tiers and audit are byte-identical in both modes.

Risk tiers (the HITL contract)

Tier	Meaning	Gate
T0	read-only recon / enumeration	auto
T1	low-impact / contained mutation	notify
T2	state-changing exploitation	approve
T3	destructive / high blast radius	approve + typed confirm

Tiers are set per tool and overridable per playbook; a human-only override forces a step to a confirm gate for the highest-impact actions (e.g. an agentic AI tool action, or a domain-dominance step).

Adaptivity, how a run steers itself

Mechanism	What it does
Findings-driven eligibility	each technique's eligibility rule gates it on live state (e.g. a domain controller was discovered, credentials are available, a vulnerable certificate template was found); only applicable branches fire.
Exhaustive discovery	every recon/discovery technique runs first, deterministically, no vector is skipped, before the LLM-selective kill chain, which may stop early once a foothold works.
The ledger	each action's redacted output + outcome accumulates in state; the planner/operator/analyst read it, so they adapt to real signals (e.g. an access-denied result → pivot to another enumeration route) instead of stalling.
Multi-host sweep	enumeration targets an explicit host list or CIDR; one step iterates every in-scope host. Authenticated steps stay pinned to a single discovered host.
Operator synthesis	tool args (targets, users, payloads) are synthesized from discovered state; a scope-pinned value cannot be overridden by a hallucinating LLM.

Auditability

The audit trail is the engagement's record of record. Every action writes a JSONL line with the scope decision, tier, approver, the exact command that ran (passwords masked), a redacted copy of the tool's output (hashes, tickets, cleartext credentials masked by default; a raw opt-in exists for debugging), and a digest of the full result for integrity. Because the ledger the LLM reads is the same redacted output, no secret reaches a prompt, and every autonomous decision is recorded with its rationale in the decision log.

Playbooks shipped

Playbook	Kind	Execution
full-ad	Active-Directory forest → domain/forest compromise: recon, poison/relay, credential access, certificate-services abuse, delegation, ACL abuse, database access, trusts, domain dominance	real tools (live / sim)
web-app	Web-application foothold: unauth recon → OWASP Top 10 → credential recovery → CMS/plugin RCE → local privesc → pivot into the internal network → hands off to the AD chain	real tools + HTTP (live / sim)
ai-surface-redteam	AI model/agent robustness, OWASP-LLM / MITRE ATLAS battery	real HTTP against the target agent (live / sim)
ai-dmz	AI-to-AD pivot: retrieval poisoning → web exploitation → internal lateral movement	real HTTP + tools (live / sim)

Playbooks are loaded as data and keyed by name; adding or removing one is a configuration change, not a code change. Scope (the target network, hosts and endpoints) lives in each playbook's scope block, so the same technique set retargets to any authorized environment.

Operating model

Local-first inference. All LLM roles run on a local OpenAI-compatible server (Ollama or MLX); loot and audit never leave the box (a cloud backend such as Bedrock is an optional swap). Each role degrades to a deterministic backend when the LLM is unreachable, so the system always runs.
Real tools, one switch. Live mode executes genuine offensive tooling against the authorized lab; the default replays fixtures for a safe, offline, deterministic demo. Same gate, scope, tiers and audit either way.
Authorized engagements only. A playbook won't load without confirmed authorization; the scope guardian refuses any target outside the allowlist, per host, before execution, and honors a per-host denylist even inside a sweep.
Isolated by design. Intended to run from a disposable attacker host against a segmented lab; ephemeral artifacts stay local, while the durable record is the audit trail and rendered report.

← Back to Technology Request the full technical brief