How We Tried to Break an Autonomous AI System

An AI system cannot meaningfully claim to be secure if it is allowed to generate the attacks, authorize the attacks, evaluate the attacks, and report the results. H33-Agent-008 separates those four authorities cryptographically and attacks each independently — and every result is bound to an evidence package a third party can replay after the fact.

H33-Agent-008 documents an attempt to break the governance layer of an autonomous AI system: the authority, identity, execution, evidence-integrity, replay/provenance, and supply-chain boundaries that decide whether an agent’s action is permitted and whether a result is real.

Unlike agentic red teaming that relies on the same AI to generate, execute, evaluate, and report outcomes, H33-Agent-008 separates attack generation from authorization, execution, evidence, and verification. AI may generate adversarial hypotheses; it cannot determine whether an attack succeeded.

Honesty gate (read this first). Of 93 enumerated attack classes, 54 were run — the governance, cryptographic, execution, operator-abuse, swarm-dynamics, and memory/context boundaries. The 26 model-in-the-loop classes (prompt injection, adversarial ML, poisoning, privacy extraction, model-behavior, memory/retrieval poisoning) are classified GovernedTargetRequired and have not run — they need an attached governed model, which we do not fake. The remaining 13 are runtime-dependent and armed but unrun. So the model-facing portion of “AI red teaming” is precisely the unrun portion. All results below were produced against constructed inputs and ephemeral signing keys; the deployed Agent-008 is not yet independently identified through H33-BIND, and no production swarm has run. Mechanism claims are stated in the present tense; every outcome claim is a result of the constructed suite, marked [constructed]. Production identity, results, and benchmarks are the Production Validation report, marked [Production]. The full 93 are published in Appendix A. We do not hide unfinished vectors.

How to read this paper

Four terms, used precisely throughout — they are not synonyms:

• Attack class — one item in the published taxonomy (e.g. evidence tamper). There are 93.
• Attack obligation — the requirement that a class be tested, with a defined expected governed outcome. One obligation per class.
• Campaign — a group of related attack classes run together (C1…C13).
• Boundary — the architectural surface a class challenges (authority, execution, evidence, memory, …).

Evidence tier — never quote across the line. Every outcome carries a tier badge: CONSTRUCTED = constructed inputs + ephemeral keys — this report; PRODUCTION = a commissioned runtime + anchored keys — Paper #3, not yet produced. A CONSTRUCTED result must never be quoted as a PRODUCTION result. Everything below this line is CONSTRUCTED unless explicitly badged PRODUCTION.

Abstract

Autonomous AI systems introduce a security problem the model alone does not capture: the same system that generates decisions can also generate attacks, manipulate workflows, obscure failures, and misreport its own security posture. The governance layer around the model — who authorized an action, which exact code ran, what evidence exists, and whether that evidence can be independently reproduced — is where those failures are caught or missed.

This paper documents an attempt to break that governance layer. We enumerate 93 adversarial attack classes spanning governance, authority, cryptography, identity, execution/admission, evidence integrity, replay/provenance, privacy, supply chain, operator abuse, swarm dynamics, and memory/context, and run the 54 that do not require an attached model. Testing included attempts to bypass authority, manipulate evidence, create impossible states, exploit identity confusion, introduce replay attacks, abuse operator privilege, manufacture swarm consensus, poison stored memory and retrieved context, abuse AI-generated attack paths, and compromise the evaluation process itself.

Every evaluated result is tied to governed execution, tamper-evident cryptographic evidence, and out-of-process replay verification — a verifier that shares no code with the system it checks. Replay is the load-bearing idea of this paper: it is what separates an engineering claim from one that merely asks the reader to trust the authors — attack → evidence → replay → truth. A claim survives only if a party outside the producer can reproduce it from the evidence alone. The methodology is the H33 Verification Methodology (HVM), which separates adversarial creativity from authorization, execution, evidence, and final determination.

We document what was tested, what was not (the 26 model-in-the-loop classes, and 13 runtime-dependent), and — as much as the results — how we attempted to prove ourselves wrong.

Results at a glance

H33-Agent-008 was evaluated against a 93-obligation adversarial registry. The headline is a control- conformance result under tested conditions — not a universal-security claim.

