How We Tried to Break the Governance Layer of an Autonomous AI System

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 80 enumerated attack classes, 43 were run — these are the governance and cryptographic boundaries. The 24 model-in-the-loop classes (prompt injection, adversarial ML, poisoning, privacy extraction, model-behavior) 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 80 are published in Appendix A. We do not hide unfinished vectors.

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 80 adversarial attack classes across eight boundaries and run the 43 that do not require an attached model: authority, identity, execution/admission, evidence integrity, replay/provenance, multi-root conflict, data/secret leakage, and supply chain. Testing included attempts to bypass authority, manipulate evidence, create impossible states, exploit identity confusion, introduce replay attacks, 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. 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 24 model-in-the-loop classes, and 13 runtime-dependent), and — as much as the results — how we attempted to prove ourselves wrong.

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 — 43 governance/cryptographic attack classes (of 80 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.

1. Executive summary

We assumed our own governance layer was breakable and built an adversarial program — H33-SWARM — to break it. We attacked six boundaries we can exercise without a model in the loop (authority, identity, execution/admission, evidence integrity, replay/provenance, supply chain), plus multi-root conflict and data/secret leakage. The enumeration is a fixed master denominator of 80 classes; 43 ran (Appendix A), 24 are model-in-the-loop and unrun, 13 are runtime-dependent and unrun.

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 43 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

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). 80 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 80 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) 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]

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 43 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 43/43. 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”

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, and what changed

We attacked the system, found assumptions, and improved it. Each is a real finding.

• BIND coverage discovery. An internal audit (an AI-assisted reconciliation sweep — not a third party) found BIND coverage was zero: every attestation ran on ephemeral keys, the deployed artifact shipped without the Agent-008 composition, and CI did not gate on BIND. It became the explicit production gate.
• Execution/evidence linkage. executed/spawn-hash were hardcoded; the observation now carries the real execution linkage and H33-74 binds the terminal SpawnEvidence.
• Mandatory ingest enforcement. A raw record path existed alongside the governed flow; Swarm::ingest now accepts only a CompletedGovernedAttack.
• reverify_evidence. Conflict evidence is now re-verified against the signed registry (eight adversarial tests).
• Strict-domination testing. A plan to consume API-G’s executor/single-use was tested by a strict domination harness; the disposition (KEEP the fd executor, ADAPT single-use) prevented a lossy retirement.
• Custody seam. BIND composition signing was routed through a governed custody seam, with a crown-jewel negative: a byte-consistent, correctly-signed composition still fails deployment if custody is removed.

11. The H33 Verification Methodology (HVM)

The campaign exposed a broader requirement: security claims about autonomous AI systems require a repeatable verification discipline. HVM is that discipline — the doctrine that makes this report checkable, and a product-agnostic framework the rest of the H33 portfolio inherits. 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 80 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: 43 ExecutableNative (run) · 24 GovernedTargetRequired (model-in-the-loop, not run) · 13 PendingRuntime (runtime-dependent, not run) · 0 EvidencedMissing = 80.

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.

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.