Meta-Harness Architecture for Offensive Operations

Module S05 · Course 2A

60 min · Routing between specialized harnesses · The Alias Robotics CSI model

Prerequisite: S00, S01, S02, S03, S04

Why a single harness is wrong

A real offensive org runs bug bounty, pentest, CTF, appsec, smart contracts, cloud attack paths — concurrently.

The naive response: one super-harness with every tool, every prompt, every primitive. It fails for three compounding reasons:

Context pollution — every tool description loaded into every session
Reasoning drift — a model good at everything is excellent at nothing
Token waste — six domains of overhead, every turn, every engagement

The cure is the meta-harness: a thin orchestration layer that routes to specialized sub-harnesses.

S05.1 — When a Single Harness Is Wrong

CSI (Common Scaffold Interface) — Alias Robotics' scaffold combiner. Routes between CAI, Claude Code, Codex CLI through a local proxy.

CSI does not implement offensive capability. It routes. The proxy is the only endpoint any sub-harness can reach.

Operator task → Task classifier → Harness selector → Local proxy
Proxy routes to: CAI (offensive) · Claude Code (code-aware) · Codex CLI (SDLC)
Proxy intercepts every tool call → security primitives → telemetry aggregation

The local proxy is load-bearing

The sub-harnesses are not under your control. CAI, Claude Code, Codex CLI have their own update cadences, tool surfaces, prompt regimes. You cannot modify their internals. You can only wrap them.

The proxy is the wrap. A sub-harness cannot bypass it because the proxy is the only thing it can reach.

Same defense-in-depth argument as S02.2's scope check in both middleware and tool — lifted to the inter-harness boundary.

Meta-harness: four responsibilities

ResponsibilityWhat it does
Task classificationRead task, emit domain label. S04.1 meta-agent pattern, generalized. Allowed to be uncertain.
Harness selectionDeterministic lookup: domain → sub-harness + prompt + tool subset + HITL posture. Not a model call.
Telemetry aggregationOne ledger per engagement regardless of which sub-harness ran. Tool calls, tokens, findings.
Cost controlPer-engagement budget: tokens, dollars, wall-clock. Re-route, degrade, or halt when exhausted.

Anything outside these four belongs in a sub-harness.

Shared context, one evidence log

Shared engagement context
scope.json (S00.3)
Rules of engagement
Engagement memory handle (S02.1)
engagement_id

Loaded once by meta-harness, passed by reference. Sub-harnesses borrow, never own.

Cross-harness evidence
ONE evidence log

Append-only, hash-chained (S02.3). Findings from any sub-harness land in the same log, same schema, same engagement_id.

A finding from CAI and a finding from Claude Code: one query, one legal record.

S05.2 — The Security Primitive Layer

General-purpose meta-harnesses do not include security primitives. CAI has its own scope model; Claude Code has none; Codex CLI is a coding tool with no concept of scope.

The five primitives that MUST live at the meta-harness level — applied regardless of which sub-harness is executing.

The five primitives

1. Scope enforcement — every outbound call checked against scope.json
2. Evidence collection — every call logged, hash-chained, scope_ref stamped
3. Kill chain state — phase-appropriate gating (recon → exploit → post-exploit)
4. Signal/noise filtering — one triage pipeline for all sub-harness findings
5. RoE enforcement — rate caps + prohibited actions at the proxy

Why meta-harness-level, not sub-harness-level: you do not control the sub-harnesses. A sub-harness update can silently remove a primitive. The proxy is the one choke point every sub-harness must pass through.

The middleware pattern

Wraps any sub-harness's tool-call interface. Sub-harness code is unchanged.

Sub-harness emits tool call
1. Scope check → 2. RoE check → 3. Kill chain gate
4. Execute (via sub-harness's own executor)
5. Evidence log → 6. Triage finding → 7. Cost accounting
Structured result back to sub-harness

The sub-harness sees only the result. It has no idea scope was checked, evidence was logged, or triage ran. Robust to sub-harness updates: primitives are not in the sub-harness's code path.

S05.3 — Benchmarking Your Offensive Harness

A meta-harness that routes, enforces primitives, and aggregates telemetry is not done. It must be measurable. Without benchmarking you cannot tell whether routing to CAI vs Claude Code is actually better.

MetricMeasures
Detection rateOf seeded vulns, how many found
Exploit success rateOf detected, how many exploitably shown
False positive rateOf surfaced, how many not real
Evidence completenessOf findings, chain complete + reproducible
Time-to-first-findingWall-clock to first confirmed finding
Cost per findingDollars (tokens + compute) / confirmed findings

InjecAgent: the pass/fail gate

Before benchmarking offensive performance, the harness must resist adversarial manipulation of its tool output. InjecAgent is the test.

It is a pass/fail gate, not a performance metric. The failure mode is catastrophic: a harness that executes injected commands will eventually exfiltrate scope, modify evidence, or call out-of-scope systems.

The S01.3 reader-actor separation and S02.1 structured-summary-only memory are the defenses. InjecAgent is the test that proves they work.

One injected command executed = fail, regardless of how the harness scored on the six metrics. Fix injection resistance first.

Baselines + the repeatable lab

Published baselines
CAI CTF benchmarks
EVMbench (smart contracts)
RedTeamLLM CTF results

Not to beat — to confirm same order of magnitude and find systematic gaps.

Repeatable lab — four properties
Isolated targets (Docker, seeded vulns)
Documented vulnerability set per target
Consistent scoring script
Fixed compute envelope (model, tokens, wall-clock)

Output: a scored report — six metrics + InjecAgent pass — compared to previous run + published baselines. The artifact you publish.

What you take forward

The meta-harness is operational: routes between sub-harnesses, enforces the five primitives at the proxy, aggregates one evidence log and one cost ledger, and is benchmarked against a repeatable lab with InjecAgent as the gate.

Pillar 2 (AppSec / SDLC) takes the security primitive layer forward — scope enforcement and evidence collection apply identically to defensive harnesses doing code review and threat modeling.

The architecture is the same. The sub-harnesses change. The primitives do not.