Tested governance effectiveness — adversarial attack campaigns [constructed]: - 93 attack obligations defined - 54 executable-native attacks tested - 54 / 54 produced the expected governed outcome - 0 evidence-laundering states accepted - 0 impossible-state transitions accepted - 0 fabricated success paths accepted - 100% replay verification of generated evidence packages - 26 AI-model-in-the-loop attacks reserved for production AI-target validation - 13 runtime-dependent attacks armed, not yet production-executed

Headline metric — 54 of 54 executed attack obligations produced the expected governed outcome under replay verification — 100% control conformance under tested conditions. Always read with that context: this is not “100% secure,” “AI attacks defeated,” “all attacks blocked,” or “54 vulnerabilities found.” It is a scoped, replayable, controls-behaved-as-specified result.

Attack effectiveness — four different measurements, reported separately [constructed]. Collapsing these into one “54/54” is exactly the misread we refuse: an attack run has four independent success questions, and they do not mean the same thing.

“Attack generation 54/54” means the swarm really did produce meaningful attacks — not that the attacks were weak. “Control 54/54” means governance refused them. “Replay 54/54” means a third party can reproduce that. None of the three implies the system defeated every conceivable attack — that is why we separate them.

What the attacker achieved vs. what the governance layer allowed (tested classes) [constructed]: The H33-SWARM campaign generated and executed governed adversarial obligations against Agent-008. The swarm is the attacker, not the judge — it never determines whether an attack succeeded. The goal was never to stop the swarm from thinking of attacks; it was to stop unauthorized consequences.

These results demonstrate control correctness under the tested adversarial obligations. They do not represent a claim of universal AI security or complete attack-space coverage. The 26 model-in-the-loop classes are reserved for production AI-target validation; the full per-class registry is Appendix A.

The Challenge · The Test · The Proof

The Challenge — can the governance layer around an autonomous agent be made to: authorize an unauthorized outcome, accept manipulated evidence, admit an impossible state, confuse identity or authority, or report a success that did not happen?

The Test — 54 governance, cryptographic, execution, operator-abuse, swarm, and memory/context attack classes (of 93 enumerated), run against the real governed system.

The Proof — cryptographic evidence and out-of-process replay: the verdict is produced by a verifier that shares no code with the system under test.

One attack, end to end CONSTRUCTED

If you read only one thing, read this. A single obligation, traced the whole way — attack → evidence → replay → truth — so the rest of the paper is just this shape, 54 times.

Attack class — admission command substitution (C10-A001). Boundary: execution / admission.

1. Objective. Make the governed executor run command B while holding an authorization bound to command A — i.e. turn a legitimate approval into an unauthorized action.
2. Attack generated (untrusted AI). The swarm proposes presenting a valid AdmissionToken for A while requesting B, plus mutations (argv reorder, cwd swap, env-policy swap). This is a real, meaningful attack — the swarm is a capable adversary.
3. Governance decision. The admission layer re-asserts the command commitment (authority → binding → fork) and rejects the mismatch before any file-descriptor dup or fork. Verdict: CommandMismatch. No child process is ever created.
4. Evidence artifact. An H33-74 package binds the Root attack-intent hash, both H33-BIND identities, and the observation (earliest stopping layer = admission::command-commitment). It is tamper-evident: its self-hash recomputes from its fields, so any mutation is detectable.
5. Replay. The independent, out-of-process Reference Verifier — given only the package bytes and the Root public key, sharing no code with Agent-008 — reproduces STOPPED @ admission::command-commitment, and refuses the same package under a foreign key.
6. Final conclusion. Attack generated ✓ · control refused ✓ · a third party reproduced the refusal from bytes alone ✓. The result is not “trust us” — it is a package you can replay. CONSTRUCTED: no production runtime was involved.

That last step — a third party reproduced the refusal from bytes alone — is the one most red-team reports cannot produce, and it is the paper in miniature.

1. Executive summary

