Module: S05 — Meta-Harness Architecture for Offensive Operations · Duration: ~60 minutes
Format: Verbatim transcript. Cues [SLIDE N] map to 03-slide-deck.html.
[SLIDE 1 — Title]
This is Module S Zero Five: Meta-Harness Architecture for Offensive Operations. Sixty minutes. The final module of Pillar One, and the one that ties S Zero Two, S Zero Three, and S Zero Four together. Each of those modules built a harness tuned to one engagement shape — bug bounty, pentest and red team, CTF. A real offensive organization runs all of them, plus web application security, plus smart contract auditing, plus cloud attack-path discovery, concurrently. This module is about how you operate all of that without it collapsing into one incoherent super-harness.
Three sub-sections. First: when a single harness is the wrong architecture, and the CSI scaffold-combiner model from Alias Robotics. Second: the security primitive layer — the five primitives that must live at the meta-harness level, not in any sub-harness. Third: benchmarking your offensive harness, with InjecAgent as a pass/fail gate.
By the end you can design a meta-harness that routes between specialized sub-harnesses through a local proxy, enforce the security primitives uniformly regardless of which sub-harness is executing, and prove the architecture is worth operating with a repeatable benchmark.
[SLIDE 2 — Why a single harness is wrong]
Start with the failure mode. The naive response to "we run bug bounty, pentest, CTF, appsec, smart contracts, cloud" is to build one harness that does everything. Load every tool, every prompt, every primitive into a single agent. That harness fails for three compounding reasons — and they are the same three reasons a single CTF agent fails, from S Zero Four point one, just at a larger surface area.
Context pollution. A bug bounty engagement does not need ROPgadget in the tool manifest. A smart contract audit does not need ffuf. Loading every tool description into every session inflates the system prompt, dilutes the model's tool-selection signal, and consumes context the engagement itself needs. Empirically, models with broad tool manifests call the wrong tool more often than models with narrow manifests.
Reasoning drift. The mental mode for exploit development — careful hypothesis testing, low-level memory reasoning — is the opposite of the mode for broad fuzzing. A model instructed to be good at both will be excellent at neither. Specialized system prompts per domain, written by domain experts, measurably outperform a generic prompt that tries to cover everything.
Token waste. Each tool's schema, examples, and invocation cost is paid every turn. Six domains of tools means six domains of overhead, every turn, on every engagement. You are paying for capability you are not using, and the capability you are using is diluted by the capability you are not.
The cure is the meta-harness: a thin orchestration layer that classifies the task, selects the right specialized sub-harness, and enforces the primitives that are common to every engagement. The sub-harnesses stay specialized. The meta-harness owns what is true regardless of which sub-harness is running.
[SLIDE 3 — S05.1: CSI architecture]
Sub-section one. The architecture worth studying is CSI — Common Scaffold Interface — developed at Alias Robotics. CSI is a scaffold combiner. It does not implement offensive capability itself. It routes work between existing specialized harnesses — CAI for cybersecurity operations, Claude Code for code-aware reasoning, Codex CLI for agentic software engineering, and others — through a local proxy that every sub-harness talks to.
The flow is straightforward. An operator task enters the task classifier. The classifier emits a domain label. The harness selector — a deterministic lookup, not a model call — maps that label to a sub-harness configuration: its system prompt, its tool subset, its context budget, its human-in-the-loop posture. Shared context — the scope file, the rules of engagement, a handle to the engagement memory, the engagement ID — is loaded once and passed by reference. Then the local proxy routes the work to the selected sub-harness, intercepting every tool call to apply the security primitives and aggregate telemetry.
The output is unified: findings, an evidence chain, and a cost ledger, all in one schema, regardless of which sub-harness did the work.
[SLIDE 4 — The local proxy is load-bearing]
Here is the design decision that makes the whole architecture work. The local proxy is load-bearing. Every sub-harness — regardless of its native tool-calling format, its native model provider, its native auth scheme — talks to the same proxy endpoint. The proxy owns the security primitives, the scope enforcement, the evidence logging, the rate limiting. A sub-harness cannot bypass the proxy because the proxy is the only thing it can reach.
This matters because the sub-harnesses are not under your control. CAI, Claude Code, and Codex CLI are external tools. They have their own update cadences, their own tool surfaces, their own prompt regimes. You cannot modify their internals. You can only wrap them. The proxy is the wrap.
This is the same defense-in-depth argument as S Zero Two point two's scope check in both middleware and tool — but lifted to the inter-harness boundary. There, the argument was: if the middleware is bypassed, the tool's own check is the last line of defense. Here, the argument is: if a sub-harness's internal scope model breaks or was never there, the proxy's check is the last line of defense. Belt and suspenders, at the architecture boundary.
[SLIDE 5 — Meta-harness: four responsibilities]
The meta-harness has four jobs. Anything outside these four belongs in a sub-harness.
First, task classification. Read the incoming task — a bug bounty brief, a CTF challenge, a pentest scope, a code-review request — and emit a domain label. This is the S Zero Four point one meta-agent pattern, generalized. A small, fast classifier, model or deterministic, routes to the right specialist. When the classifier is uncertain, a TriageAgent runs cheap probes — target type, scope, attached artifacts — and re-routes. The meta-harness does not solve the task. It decides who does.
Second, harness selection. Map the domain label to a sub-harness and load its configuration. This is a lookup table, not a model call. Once classification is done, the mapping is deterministic. A bug bounty task routes to the S Zero Two harness. A CTF task routes to the S Zero Four harness. A code-review task routes to Codex CLI with the SDLC prompt and no offensive tools loaded at all.
Third, telemetry aggregation. Every sub-harness emits telemetry — tool calls, model invocations, tokens consumed, findings produced. The meta-harness aggregates this into one ledger per engagement. This is what makes cross-harness cost control and benchmarking possible. There is one place to read "what did this engagement cost and what did it find" instead of reconciling logs from three tools with three formats.
Fourth, cost control. The meta-harness enforces a per-engagement budget — total tokens, total dollars, total wall-clock. When a sub-harness exhausts its allocation, the meta-harness either re-routes to a cheaper sub-harness, degrades gracefully by narrowing the tool surface or reducing parallelism, or halts and surfaces to the operator. Cost control cannot live in a sub-harness because a sub-harness only sees its own consumption. Only the meta-harness sees the total.
[SLIDE 6 — Shared context, one evidence log]
Two properties that prevent the most common operational failure. First, shared engagement context. Every sub-harness reads the same scope file, the same rules of engagement, the same engagement memory handle, the same engagement ID. The sub-harness does not own this context. It borrows it. The meta-harness loads it once at engagement start and passes a reference.
This prevents the "three harnesses, three scope files" failure. If CAI loads its own scope, Claude Code loads its own scope, and Codex CLI has no scope at all, the operator is responsible for keeping them synchronized. They will drift. Drifted scope is how out-of-sscope tool calls happen. The cure is one scope file, owned by the meta-harness, read-only to every sub-harness.
Second, cross-harness evidence aggregation. S Zero Two point three established the evidence chain — append-only, hash-chained, scope-referenced. In a meta-harness architecture, that chain is owned by the meta-harness, not by any sub-harness. A finding produced by CAI and a finding produced by Claude Code both land in the same evidence log, with the same schema, stamped with the same engagement ID and scope ref. The sub-harnesses do not even know the evidence log exists. The proxy intercepts their tool calls and writes the records transparently.
This is the property that makes the meta-harness legally defensible. When the client asks how a finding was obtained, the answer is one query against one log — not a reconciliation exercise across three tools' separate evidence stores.
[SLIDE 7 — S05.2: The security primitive layer]
Sub-section two. A general-purpose meta-harness — one that only routes and aggregates — is not enough for offensive work. Offensive harnesses need security primitives: scope enforcement, evidence collection, rules-of-engagement enforcement. A meta-harness that routes between sub-harnesses but does not enforce these primitives is an open pipe to the network, and the sub-harnesses — which you do not control — will eventually call out of scope, fail to log evidence, or violate the RoE.
The gap is real. CAI has its own scope model. Claude Code has none. Codex CLI is a coding tool with no concept of scope at all. The meta-harness must impose the primitives uniformly, regardless of which sub-harness is executing. This is the security primitive layer: a middleware that wraps every sub-harness and applies the five primitives without modifying the sub-harness's code.
[SLIDE 8 — The five primitives]
Five primitives. Each must live at the meta-harness level, and each is justified by what breaks if it is delegated to a sub-harness.
One. Scope enforcement. Every outbound tool call — every nmap scan, every HTTP request, every file read — is checked against the engagement scope file before execution. This is S Zero Zero point three and S Zero Two point two's scope middleware, lifted to the meta-harness boundary. It cannot live in a sub-harness because the sub-harnesses do not all implement it, and the ones that do implement it differently. One scope file, one enforcement point, applied to every sub-harness through the proxy.
Two. Evidence collection. Every tool call's request and response is captured into the append-only, hash-chained evidence log. The sub-harness does not opt in. The proxy intercepts the call and writes the record. Delegate this to a sub-harness and you get three logs with three schemas and three hash chains — useless for legal defense.
Three. Kill chain state. The engagement's position in the attack kill chain — recon, weaponize, deliver, exploit, post-exploit — is tracked at the meta-harness level. This is S Zero Three's kill chain state machine, generalized. The meta-harness knows "we are in the exploitation phase against target X" and can enforce phase-appropriate controls. Post-exploit actions require explicit operator confirmation, even in CTF contexts where other gates are removed. Sub-harnesses report phase transitions. The meta-harness holds the authoritative state.
Four. Signal/noise filtering. The triage pipeline from S Zero Two point four runs at the meta-harness level. Findings from any sub-harness — CAI's nuclei output, Claude Code's code review findings, Codex CLI's static analysis — flow through the same dedup, severity, enrichment, and model-judged triage. This is what produces one prioritized finding list per engagement. If each sub-harness triages its own output, the operator reconciles three finding lists with three severity schemes.
Five. Rules-of-engagement enforcement. The RoE — max requests per second, prohibited actions, time windows, data-handling restrictions — is enforced at the proxy. A sub-harness that wants to send two hundred requests per second is throttled to the RoE cap regardless of what it thinks its own limit is.
The argument is the same for all five: you do not control the sub-harnesses. A sub-harness update can silently change or remove a primitive. The only way to guarantee that every outbound call is scope-checked, evidence-logged, RoE-compliant, and triaged consistently is to enforce it at the one choke point every sub-harness must pass through: the proxy.
[SLIDE 9 — The middleware pattern]
The security primitive layer is implemented as middleware. It wraps the sub-harness's tool-call interface. The sub-harness calls a tool. The middleware intercepts the call, applies the primitives, executes or blocks, and returns the result. The sub-harness's code is unchanged.
Walk through the path. The sub-harness emits a tool call. Three gates run first. Scope check — is the target-action in scope? RoE check — is the action prohibited, or would it exceed the rate cap? Kill chain gate — is the action permitted in the current phase? Any gate failing blocks the call, stamps a scope ref, and logs the block. If all gates pass, the call executes via the sub-harness's own executor. The result is then evidence-logged, hash-chained, scope-ref stamped. If it contains a finding, it is triaged. Then cost-accounted. The sub-harness sees only the structured result.
The key point: the sub-harness has no idea the primitives ran. This is what makes the pattern robust to sub-harness updates. The primitives are not in the sub-harness's code path, so they cannot be removed by a sub-harness change. CAI ships an update that breaks its internal scope model — your proxy still checks scope. Claude Code adds a feature that bypasses its evidence logging — your proxy still logs. The wrap holds.
[SLIDE 10 — S05.3: Benchmarking]
Sub-section three. 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 versus Claude Code for a given task class is actually better. You cannot tell whether the security primitives are catching real violations. You cannot tell whether the harness is competitive with published baselines. You are operating on feel, and feel is how unmeasured changes get mistaken for improvements.
Six metrics cover offensive harness performance. Each measures a different failure mode. Detection rate — of seeded vulnerabilities, how many the harness finds. Exploit success rate — of detected vulnerabilities, how many are exploitably demonstrated, not just asserted. False positive rate — of findings surfaced, how many are not real. Evidence completeness — of findings, how many have a complete, reproducible evidence chain. Time-to-first-finding — wall-clock from engagement start to the first confirmed finding. Cost per finding — dollars, tokens plus compute, divided by confirmed findings.
The targets are starting points, not absolutes. The discipline is measuring consistently and tracking the trend across harness versions. A change that improves detection rate by five points but doubles cost per finding is a tradeoff, not a win. You can only see that tradeoff if you measure all six.
[SLIDE 11 — InjecAgent: the pass/fail gate]
Before benchmarking offensive performance, the harness must pass a safety gate. It must resist adversarial manipulation of its tool output. InjecAgent is the benchmark for this — a suite of injection attacks against agent tool-calling, with pass/fail scoring on whether the agent executed the injected action.
InjecAgent is a pass/fail gate, not a performance metric, because the failure mode is catastrophic. A harness that finds ninety-five percent of vulnerabilities but executes injected commands from target output is not a harness you can operate against real targets. It will eventually exfiltrate scope, modify evidence, or call out-of-scope systems because a target response told it to. The S Zero One point three reader-actor separation and S Zero Two point one's structured-summary-only memory are the defenses. InjecAgent is the test that proves they work.
The gate is simple. Run InjecAgent against the meta-harness with the security primitive layer enabled. The harness must refuse every injected action. No exceptions. A single execution of an injected command is a fail, regardless of how the harness scored on the six metrics. Fix the injection resistance before benchmarking anything else. A harness that benchmarks well but fails InjecAgent is a harness that will betray you in production.
[SLIDE 12 — Baselines + the repeatable lab]
Three published baselines give external reference points. CAI CTF benchmarks — use these to validate the S Zero Four router and the CTF sub-harness's solve rate. EVMbench, for smart contract work — use these when the meta-harness routes to a smart-contract sub-harness. RedTeamLLM CTF results — use these as a competitive baseline for offensive reasoning quality.
The point of comparison is not to beat the published number. It is to confirm your harness is in the same order of magnitude and to identify where it is systematically worse. A harness that scores forty percent detection rate where the baseline scores eighty-five has an architecture problem, not a tuning problem.
A benchmark is only useful if it is repeatable. The lab has four properties. Isolated targets — Docker containers or VMs with known, seeded vulnerabilities. No live targets; live targets change and invalidate the baseline. Seeded vulnerabilities — each target has a documented vulnerability set. The harness's findings are scored against this set. Consistent scoring methodology — the same scoring script runs against every harness version. Fixed compute envelope — same model, same token budget, same wall-clock limit per run. A harness that scores higher because it consumed three times the compute is not better. It is more expensive.
The output of a benchmark run is a scored report: the six metrics, the InjecAgent pass or fail, and a comparison against the previous run and the published baseline. This is the artifact you publish — internally or externally — to defend the architecture.
[SLIDE 13 — What you take forward]
The meta-harness is operational. It routes between sub-harnesses through a local proxy. It enforces the five security primitives at the proxy boundary, uniformly, regardless of which sub-harness is executing. It aggregates one evidence log and one cost ledger per engagement. And it is benchmarked against a repeatable lab, with InjecAgent as the pass/fail gate that runs first.
Pillar Two — AppSec and 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.
That is the end of Pillar One. You now have the full offensive stack: the bug bounty harness, the pentest and red team harness, the CTF harness, and the meta-harness that routes between them and enforces the primitives that make the whole thing safe to operate. Pillar Two builds on this foundation for defensive work.
[End of script]
# Teaching Script — Module S05: Meta-Harness Architecture for Offensive Operations **Module**: S05 — Meta-Harness Architecture for Offensive Operations · **Duration**: ~60 minutes **Format**: Verbatim transcript. Cues `[SLIDE N]` map to `03-slide-deck.html`. --- [SLIDE 1 — Title] This is Module S Zero Five: Meta-Harness Architecture for Offensive Operations. Sixty minutes. The final module of Pillar One, and the one that ties S Zero Two, S Zero Three, and S Zero Four together. Each of those modules built a harness tuned to one engagement shape — bug bounty, pentest and red team, CTF. A real offensive organization runs all of them, plus web application security, plus smart contract auditing, plus cloud attack-path discovery, concurrently. This module is about how you operate all of that without it collapsing into one incoherent super-harness. Three sub-sections. First: when a single harness is the wrong architecture, and the CSI scaffold-combiner model from Alias Robotics. Second: the security primitive layer — the five primitives that must live at the meta-harness level, not in any sub-harness. Third: benchmarking your offensive harness, with InjecAgent as a pass/fail gate. By the end you can design a meta-harness that routes between specialized sub-harnesses through a local proxy, enforce the security primitives uniformly regardless of which sub-harness is executing, and prove the architecture is worth operating with a repeatable benchmark. [SLIDE 2 — Why a single harness is wrong] Start with the failure mode. The naive response to "we run bug bounty, pentest, CTF, appsec, smart contracts, cloud" is to build one harness that does everything. Load every tool, every prompt, every primitive into a single agent. That harness fails for three compounding reasons — and they are the same three reasons a single CTF agent fails, from S Zero Four point one, just at a larger surface area. Context pollution. A bug bounty engagement does not need ROPgadget in the tool manifest. A smart contract audit does not need ffuf. Loading every tool description into every session inflates the system prompt, dilutes the model's tool-selection signal, and consumes context the engagement itself needs. Empirically, models with broad tool manifests call the wrong tool more often than models with narrow manifests. Reasoning drift. The mental mode for exploit development — careful hypothesis testing, low-level memory reasoning — is the opposite of the mode for broad fuzzing. A model instructed to be good at both will be excellent at neither. Specialized system prompts per domain, written by domain experts, measurably outperform a generic prompt that tries to cover everything. Token waste. Each tool's schema, examples, and invocation cost is paid every turn. Six domains of tools means six domains of overhead, every turn, on every engagement. You are paying for capability you are not using, and the capability you are using is diluted by the capability you are not. The cure is the meta-harness: a thin orchestration layer that classifies the task, selects the right specialized sub-harness, and enforces the primitives that are common to every engagement. The sub-harnesses stay specialized. The meta-harness owns what is true regardless of which sub-harness is running. [SLIDE 3 — S05.1: CSI architecture] Sub-section one. The architecture worth studying is CSI — Common Scaffold Interface — developed at Alias Robotics. CSI is a scaffold combiner. It does not implement offensive capability itself. It routes work between existing specialized harnesses — CAI for cybersecurity operations, Claude Code for code-aware reasoning, Codex CLI for agentic software engineering, and others — through a local proxy that every sub-harness talks to. The flow is straightforward. An operator task enters the task classifier. The classifier emits a domain label. The harness selector — a deterministic lookup, not a model call — maps that label to a sub-harness configuration: its system prompt, its tool subset, its context budget, its human-in-the-loop posture. Shared context — the scope file, the rules of engagement, a handle to the engagement memory, the engagement ID — is loaded once and passed by reference. Then the local proxy routes the work to the selected sub-harness, intercepting every tool call to apply the security primitives and aggregate telemetry. The output is unified: findings, an evidence chain, and a cost ledger, all in one schema, regardless of which sub-harness did the work. [SLIDE 4 — The local proxy is load-bearing] Here is the design decision that makes the whole architecture work. The local proxy is load-bearing. Every sub-harness — regardless of its native tool-calling format, its native model provider, its native auth scheme — talks to the same proxy endpoint. The proxy owns the security primitives, the scope enforcement, the evidence logging, the rate limiting. A sub-harness cannot bypass the proxy because the proxy is the only thing it can reach. This matters because the sub-harnesses are not under your control. CAI, Claude Code, and Codex CLI are external tools. They have their own update cadences, their own tool surfaces, their own prompt regimes. You cannot modify their internals. You can only wrap them. The proxy is the wrap. This is the same defense-in-depth argument as S Zero Two point two's scope check in both middleware and tool — but lifted to the inter-harness boundary. There, the argument was: if the middleware is bypassed, the tool's own check is the last line of defense. Here, the argument is: if a sub-harness's internal scope model breaks or was never there, the proxy's check is the last line of defense. Belt and suspenders, at the architecture boundary. [SLIDE 5 — Meta-harness: four responsibilities] The meta-harness has four jobs. Anything outside these four belongs in a sub-harness. First, task classification. Read the incoming task — a bug bounty brief, a CTF challenge, a pentest scope, a code-review request — and emit a domain label. This is the S Zero Four point one meta-agent pattern, generalized. A small, fast classifier, model or deterministic, routes to the right specialist. When the classifier is uncertain, a TriageAgent runs cheap probes — target type, scope, attached artifacts — and re-routes. The meta-harness does not solve the task. It decides who does. Second, harness selection. Map the domain label to a sub-harness and load its configuration. This is a lookup table, not a model call. Once classification is done, the mapping is deterministic. A bug bounty task routes to the S Zero Two harness. A CTF task routes to the S Zero Four harness. A code-review task routes to Codex CLI with the SDLC prompt and no offensive tools loaded at all. Third, telemetry aggregation. Every sub-harness emits telemetry — tool calls, model invocations, tokens consumed, findings produced. The meta-harness aggregates this into one ledger per engagement. This is what makes cross-harness cost control and benchmarking possible. There is one place to read "what did this engagement cost and what did it find" instead of reconciling logs from three tools with three formats. Fourth, cost control. The meta-harness enforces a per-engagement budget — total tokens, total dollars, total wall-clock. When a sub-harness exhausts its allocation, the meta-harness either re-routes to a cheaper sub-harness, degrades gracefully by narrowing the tool surface or reducing parallelism, or halts and surfaces to the operator. Cost control cannot live in a sub-harness because a sub-harness only sees its own consumption. Only the meta-harness sees the total. [SLIDE 6 — Shared context, one evidence log] Two properties that prevent the most common operational failure. First, shared engagement context. Every sub-harness reads the same scope file, the same rules of engagement, the same engagement memory handle, the same engagement ID. The sub-harness does not own this context. It borrows it. The meta-harness loads it once at engagement start and passes a reference. This prevents the "three harnesses, three scope files" failure. If CAI loads its own scope, Claude Code loads its own scope, and Codex CLI has no scope at all, the operator is responsible for keeping them synchronized. They will drift. Drifted scope is how out-of-sscope tool calls happen. The cure is one scope file, owned by the meta-harness, read-only to every sub-harness. Second, cross-harness evidence aggregation. S Zero Two point three established the evidence chain — append-only, hash-chained, scope-referenced. In a meta-harness architecture, that chain is owned by the meta-harness, not by any sub-harness. A finding produced by CAI and a finding produced by Claude Code both land in the same evidence log, with the same schema, stamped with the same engagement ID and scope ref. The sub-harnesses do not even know the evidence log exists. The proxy intercepts their tool calls and writes the records transparently. This is the property that makes the meta-harness legally defensible. When the client asks how a finding was obtained, the answer is one query against one log — not a reconciliation exercise across three tools' separate evidence stores. [SLIDE 7 — S05.2: The security primitive layer] Sub-section two. A general-purpose meta-harness — one that only routes and aggregates — is not enough for offensive work. Offensive harnesses need security primitives: scope enforcement, evidence collection, rules-of-engagement enforcement. A meta-harness that routes between sub-harnesses but does not enforce these primitives is an open pipe to the network, and the sub-harnesses — which you do not control — will eventually call out of scope, fail to log evidence, or violate the RoE. The gap is real. CAI has its own scope model. Claude Code has none. Codex CLI is a coding tool with no concept of scope at all. The meta-harness must impose the primitives uniformly, regardless of which sub-harness is executing. This is the security primitive layer: a middleware that wraps every sub-harness and applies the five primitives without modifying the sub-harness's code. [SLIDE 8 — The five primitives] Five primitives. Each must live at the meta-harness level, and each is justified by what breaks if it is delegated to a sub-harness. One. Scope enforcement. Every outbound tool call — every nmap scan, every HTTP request, every file read — is checked against the engagement scope file before execution. This is S Zero Zero point three and S Zero Two point two's scope middleware, lifted to the meta-harness boundary. It cannot live in a sub-harness because the sub-harnesses do not all implement it, and the ones that do implement it differently. One scope file, one enforcement point, applied to every sub-harness through the proxy. Two. Evidence collection. Every tool call's request and response is captured into the append-only, hash-chained evidence log. The sub-harness does not opt in. The proxy intercepts the call and writes the record. Delegate this to a sub-harness and you get three logs with three schemas and three hash chains — useless for legal defense. Three. Kill chain state. The engagement's position in the attack kill chain — recon, weaponize, deliver, exploit, post-exploit — is tracked at the meta-harness level. This is S Zero Three's kill chain state machine, generalized. The meta-harness knows "we are in the exploitation phase against target X" and can enforce phase-appropriate controls. Post-exploit actions require explicit operator confirmation, even in CTF contexts where other gates are removed. Sub-harnesses report phase transitions. The meta-harness holds the authoritative state. Four. Signal/noise filtering. The triage pipeline from S Zero Two point four runs at the meta-harness level. Findings from any sub-harness — CAI's nuclei output, Claude Code's code review findings, Codex CLI's static analysis — flow through the same dedup, severity, enrichment, and model-judged triage. This is what produces one prioritized finding list per engagement. If each sub-harness triages its own output, the operator reconciles three finding lists with three severity schemes. Five. Rules-of-engagement enforcement. The RoE — max requests per second, prohibited actions, time windows, data-handling restrictions — is enforced at the proxy. A sub-harness that wants to send two hundred requests per second is throttled to the RoE cap regardless of what it thinks its own limit is. The argument is the same for all five: you do not control the sub-harnesses. A sub-harness update can silently change or remove a primitive. The only way to guarantee that every outbound call is scope-checked, evidence-logged, RoE-compliant, and triaged consistently is to enforce it at the one choke point every sub-harness must pass through: the proxy. [SLIDE 9 — The middleware pattern] The security primitive layer is implemented as middleware. It wraps the sub-harness's tool-call interface. The sub-harness calls a tool. The middleware intercepts the call, applies the primitives, executes or blocks, and returns the result. The sub-harness's code is unchanged. Walk through the path. The sub-harness emits a tool call. Three gates run first. Scope check — is the target-action in scope? RoE check — is the action prohibited, or would it exceed the rate cap? Kill chain gate — is the action permitted in the current phase? Any gate failing blocks the call, stamps a scope ref, and logs the block. If all gates pass, the call executes via the sub-harness's own executor. The result is then evidence-logged, hash-chained, scope-ref stamped. If it contains a finding, it is triaged. Then cost-accounted. The sub-harness sees only the structured result. The key point: the sub-harness has no idea the primitives ran. This is what makes the pattern robust to sub-harness updates. The primitives are not in the sub-harness's code path, so they cannot be removed by a sub-harness change. CAI ships an update that breaks its internal scope model — your proxy still checks scope. Claude Code adds a feature that bypasses its evidence logging — your proxy still logs. The wrap holds. [SLIDE 10 — S05.3: Benchmarking] Sub-section three. 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 versus Claude Code for a given task class is actually better. You cannot tell whether the security primitives are catching real violations. You cannot tell whether the harness is competitive with published baselines. You are operating on feel, and feel is how unmeasured changes get mistaken for improvements. Six metrics cover offensive harness performance. Each measures a different failure mode. Detection rate — of seeded vulnerabilities, how many the harness finds. Exploit success rate — of detected vulnerabilities, how many are exploitably demonstrated, not just asserted. False positive rate — of findings surfaced, how many are not real. Evidence completeness — of findings, how many have a complete, reproducible evidence chain. Time-to-first-finding — wall-clock from engagement start to the first confirmed finding. Cost per finding — dollars, tokens plus compute, divided by confirmed findings. The targets are starting points, not absolutes. The discipline is measuring consistently and tracking the trend across harness versions. A change that improves detection rate by five points but doubles cost per finding is a tradeoff, not a win. You can only see that tradeoff if you measure all six. [SLIDE 11 — InjecAgent: the pass/fail gate] Before benchmarking offensive performance, the harness must pass a safety gate. It must resist adversarial manipulation of its tool output. InjecAgent is the benchmark for this — a suite of injection attacks against agent tool-calling, with pass/fail scoring on whether the agent executed the injected action. InjecAgent is a pass/fail gate, not a performance metric, because the failure mode is catastrophic. A harness that finds ninety-five percent of vulnerabilities but executes injected commands from target output is not a harness you can operate against real targets. It will eventually exfiltrate scope, modify evidence, or call out-of-scope systems because a target response told it to. The S Zero One point three reader-actor separation and S Zero Two point one's structured-summary-only memory are the defenses. InjecAgent is the test that proves they work. The gate is simple. Run InjecAgent against the meta-harness with the security primitive layer enabled. The harness must refuse every injected action. No exceptions. A single execution of an injected command is a fail, regardless of how the harness scored on the six metrics. Fix the injection resistance before benchmarking anything else. A harness that benchmarks well but fails InjecAgent is a harness that will betray you in production. [SLIDE 12 — Baselines + the repeatable lab] Three published baselines give external reference points. CAI CTF benchmarks — use these to validate the S Zero Four router and the CTF sub-harness's solve rate. EVMbench, for smart contract work — use these when the meta-harness routes to a smart-contract sub-harness. RedTeamLLM CTF results — use these as a competitive baseline for offensive reasoning quality. The point of comparison is not to beat the published number. It is to confirm your harness is in the same order of magnitude and to identify where it is systematically worse. A harness that scores forty percent detection rate where the baseline scores eighty-five has an architecture problem, not a tuning problem. A benchmark is only useful if it is repeatable. The lab has four properties. Isolated targets — Docker containers or VMs with known, seeded vulnerabilities. No live targets; live targets change and invalidate the baseline. Seeded vulnerabilities — each target has a documented vulnerability set. The harness's findings are scored against this set. Consistent scoring methodology — the same scoring script runs against every harness version. Fixed compute envelope — same model, same token budget, same wall-clock limit per run. A harness that scores higher because it consumed three times the compute is not better. It is more expensive. The output of a benchmark run is a scored report: the six metrics, the InjecAgent pass or fail, and a comparison against the previous run and the published baseline. This is the artifact you publish — internally or externally — to defend the architecture. [SLIDE 13 — What you take forward] The meta-harness is operational. It routes between sub-harnesses through a local proxy. It enforces the five security primitives at the proxy boundary, uniformly, regardless of which sub-harness is executing. It aggregates one evidence log and one cost ledger per engagement. And it is benchmarked against a repeatable lab, with InjecAgent as the pass/fail gate that runs first. Pillar Two — AppSec and 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. That is the end of Pillar One. You now have the full offensive stack: the bug bounty harness, the pentest and red team harness, the CTF harness, and the meta-harness that routes between them and enforces the primitives that make the whole thing safe to operate. Pillar Two builds on this foundation for defensive work. --- [End of script]