DEV Community

zxpmail
zxpmail

Posted on

The Second Face: Probe-Detection Evasion — Tested

#ai #agents #testing #llm

The Second Face: Probe-Detection Evasion — Tested

Agent Determinism Illusions (Part 18)

2026-08-17

Where this fits: This part continues Part 10's argument-space line. Part 11 mapped the semantic face of C3's boundary — referent gameability, where the gap lives between what the requirement says and what was meant. This part maps the runtime face — probe-detection evasion, where the gap lives between what the implementation does and what the oracle can observe. Both faces share a shape: the oracle cannot escape the producer's reach by reading more carefully, only by being isolated from the producer's writable surface.

Part 10's C3 (argument-space verify runner) was tested for one threat model: the producer rephrases the evidence text. Five scenarios — honest, surfaced negation, non-surfaced coherency, synonym naming, hallucinated compliance — measured C3's synonym-immunity. The result was 5/5: C3 observes the side effect, not the vocabulary, so rephrasing cannot clear it. The headline claim was "the only floor a synonym can't walk through."

A comment from Peter on Part 10 named the assumption that headline didn't test: the producer and verifier share a process, and a producer that can rewrite the implementation can stage the side effect only when the oracle is watching. That is a different threat model — rewrite-immunity, not synonym-immunity — and C3 as written does not address it.