We assumed our own governance layer was breakable and built an adversarial program — H33-SWARM — to break it. We defined 93 adversarial attack obligations spanning governance, authority, cryptography, identity, execution, privacy, supply chain, operator abuse, swarm dynamics, and memory/context attacks. 54 are executable natively, 26 require governed AI targets, and 13 require production runtime conditions. Every executed obligation produces replayable cryptographic evidence. 54 ran (Appendix A); the 26 model-in-the-loop and 13 runtime-dependent obligations are enumerated and armed but unrun — the denominator is a statement of the attack space we recognize, not a number optimized around what happens to be runnable today.

The strongest evidence is not “everything passed.” It is the record of what broke, what changed, and the structural guarantee that no result reaches the scoreboard without governed execution, tamper-evident H33-74 evidence, and out-of-process replay.

We state the result carefully, because the careful version is the defensible one. The claim is not “all attacks failed.” It is: every one of the 54 tested obligations produced the expected governed outcome under the defined execution and evidence rules [constructed] — evidence-laundering, impossible-state, unauthorized-authority, replay-inconsistency, and evaluator-manipulation attempts each refused at the boundary as an ingest failure, never a scored result. That is a scoped, deterministic-control statement — the controls behaved as specified, within a defined scope, reproducibly — not a claim that the system is unbreakable. What makes it credible rather than self-asserted is the trust boundary in §2, the attacker model in §3, and the independence limits we are explicit about in §8.

2. Why the governance layer needs a new red-teaming model

Most agentic red teaming collapses generation, execution, and judgement into the same untrusted model. For a system that can also generate attacks and misreport its posture, that is circular — the concern reviewers rightly raise is “how do I know the AI didn’t simply convince itself it was right?”

We agree, and solved it by moving AI to the one place its failure mode is harmless — idea generation, where a wrong idea is simply rejected. The whole thesis is one boundary:

        ══════════════════════  UNTRUSTED  ══════════════════════
              AI attack generation
              hypotheses · mutations · chains · coverage ideas
                             │
        ═════════════════  TRUST BOUNDARY  ═══════════════════════
                             ▼
              ┌─────────────────────────────────────┐
              │  Governance admission · H33-Root     │   no authorization ⇒ it does not run
              └─────────────────────────────────────┘
                             ▼
              Authorized attack plan                     bound to the exact composition root
                             ▼
              Execution runtime                          one governed execution edge
                             ▼
              H33-74 evidence package                    tamper-evident, self-hashed
                             ▼
              Independent replay                         out of process; shares no code with the system
                             ▼
                        ▓▓  TRUTH  ▓▓                     the verdict — not the AI's opinion

The whole difference in one picture — the same intelligence closing its own loop, versus authorities separated:

     TRADITIONAL AI RED TEAM          │        H33 — CRYPTOGRAPHICALLY GOVERNED
                                      │
             AI                       │                  AI
              │                       │                   │
              ▼                       │                   ▼
           Attack                     │            Attack proposal          ← UNTRUSTED
              │                       │                   │
              ▼                       │        ═══════  TRUST BOUNDARY  ═══════
          AI  judge   ←── the same    │              Governance
              │        intelligence   │                   │
              │        grades its     │                   ▼
              ▼        own work        │              Authorization
           Report      "trust me"     │                   │
                                      │                   ▼
                                      │               Execution
                                      │                   │
                                      │                   ▼
                                      │                Evidence
                                      │                   │
                                      │                   ▼
                                      │                 Replay
                                      │                   │
                                      │                   ▼
                                      │        Independent conclusion        ← TRUTH

On the left, the judge is the attacker. On the right, no single authority — attacker, executor, or evaluator — can define the outcome alone.

Everything above the trust boundary is untrusted: the AI can generate anything, prioritize wrongly, or claim any coverage — and none of it becomes a result. Everything below is governed: admission, execution, evidence, and replay each independently constrain what can be true. AI never determines whether the attack succeeded. We call this Cryptographically Governed AI Red Teaming: the model authors nothing past the hypothesis — authorization, execution, evidence, verdict, and every published figure come from governed components the model cannot write.

3. Attacker model and trusted computing base

Every cryptographic claim below holds only relative to this model; violate the TCB and the claim is withdrawn (this connects directly to §9, Falsifiability).

