Module S01 — Security Harness Architecture

Security Harness Architecture

The offensive state machine, scope enforcement as hard-wired middleware, and the adversarial tool output problem. Three architectural changes that make a general harness into a security harness.

60
minutes
8
artifacts
3
sub-sections
Course 1 assumed a cooperative target. The model reads files, calls tools, outputs are trusted. None of that holds when the target is an adversary. This module covers the three architectural changes — the loop, the tool layer, and the trust model — that make a general harness into a security harness.
Key Claims
Load-Bearing Claims

The offensive state machine is a specialization of ReAct, not a replacement — adversarial inputs, evidence-driven stops, domain-specific evidence.

Scope enforcement is a distinct control plane from sandboxing. Both required. Sandbox = local containment. Scope = network authorization.

~50% of agentic tasks are vulnerable to indirect prompt injection via tool outputs (InjecAgent). Every external read is potentially hostile.

Reader-actor separation is the strongest single defense — the actor never sees raw adversarial content.

After This Module
01
Draw the offensive state machine (Recon → Hypothesis → Exploit → Evidence → Triage → Report) and name every structural difference from ReAct.
02
Implement scope enforcement middleware that intercepts every outbound tool call — and explain why it is distinct from code-execution sandboxing.
03
Map the CAI autonomy-level model (Level 0–5) and defend which level is appropriate for a given engagement type.
04
Explain the InjecAgent finding and apply untrusted-content tagging in the offensive context.
05
Specify why offensive harnesses need a stricter trust model: every external read is potentially hostile.
Artifacts