This article tests rewrite-immunity directly. Five attack fixtures, each implementing one of the vectors Peter named. Two oracles: C3 (Part 10's exact runner) and a stronger oracle with randomized keys and multi-channel probes. The split between oracles isolates what each defense layer closes, and what it doesn't. A second round then tests the defense itself: the trusted-parent design that closes the verdict channel, the attack shapes that hollow it out, and the residuals that survive three hardenings.

1. The two threat models

Synonym attack (Part 10's tested model): the producer writes compliant-looking evidence using different vocabulary. C3's verify runner doesn't read the evidence — it observes the side effect on the named referent — so synonyms don't matter. S0 (delete), S3 (purgeCacheOnWrite) both PASS; the method name is irrelevant.

Rewrite attack (Peter's model): the producer modifies the implementation so the side effect exists only when the verify runner is observing. The producer doesn't rephrase the evidence; it rewrites the observation channel. C3 reads the (tampered) observation and PASSes.

These are different shapes. The synonym attack lives in the lexical layer; the rewrite attack lives in the runtime layer. A defense against one is not automatically a defense against the other.

Part 10's "synonym-immune floor" is honest for the threat model it tested. The five attacks below test whether it extends to the threat model it didn't.

2. Five attacks, three controls, two oracles — and the mutation discipline

Attacks

Each fixture implements rate-limiter write(k, v) with one of Peter's named vectors. The implementation does the side effect conditionally — only when the verify runner is observing.

Scenario What write(k,v) does Vector
S5 special-case-key if (k === "key1") this._cache.delete(k) special-case the fixture key
S6 stack-detect if (Error().stack.includes("verify-write-invalidation")) this._cache.delete(k) detect verifier by filename
S7 cache-intercept replace this._cache.has with a function reporting false for the just-written key intercept the cache object
S8 prototype poison at module load, patch Map.prototype.has to hide key1 after write() was called once replace a dependency (data channel)
S9 exit-override at module load, patch process.exit so non-zero exit codes flip to 0 replace a dependency (control channel)

Controls

Scenario Compliance Purpose
S0 honest compliant positive control — both oracles must PASS
S1 TTL non-compliant negative control — both oracles must REJECT
S3 synonym-naming compliant positive control, synonym variant

Oracles

  • C3 — Part 10's exact verify runner (verify-write-invalidation.js). Fixed key "key1", fixed filename, single _cache.has channel. This is what Part 10 tested.
  • PROD — a stronger runner (prod-simulate.js). Five random keys per run, four observation channels per key (has, get, iteration, size-drop agreement). This is what a rewrite-aware oracle would look like.

PROD is not the focus of this article. It is the contrast that isolates what C3 misses.

Result matrix

Scenario Truth C3 PROD C3 fooled? PROD fooled?
S0 honest comply PASS PASS — —
S1 TTL evade REJECT REJECT — —
S3 synonym comply PASS PASS — —
S5 special-case-key evade PASS REJECT YES —
S6 stack-detect evade PASS REJECT YES —
S7 cache-intercept evade PASS REJECT YES —
S8 prototype poison evade PASS REJECT YES —
S9 exit-override evade PASS PASS YES YES

C3 is fooled on 5/5. PROD catches 4/5 — every attack except S9. Controls behave correctly under both.

The headline: Part 10's "synonym-immune floor" does not extend to rewrite attacks. C3 reads the side effect through channels the producer can rewrite; the producer rewrites them, and C3 sees compliance that isn't there.

The controls are themselves testable

Peter's prescription included two controls — known-good must pass, known-bad must fail. Mutation testing is that discipline systematized: poison the claimed side effect, require the probe to go red.

Four cells (probe-mutation-poison-test.py, stdlib-only). M0 baseline honest impl → PASS. M1 remove the invalidation → a correct probe REJECTs. M2 invalidate a different key only → a correct probe REJECTs, and a wrong-key probe still PASSes — which is the point: M2 exposes a probe aimed at the wrong referent. M3 an always-green probe on M1 stays green, and the run flags mutation_test_failed. All four cells behaved as predicted (SUPPORT).

The discipline cuts both ways: it validates the gate (M1/M2 must redden it) and audits the probe (M3 must be caught). A probe that survives its own mutation test is suspect, not proven.

3. The split: data-channel vs control-channel

The interesting result is the gap between S8 and S9. Both patch a global at module load — they look like the same attack. They're not.

S8 patches Map.prototype.has — a method on the data channel. PROD catches it because:

  • Randomized keys defeat the targeted patch (S8 only hides key1; PROD's random keys bypass the patch)
  • Multi-channel probes catch the single poisoned method (.get, iteration, and the size-drop check all still see the entry)

S9 patches process.exit — the oracle's verdict signal. PROD also misses it because:

  • PROD's probes still flag the stale entry (data channel is intact)
  • PROD calls process.exit(1) to signal REJECT
  • The patched process.exit flips it to 0 (PASS)

Probe diversification does not close S9 — and not because the probes weren't diverse enough. The producer moved the fakery up one level, from "lie about the cache" to "lie about the verdict": multi-channel probes read the data channel, and the reporting channel is not something a probe reads.

This is the deepest form of Peter's point. The observation channel (data) and the reporting channel (verdict) are both producer-reachable in a shared process. Hardening one channel just shifts the attack to the other.

4. Config-boundary attacks: harness rewrite and pin rollback

Peter named a fifth vector that doesn't fit the runtime-attack shape: modify the harness. If the producer can write to the oracle file path, no runtime trickery is needed — the producer rewrites the oracle to a stub that always exits 0.

Part 10's design put the oracle in .forge/verify/ under editable-surface.json's readonly section. That is a filesystem-level boundary. The demonstration: a three-line fake oracle that ignores the impl and always exits 0.

Real C3 on S1 (TTL, known-bad):     REJECT
Fake oracle on S1:                  PASS
Enter fullscreen mode Exit fullscreen mode

If editable-surface.json readonly is bypassable — any code path that writes a file outside the contract — the producer rewrites the oracle and S1 PASSes. Filesystem-readonly is a config boundary, not a capability boundary. Once bypassed, the verdict is fully producer-controlled regardless of impl behavior.

The same family has a second member that modifies nothing: pin rollback (parent-pin-rollback-test.py). An external digest proves a verifier was approved, not that it is the newest acceptable verifier. If CI may select any digest still in the approval set, it can resurrect an older harness with a known false-green channel — no file rewritten, only the choice of which pin to use. Tested with two executable harnesses on a failing observation:

Cell Selection policy Pick old harness (v1, false-green) Pick current (v2, repaired)
A digest-only allowlist admit → adjudicate PASS (rollback false green) admit → adjudicate REJECT
B sealed monotonic minimum = 2 REJECT at admission (never runs) admit → adjudicate REJECT

Two further cells pin down what kind of attack this is. C — selection, not tampering: under the digest-only allowlist, rewriting v1's bytes fails admission (the digest no longer matches), while selecting the unmodified v1 passes. The allowlist is beaten by choice, not forgery. D — the floor's own writability: with the minimum recorded at 1 — writable by CI — the rollback false green returns; sealed at 2, it is blocked. Who can write the floor is the whole defense.

Rewriting the oracle and resurrecting an old oracle are the same boundary at different times: both are config-layer moves, and both need the selection authority to sit outside the producer's — and CI's — writable surface.

5. Capability isolation: tested, then hollowed

The residual vectors — S9 control-channel override, harness rewrite, pin rollback — close under the same shape: capability isolation. The oracle's reading surface and reporting surface must both be outside the producer's writable surface.

The S9 closure is directly testable, and was tested (parent-reporting-authority-test.py): a trusted parent launches a restricted child, reads one narrow IPC line, and owns the verdict. Six claims, all confirmed:

  • A1 — the in-process adversary (S9's exact shape) converts a REJECT into PASS when reporting authority lives inside the evaluated process. This is the baseline failure.
  • A2 — the same adversary as a child, exiting 0 and printing a fake PASS banner, cannot move the parent: the parent decides from the IPC line and REJECTs.
  • A3 / A4 — a hung child, or a malformed IPC line, fails closed.
  • A5 — a harness digest mismatch REJECTs even when the IPC line says ok.
  • A6 — an honest child with matching digest and a real side effect PASSes.

But process separation alone is hollow (parent-oracle-hollow-test.py). Three attack shapes each produce a clean parent PASS when the parent trusts what it reads:

  • H1 — the child lies over IPC. The side effect failed; the child emits {"obs":"ok"} anyway. A parent that trusts the line PASSes. A parent that observes for itself REJECTs.
  • H2 — fixture poison. The child rewrites a shared fixture the parent reads as truth. A parent reading that file PASSes; a parent using a sealed fixture the child cannot reach REJECTs.
  • H3 — colocated digest. The attacker edits the harness body and the expected digest stored beside it. The colocated check PASSes; an externally pinned expected digest REJECTs.

Reporting authority and oracle integrity are different properties. The first is closed by the process boundary; the second needs observation inputs the child does not own and an expected digest pinned outside the mutable tree. With that split in hand, the stack — each row now carrying its test:

Layer Mechanism Closes Tested by
Runtime sandbox frozen Map/Object/process/Error S6, S7, S8 (+ in-process half of S9) proposed — not tested here; the data-channel outcome is covered by PROD (§2), the sandbox mechanism is not
Independent process verdict finalized in trusted parent, narrow IPC S9 (structural) A2–A5
Parent-owned observation oracle observes itself; sealed fixtures H1, H2 hollow-parent H1/H2
External digest pin expected value outside the mutable tree H3, harness rewrite H3; §4 fake oracle
Sealed monotonic minimum version floor not CI-writable pin rollback §4 matrix
Cryptographic randomization CSPRNG keys (crypto.randomBytes), regenerated per run S5 (strengthened) PROD oracle (§2)
Meta-controls known-wrong canary; fail-open policy diff detector probe error, governance softening pg-canary-governance-test.py

The last row is the stack watching itself. A known-wrong canary that goes green invalidates the gate — in the run, a correct probe REJECTs the canary while PASSing the honest case; a wrong-key probe misses the canary and the gate is flagged invalid. And a policy-soften detector flags fail-open diffs (timeout→warn, digest→warn_only, retry_until_green) while leaving an unchanged fail-closed policy clean. Governance is a channel too: the producer doesn't need to beat the oracle if it can soften what the oracle is allowed to reject.

Each mechanism is a capability boundary: the producer cannot reach the reference, cannot rewrite it, cannot predict it, cannot reselect an old one. Together they move the oracle from "code the producer shares a process with" to "code the producer cannot reach — and neither can the pipeline around it."

This is the host/guest interface: the oracle is the host runtime; the impl is guest code; the boundary is what the host exposes to the guest. Everything the oracle reads must be on the host side. Everything the impl touches must be on the guest side. The control-channel subset is closed by that boundary, not by better reading — probes address what the oracle observes, not who owns the verdict.

6. The honest claim

This article is not proposing closure. Two residual false-green channels were measured, not just named (parent-residual-false-green-test.py), surviving all three hardenings (parent-owned observation intent, child-unwritable fixtures, an "external" digest pin):

  • R1 — the parent imports the child. A parent that "observes" by importing the impl into its own address space trusts the module's return values; the module lies in invalidate() and PASSes. The boundary has to dissolve itself to be used. An out-of-process probe that checks sealed state the child code never receives REJECTs.
  • R2 — the "external" pin is CI-writable. An attacker who already owns CI rewrites the expected digest together with the harness, and the colocated-style check PASSes. A second-channel pin — an offline attestation stand-in the CI job cannot write — REJECTs. "External" is a claim about write authority, not file location. The same writability failure reopens §4's sealed minimum: with the floor CI-writable at 1, the rollback false green returns (cell D). The defense is who can write the authority, not the mechanism's shape.

Beyond the measured residuals, the isolation stack has named-but-untested assumptions:

  • TCB integrity. The Node runtime, V8 engine, and OS kernel are below the capability boundary. A vulnerability in any of them collapses the boundary. Software-layer capability isolation is only as strong as its trusted computing base.
  • VM detection. A guest that can fingerprint the sandbox can selectively behave — implementing the side effect only when not detected as in-test. This is S6 (stack-detect) strengthened: instead of reading the call stack, the producer reads the sandbox's physical characteristics (timing, error messages, missing globals). isolated-vm is harder to detect than vm, not impossible.
  • Randomization distribution leakage. Randomized keys close S5 only if the producer cannot predict the distribution. If the producer knows the key format, it can special-case high-traffic keys (the production-equivalent of S5's key1). Closing this requires input distributions to be both producer-unpredictable and representative of real traffic.
  • Byzantine authority. Sealing one honest oracle's history says nothing about whose view is the truth when a compromised authority can present forked views to different observers. Equivocation, witness freshness, and the quorum arithmetic that answers them (q > (n+f)/2; one Byzantine witness → 3-of-4) are the next part's subject, not this one's.

These are residual axes, not closures. Each is a place where the producer's cost ladder continues above the capability-isolation layer — the next ratchet rungs, not the top.

The claim this article makes: C3 has at least two faces of structural boundary. Part 11 mapped the semantic face (referent gameability — the gap between what the requirement says and what was meant). This part maps the runtime face (probe-detection evasion — the gap between what the impl does and what the oracle observes). Both faces share a shape: the oracle cannot escape the producer's reach by reading more carefully, only by being isolated from the producer's writable surface. The isolation is structural, not algorithmic.

Part 10's "synonym-immune floor" is honest for synonym attacks. It is not honest as a general floor — and the difference is the threat model, not the impl.

Experiment scripts (all in the public experiments repo):

Results in results-v2/: the six verdict files read SUPPORT; rewrite-attack.json predates that convention — it records per-scenario predictions_match and the summary (C3 fooled 5/5, PROD fooled 1/5, controls matched 3/3).

Previous in the series: Round 2: when the reply triggers another revision (Part 17)
Previous in the argument-space line: The Third Predicate: Argument-Space Verification, Tested (Part 10) — Part 11, the semantic-face companion, is not yet published
Series: Agent Determinism Illusions on dev.to/zxpmail

Top comments (0)