The adversary controls: the AI/swarm and all of its outputs (hypotheses, payloads, mutations, prioritization, coverage claims); the attack inputs and payloads; the ability to submit crafted, plausible- but-wrong evidence and replay packages; substituted binaries, artifacts, and identity strings; and — within the tests — reordered, delayed, or duplicated events. The adversary is assumed to be able to try anything the swarm can express.

The trusted computing base (TCB) — what the adversary does not control: - the H33-Root authority private keys (operator custody; the production commission is an offline, operator-only signature — no key in CI or the repo); - the canonical composition root the census admits as the single runtime; - the verifier binary and its independently-supplied trust anchor (the public keys reach the verifier out-of-band, never from the package it checks); - the canonical serialization (RFC 8785 JCS + SHA3-384) and the soundness of the PQ primitives (§8).

Explicit assumptions: authority keys are not exfiltrated; the verifier runs on an uncompromised host with the correct anchor; the PQ families are not broken. We do not claim security if the TCB is violated — a stolen Root key, a compromised verifier host, or a broken primitive each withdraws the corresponding claim. What we do claim is that, absent a TCB compromise, the governance boundary refuses the attacker’s moves — and that this is checkable by replay, not by trusting us.

4. The attack program

No attack runs free. The canonical, type-enforced path:

H33-Root AttackIntent → authorize() → AuthorizedAttack
   → run attack (against the exact composition root)
   → AttackObservation → complete() → H33-74 evidence
   → Swarm::ingest(CompletedGovernedAttack)      ← the ONLY scoreboard entry

No verified Root intent ⇒ the attack did not run. No H33-74 evidence ⇒ it did not complete. No CompletedGovernedAttack ⇒ no scoreboard result — there is no bare-record path. At ingest, the Root intent, the H33-74 evidence, the internal record, and the immutable baseline must agree on composition root, product/code identity, attack id, and intent-hash; the evidence must be tamper-evident; and both mandatory H33-BIND identities must be present. A mismatch is an ingest failure, never a scored result.

The enumeration is fixed and never shrunk; classification separates where a class belongs from did it run (nothing is green by classification):

On the denominator (we write the exam, so we say so). 93 is our number, from our taxonomy, and we apply no external severity weighting. EvidencedMissing = 0 means only that we found no gap within our own enumeration — a self-graded metric, and we flag it as such. To let a reader who does not trust us check the denominator, §5 maps the classes to external frameworks; the per-class ground truth is Appendix A.

5. External anchoring — mapping the 93 to public frameworks

A self-authored denominator is not independently meaningful. We map the boundaries to MITRE ATLAS, OWASP Top 10 for LLM Applications, and NIST AI 600-1 (Generative AI Profile) so the coverage — and the gaps — are checkable against taxonomies we did not write.

Two honest readings of this table. First, the frameworks with the most-developed model coverage (ATLAS/OWASP on C2–C5) map almost entirely onto our unrun classes — the model-facing work is ahead of us, not behind. Second, the boundaries we did run hardest (C7 replay/evidence provenance, C8 multi-root conflict, C11 operator abuse, C12 swarm dynamics) are largely not covered by ATLAS or OWASP at all — evidence integrity and governed conflict are H33’s contribution, and their absence from the external taxonomies is a reason to publish them, not a reason to claim completeness.

6. Results (constructed) [constructed]

Coverage in ten seconds. Bar length = number of obligations; █ executed and replay-verified [constructed], ░ target-required (unrun — needs an attached model):

Attack family                Executed          Target-required       Replay
──────────────────────────────────────────────────────────────────────────
Identity & Authority         ████████████                            ✓
Execution / Admission        ████████████                            ✓
Evidence / Replay            ████████                                ✓
Operator Abuse               █████                                   ✓
Multi-root Conflict          █████                                   ✓
Swarm Dynamics               ████                                    ✓
Data / Secret Leakage        ███                                     ✓
Supply Chain                 ███                                     ✓
Memory & Context             ██                ░░                     ✓
Privacy & Extraction                           ░░░░░                  —
Model Manipulation (C2/C3)                     ░░░░░░░░░░░░           —
Training / Poisoning                           ░░░░                   —
Hallucination / Reliability                    ░░░                    —
──────────────────────────────────────────────────────────────────────────
█ 54 executed & replay-verified   ░ 26 target-required (unrun)   +13 runtime-dependent, armed:
Identity +4 · Execution +7 · Supply Chain +2   (enumerated, not dropped)

