Kill-Witness Verification: Adversarial Falsification of Code in Autonomous AI Swarms

#Abstract

When autonomous coding agents author both implementation code and unit test suites, standard Continuous Integration (CI) suffers from a structural blind spot: vacuous verification. An LLM agent frequently writes unit tests that assert its own internal assumptions or rely on tautological mock states. The resulting test suite passes with 100% code coverage while failing to constrain the software against critical regressions or security vulnerabilities.

In this paper, we present Kill-Witness Verification (KWV), an adversarial verification paradigm operationalized in the Mupot multi-agent substrate. Rather than accepting green test execution as proof of correctness, KWV requires an independent adversarial agent to generate syntactic and behavioral mutations ($M$) against the code under test. A test suite is certified as non-vacuous if and only if every mutation that violates a specification boundary triggers a deterministic test RED (a “kill”). If a mutation survives without failing the test suite, the verification is proven vacuous and the pull request is rejected.

We analyze the mathematical formulation of KWV, define the vacuity detection theorem for multi-agent systems, and demonstrate its empirical efficacy across production pull requests in Mupot (Flights 005–008). We show how KWV caught critical authorization misalignments (PR #1076) and clock-skew time bombs (PR #1077) that passed conventional 14/14 automated CI pipelines.

#1. Introduction: The Fallacy of Green-Light CI in AI Fleets

In human-centric software engineering, the author of a feature typically writes tests to verify their intent, and independent human code reviewers inspect the diff. In autonomous AI swarms, however, code generation and unit testing are delegated to language models that share the same underlying inductive biases.

graph TD
    subgraph Traditional CI: The Tautological Loop
        A[Builder Agent] -->|Writes Feature Code C| B[Code Under Test]
        A -->|Writes Tests T based on C's assumptions| C[Test Suite]
        B & C --> D[Standard Test Runner]
        D -->|Tautology Passes| E[100% Green CI: False Sense of Security]
    end

    subgraph Kill-Witness CI: Adversarial Falsification
        F[Builder Agent] --> G[Candidate Code C & Suite T]
        H[Adversarial Gate Agent: River] -->|Injects Mutation M| I[Mutated Code M_C]
        I & T --> J[Kill-Witness Runner]
        J -->|T fails RED on M_C| K[Kill-Witness Proven: Non-Vacuous Test Certified]
        J -->|T passes GREEN on M_C| L[Vacuity Detected: PR Rejected]
    end

When an LLM authors a pull request, it frequently:

1. Mocks what it cannot satisfy: If a database foreign-key constraint is difficult to satisfy, the agent constructs a mock database that accepts arbitrary IDs.
2. Asserts what it computes: Instead of asserting against independent domain invariants, the test asserts that $f(x)$ returns whatever $f(x)$ currently outputs.
3. Ignores boundary violations: Security checks, clock bounds, and multi-tenant isolation rules are omitted from assertions because the LLM did not conceptualize them during feature drafting.

Traditional CI simply asks: “Did the code execute without throwing an uncaught exception?” Kill-Witness Verification asks: “If the code were maliciously or accidentally corrupted, is the test suite capable of catching the crime?”

#2. Mathematical Formalization of Kill-Witness Verification

Let $\mathcal{S}$ be the state space of a software system, and $\mathcal{F}$ be the space of functions $f: \mathcal{S} \to \mathcal{S}$.

#2.1 Specification and Invariants

A software component is governed by a set of formal invariant predicates: $\mathcal{I} = \{ I_1, I_2, \dots, I_k \}, \quad \text{where } I_j: \mathcal{S} \times \mathcal{S} \to \{0, 1\}$ An implementation $f \in \mathcal{F}$ is semantically correct with respect to $\mathcal{I}$ if: $\forall s \in \mathcal{S}, \quad \bigwedge_{j=1}^k I_j(s, f(s)) = 1$

#2.2 The Vacuity Problem in Test Suites

A test suite $T = \{ t_1, t_2, \dots, t_m \}$ is a set of executable assertions that evaluates $f$ on a finite sample subset $\mathcal{S}_{\text{sample}} \subset \mathcal{S}$: $T(f) = \bigwedge_{i=1}^m t_i(f)$

Definition 1 (Vacuous Test Suite): A test suite $T$ is vacuous with respect to invariant $I_j$ if there exists an implementation $f_{\text{bad}} \in \mathcal{F}$ such that: $(\exists s \in \mathcal{S}, I_j(s, f_{\text{bad}}(s)) = 0) \land (T(f_{\text{bad}}) = 1)$ That is, the implementation breaks the fundamental invariant $I_j$, yet the test suite reports full success ($T = 1$).

#2.3 The Kill-Witness Operator

To detect and eliminate vacuity, Mupot defines the Kill-Witness Operator $\mathcal{K}$. Given candidate implementation $f$ and test suite $T$, an adversarial agent selects a suite of targeted mutation operators $\mathcal{M} = \{ \mu_1, \mu_2, \dots, \mu_p \}$ where each $\mu_r: \mathcal{F} \to \mathcal{F}$ deliberately breaks a known invariant $I_j$.

$\mathcal{K}(f, T, \mathcal{M}) = \bigwedge_{r=1}^p \Big( \neg T(\mu_r(f)) \Big)$

Theorem 1 (Non-Vacuous Certification): A pull request is certified for landing if and only if: $\text{Certification}(f, T) = T(f) \land \mathcal{K}(f, T, \mathcal{M})$

1. The implementation passes all tests under normal conditions ($T(f) = 1$).
2. Every deliberate semantic corruption is successfully killed ($\forall \mu \in \mathcal{M}, T(\mu(f)) = 0$).

#3. The Anatomy of Kill-Witness Mutations in Mupot

Mupot categorizes adversarial mutations into three distinct tiers:

                                  Kill-Witness Mutation Hierarchy
                                                │
         ┌──────────────────────────────────────┼──────────────────────────────────────┐
         ▼                                      ▼                                      ▼
1. Authorization Mutations             2. Temporal / Clock Mutations          3. Schema & Cardinality Mutations
   • Bypass caller capability check       • Inject stale presence heartbeat      • Collapse shared-slug agents
   • Force `can_verdict: true` on 0-cap   • Set future-skewed timestamp          • Inject unattached runner seat
   • Expectation: Test Fails 403          • Expectation: Test Fails Liveness     • Expectation: Test Fails Ambiguity

#3.1 Authorization & Sovereign Bypass Mutations

• The Attack: Mutate permission checks to unconditionally return true or bypass role checks.
• The Kill-Witness Assertion: The test suite must assert that an unauthorized caller receives an explicit 403 Forbidden or that the action button is structurally omitted from the rendered DOM.
• Production Witness: In PR #1076, mutating can_verdict to always return true failed 3 separate kill-witness tests, proving that unauthorized operators cannot be promised execution controls.

#3.2 Temporal & Clock-Skew Mutations

• The Attack: Shift the simulated clock $t_{\text{mock}}$ forward or backward relative to stored heartbeat timestamps.
• The Kill-Witness Assertion: A presence row older than TTL must be classified as stale or offline, and a future-dated timestamp must not spoof eternal liveness.
• Production Witness: In PR #1077, mutating real-world execution time past 12:01 UTC killed the unmocked loadObservatory test, proving that tests must accept an explicit nowMs parameter.

#3.3 Cardinality & Identity Collision Mutations

• The Attack: Inject two distinct agents sharing the same slug name across different squads.
• The Kill-Witness Assertion: The agent selector must render distinct squad badges for both agents and refuse to collapse them into a single entry.
• Production Witness: In PR #1078, forcing a single-choice dropdown on duplicate slugs failed the cardinality guard test RED.

#4. Empirical Case Studies from Live Council Operations

#Table 1: Kill-Witness Mutations Executed Across Flights 005–008

#5. Architectural Comparison: Standard CI vs. Kill-Witness CI

// Traditional Unit Test (Tautological & Fragile)
test("user can approve task", async () => {
  const result = renderTaskPage({ status: "review" });
  expect(result.includes("Approve")).toBe(true); // Passes, but doesn't check write authority!
});

// Kill-Witness Test (Adversarial & Falsifiable)
test("verdict button is structurally omitted when caller lacks authority", async () => {
  const db = await createRealD1Fixture();
  const unprivilegedCaller = seedMember(db, { capabilities: [] }); // Schema-valid caller
  const task = seedTask(db, { gate_owner: "gate:athena" });

  // 1. Happy path assertion under authorized admin
  const adminRender = await renderApprovalsPage(db, adminCaller);
  expect(adminRender.canVerdict(task.id)).toBe(true);

  // 2. Kill-Witness assertion: Mutation to unprivileged caller MUST suppress button
  const unprivRender = await renderApprovalsPage(db, unprivilegedCaller);
  expect(unprivRender.canVerdict(task.id)).toBe(false);
  expect(unprivRender.html).not.toContain(`id="verdict-approve-${task.id}"`);

  // 3. Write-Path Mirror check: Direct API call MUST reject with 403
  const writeResponse = await postVerdict(db, unprivilegedCaller, task.id, "approved");
  expect(writeResponse.status).toBe(403);
});

#6. Implementation Guidelines for Agentic Substrates

To implement Kill-Witness Verification in any autonomous development environment, engineering teams must enforce four foundational substrate rules:

1. Role Separation: The agent drafting code (kasra-code, codex) must never possess authority to approve or merge pull requests. A dedicated adversarial persona (river, athena) must execute the mutation suite.
2. Real Schema Migration Fixtures: Kill-witness tests must run against real database migrations (node:sqlite applying exact SQL DDL), never hand-rolled mock dictionaries that bypass foreign keys.
3. No Uninjected Clocks: All time-sensitive logic must accept nowMs?: number to enable deterministic time-travel mutation testing.
4. Falsification Logging: The CI pipeline must output a Kill-Witness Receipt recording the exact mutations tested, their observed RED failures, and the Merkle root of the landed commit.

#7. Conclusion

As AI development fleets scale from single-turn code generation to autonomous long-running swarms, relying on standard green-light CI is an invitation to catastrophic architectural decay. Kill-Witness Verification provides the mathematical and operational framework required to enforce true epistemic rigor.

By demanding that every claim of success survive deliberate adversarial falsification, Mupot transforms autonomous software engineering from a high-risk black box into a mathematically verifiable, self-correcting science.

#References

1. Popper, K. R. (1959). The Logic of Scientific Discovery. London: Hutchinson.
2. Jia, Y., & Harman, M. (2011). An Analysis and Survey of Mutation Testing. IEEE Transactions on Software Engineering, 37(5), 649–678.
3. Mumega Synthetic Council. (2026). ADR-007: Domain-Substrate Decoupling and Autonomous Gate Governance. Mumega Architecture Repository.
4. Mumega Synthetic Council. (2026). ADR-008: Mupot Operating Model & Epistemic Invariants. Mumega Architecture Repository.
5. Mumega Synthetic Council. (2026). Paper 200.401: Falsificationist Substrates for Multi-Agent Systems: Beyond Tautological Task Execution. Mumega Paper Series.