The lifecycle, not just a score. Every executed obligation traverses the full chain — defined, executed, evidenced, independently replayed, and permanently pinned:

   93  attack obligations DEFINED            the recognized attack space — never shrunk
    │
    ▼
   54  EXECUTED [constructed]                the model-free boundaries
    │
    ▼
   54  bound to H33-74 EVIDENCE              tamper-evident, self-hashed
    │
    ▼
   54  independently REPLAYED                out-of-process verifier; bytes + key only
    │
    ▼
   54  pinned by REGRESSION                  reintroduction is a test failure — it cannot silently regress
    │
    ▼
   39  awaiting a model / runtime            (26 target-required + 13 runtime) — enumerated, not dropped

The acceptance bar is five zeros, tracked from the dossiers (never from state): false authorizations · unauthorized executions · cross-tenant escapes · evidence-less approvals · unexplained outcomes; false denials tracked separately.

Coverage — what was actually tested (Tested = attacked against the real code; Replay = offline reproducible; Evidence = bound in a tamper-evident H33-74 package; Regression = a test prevents recurrence):

In the constructed suite, each of the 54 tested obligations produced the expected governed outcome under the defined rules — evidence laundering (swap / cross-root / mix / corrupt); impossible states (two roots in one run / off-root record / double-execution); unauthorized authority paths (no verified intent); replay inconsistencies (package replays to a different outcome); evaluator manipulation (claimed outcome ≠ evidence-derived outcome) — each refused at the boundary as an ingest failure. We report this as controls-behaved-as-specified within a defined scope, not as nothing can break it: the value is that each outcome is deterministic and independently replayable (Appendix A), not that the number is 54/54. Production five-zero scores and benchmarks are [Production].

7. Major attack campaigns

Evidence laundering — “can valid evidence be reused incorrectly?” (run) The ingest/replay boundary rejects plausible-but-wrong evidence, not merely corrupted: swap H33-74 evidence between two attacks (intent-hash disagreement); replay valid evidence against a different composition root (rejected); mix Root intent A with H33-74 evidence B (agreement mismatch); corrupt the bound decision/ordering or drop a linked artifact (the self-hash no longer verifies).

Impossible-state attacks — “can invalid states become accepted?” (run) Two composition roots in one run (refused); an authorization whose target root disagrees with the baseline (no record minted off-root); one obligation id with two executions (single-use refuses the second). Evidence without authorization, or a scored result without H33-74, is structurally unrepresentable.

AI-manipulation attacks — “can AI generate false confidence?” An untrusted swarm can only propose. A prompt-injected agent can at most produce a hypothesis Root must authorize and evidence must confirm; it cannot mint an H33-74 package. A biased generator changes what is proposed, never what counts. (The model-behavior classes that require an attached model — C2–C5 — are unrun; see §5.)

Evaluator attacks — “can the system report incorrect success?” (run) The run-report is dossier-derived only — it fails closed on zero attacks, refuses to mix roots, and never manufactures a result from classification state. The producer’s claimed outcome travels separately from the evidence; the verifier re-derives the outcome and refuses on mismatch (ConclusionMismatch / FiveZeroMismatch): a “stopped” claim over breach evidence is rejected.

Multi-root conflict — “can competing agents create unsafe authority?” (run) A CEO transfer, CTO purchase-funding, and CFO liquidity-floor denial collide with no malicious party. Conflict evidence is never trusted as an object: reverify_evidence re-runs the deterministic detector against the signed registry.

Supply chain / identity — “can artifacts or identities be substituted?” (run) Product identity is kept strictly separate from code identity; binary/path substitution after measurement and an unreachable legacy spawn gate are covered by C9/C10.

8. Independent replay verification — and the limits of “independent”

Most AI red-team reporting stops at the observation. This one does not. The full chain is:

   Attack  →  Observation  →  Evidence package  →  Independent replay  →  Same conclusion  →  Architectural remediation

Evidence a party outside the producer can reproduce after the fact — feeding a pinned fix — is the part most organizations cannot produce today. Anyone can publish a list of attacks; very few systems let a third party independently verify exactly what happened. That is the paper’s central contribution, and the rest of this section is honest about how far the current “independence” actually goes.

The system does not get to grade itself. The Reference Independent Replay Verifier is its own crate + binary that consumes only the Root authorization, the H33-74 evidence, the H33-BIND identities, public keys (supplied separately — a package that certified itself would be worthless), and the canonical schema. It links against none of Agent-008.

What this does and does not establish. It defeats the code-coupling form of the objection “you verified Agent-008 with Agent-008” — the verifier shares no code with the system it checks and re-derives the verdict independently. It does not establish party-independence: same authors, same schema, same threat model, same assumptions. Genuine third-party verification — a different organization, and a second-language reimplementation — is the stronger bar and is not yet met. A second-language verifier could be written against the published schema and would be expected to reach the identical verdict; that verifier does not yet exist — this is stated intent, not a result [Production].

The verifier answers one question — does the cryptographic evidence support the stated conclusion? — three ways: it recomputes the evidence self-hash, re-verifies the Root authorization signature against the independent anchor, and independently re-derives the outcome and checks it against the producer’s separately- carried claim. Checks run in a fixed order; the first failure wins; the same package always yields the same byte-for-byte report or a stable refusal code — deterministic verify-or-refuse.

On the signature envelope.¹ Every hash is RFC 8785 (JCS) canonical JSON + SHA3-384; the authority envelope is a 3-of-3 of ML-DSA-87, SLH-DSA-256s, and FALCON-512.

We attacked the verifier too: a suite mutates a genuine package every way an adversary — or a bug, or version drift — could, and asserts a deterministic refusal each time (tampered/reordered/substituted artifact, forged authorization, replay from a different run/campaign/runtime, wrong identity/root/decision, malformed BIND, future/stale timestamp, conclusion- and five-zero-laundering, truncated/partial package, schema/engineering version drift).

9. Falsifiability — what would convince us we are wrong

A verification methodology must state the conditions under which its claims should be rejected. Any one of these, observed even once, withdraws a core claim (it is not defended): a replay mismatch accepted; unauthorized execution with “valid” governance; evidence accepted across composition roots; two canonical runtimes simultaneously accepted; execution without Root authorization; an H33-74 package replaying to a different outcome. Additionally — per §3 — a demonstrated TCB compromise (Root-key exfiltration, verifier-host compromise, or a broken PQ family) withdraws the corresponding cryptographic claim. These are the exact conditions the evidence-laundering and impossible-state suites provoke; in the constructed suite each is refused. Reviewers are encouraged to attempt them directly against a replay package.

10. Remediation — what broke, what changed, and how the change is pinned

People learn more from the fixes than the failures. Adversarial testing is only an engineering discipline if findings feed back into the architecture — and if the fix is then permanently verified so it cannot silently regress. Every finding below followed the same loop, and this is the record of the system getting better under adversarial pressure:

   Attack  →  Finding  →  Architecture change  →  Regression (pins it)  →  Replay (independently verifies the fix)

The loop is what most red-team reports omit: they stop at Finding. The last two steps — a regression that makes reintroduction a test failure, and an out-of-process replay that reproduces the fixed behavior from bytes alone — are the difference between “we noticed a problem” and “the problem cannot come back unseen.”

Honesty on remediation counts. These are reactive remediations from development — real assumptions that broke and were fixed. In the published constructed suite as it now stands, no executed obligation breaches, so there are zero residual findings at this tier. Every one of the 54 obligations is also answered by a proactive control (the obligation defines the attack; the control defines the fail-closed refusal; a regression pins it; replay reproduces it). The richest reactive-remediation data — an attack that reaches genuinely unexpected behavior against a live commissioned system — is the [Production] story, and it is Paper #3’s to report, not this one’s to claim.

11. The H33 Verification Methodology (HVM)

Everything above — untrusted generation, cryptographic separation of the four authorities, governed execution, tamper-evident evidence, independent replay, and pinned remediation — is not specific to Agent-008. If the preceding sections read as “of course this is how AI security validation should work,” the discipline has done its job. It has a name: HVM, the H33 Verification Methodology — a repeatable, product-agnostic discipline the rest of the H33 portfolio inherits. We put it last on purpose: the method should be invisible until the evidence has already convinced you. Agent-008 is the first system built to satisfy it.

Pipeline (every product, same order): Architecture → Threat model → AI hypothesis generation (creativity only) → Governed execution (one edge) → Cryptographic evidence → Replay → Falsifiability → Remediation → Production report. Constitutional attacks (mandatory): authority, identity, replay, evidence-laundering, coverage integrity, evaluator integrity, AI, impossible-state, drift, provenance. Attack packs: Constitutional · Product · Deployment · AI · Compound · Regression — this report runs Constitutional, the Agent-008 governance Product pack, and Regression; the AI, Deployment, and Compound packs are [Production]. Evidence tiers: Constructed · Laboratory · Integrated · Commissioned · Production · Field — this report is Constructed / Laboratory / Integrated. Conformance: HVM-A…HVM-E; Agent-008 today is HVM-C against constructed evidence.

Appendix A — the 93 attack classes (published for audit)

Every enumerated class, with its boundary, classification, run status, and replay pointer. dossier = a constructed replay package exists and independently verifies; — = not yet run. This is the central number of the paper, published so a reader can check it.

Totals: 54 ExecutableNative (run) · 26 GovernedTargetRequired (model-in-the-loop, not run) · 13 PendingRuntime (runtime-dependent, not run) · 0 EvidencedMissing = 93.

Appendix B — negative results (attack ideas that did not survive)

Real swarm output the system rejected — the rejection is the result: impossible attack (structurally unrepresentable); duplicate hypothesis (collapsed before scoring); governance refusal (never ran); unreachable state (discarded); replay rejected; malformed/laundered evidence (ingest failure); already covered (deduplicated). None became a reported result. The AI produced all of them; the system filtered them.

Appendix C — verification report template & production governing rule

Every HVM report follows the same structure (product identity · threat model · Constitutional Pack · Product Pack · packs not executed · evidence tier · HVM conformance · replay artifacts · falsifiability · remaining gaps). [Production] Every figure, chart, benchmark, and conclusion in the Production Validation report is generated from the run artifacts — never manually authored; a reader can point to the exact replay package a figure derives from.

Appendix D — class distinctness (the 13 new classes are not variants)

Expanding the denominator (80 → 93) is only legitimate if every added class is genuinely distinct — not a re-label of an existing one. Each of the 13 obligations added in this expansion is separated from every prior class by a property no prior class has: a different authority principal (privileged human vs. agent), a structural precondition impossible in a single agent or single request (multiple coordinated agents), or persistence across an execution boundary (stored state vs. a live request). We state that separation per class so “denominator inflation” can be checked, not merely denied.

The three separating axes in one line: operator abuse needs a human authority agents do not have; swarm dynamics needs a plurality of agents a single execution cannot contain; memory & context needs persistence a live request does not have. None of the 13 collapses into a prior class without discarding that property.

Appendix E — architecture evolution (why each control exists)

The architecture is not a design that happened to survive testing; it is a design shaped by testing. Each control below exists because an attack — or the reasoning behind one — found an assumption that had to be closed. Every one followed the same arc, and the last step is what makes the fix permanent:

   Version N
      │   attack finds a weakness / an assumption
      ▼
   Finding
      │
      ▼
   Architecture modified          (the control now in the system)
      │
      ▼
   Replay confirms the fixed behavior   (out of process)
      │
      ▼
   Regression added               the weakness becomes a test failure
      │
      ▼
   Version N+1  —  cannot silently regress

Read top-to-bottom, this is the system getting better under adversarial pressure — and read as a whole, it is the answer to “why is the architecture shaped this way?” Every control is a scar from a specific attack, and every scar is pinned so it cannot reopen unseen.

Verification philosophy

We do not ask reviewers to trust our implementation. We ask them to examine the evidence, reproduce the replay, and determine whether the evidence supports the claims. If it does not, the claim should be rejected.

Claims are not accepted because they are written in this paper. Claims are accepted only if the replay package independently reproduces them.

The contribution, in one sentence. This paper is not a claim that autonomous AI systems can be proven secure. It is a demonstration that adversarial evaluation itself can be cryptographically governed, independently replayed, and reproducibly verified.