The Wall Part 7 Left Standing
Part 7 ended on a wall I couldn't argue my way past. I'd built a detector that catches generic AI writing well, and it does, but when I pointed a model at imitating me specifically, the detector lost, scoring a deliberate mimic as more me-than-me. A better detector wouldn't fix that, because the answer was never in the text. Whether something is authentically mine is a question of provenance, of who actually typed it, and a detector can keep improving forever without ever getting to that question.
For authorship that's mostly where it stops. The same shape shows up one level up, though, in the guard itself, and that version I could do something about.
Who Holds the Key
If the agent can approve itself past its own guard, switch it off, or quietly rewrite it, the guard is theater, the mimic grading its own mimic, which is the same failure Part 7 ran into wearing a different coat. So the guard can't be something the agent installs, and its trust root has to sit with a human owner, somebody outside the agent entirely.
The mechanism itself is pretty small. I hold a secret the agent never sees, and I pin a fingerprint of the safety files myself. When I switched the core on, the agent that wrote every line of it was structurally unable to do that one step for me, so it guided and I turned the key.
I'm also the only person holding that key, and when I wrote this a separate hardening step hadn't run yet, so tampering with the safety files got detected but wasn't physically prevented at the OS level.
Voice Was Only the First Failure Class
The voice checker was one instance of a pattern, a deterministic test for a specific way work goes wrong, wired to block and upfront about its ceiling, and once I saw it that way I started asking what else in agent work has that shape.
An agent doesn't only risk sounding like a robot. It can be talked into something by a poisoned input it was only supposed to read, or leak data on the way out (sometimes through a channel nobody thinks of as "sending"), or fire an action nobody approved, or leave a record you can't actually trust. Each of those is a failure class, and each one gets a check built the way the voice tell's was, one that fires on the bad case, stays quiet on the good one, and says plainly what it can't catch.
- slop · sounds like AI (Part 7)
- injection · input treated as an order
- egress · data leaving quietly
- evidence · a record you can trust
- drift · a guard that stopped working
- silent-empty · green over nothing
- ungrounded · a claim with no source
- execution · it didn't actually run
- model-swap · a different model than asked
What Each Check Catches and Where It Stops
Click any of the nine and you'll see what sets its check off, what it leaves alone, and the ceiling it can't see past.
The ceiling they all share is that a check only catches what I taught it, so a determined attacker who knows a specific guard exists can study it and route around it. Part 7 hit that same ceiling with the voice detector, and here it applies to the whole layer. When I counted the 653 workflow subagent runs that answered in one long harness session between 2026-09-19 and 2026-10-02, every one got the model it asked for, named or inherited as the default, which is the same comparison the model-swap check makes, and like that check my count can't see past the gateway's own report of which model answered. The 23 that asked for Sonnet and died on an API error never answered, so they're outside that count. I keep raising it over time, and I don't get to call it finished.
One Core, Three Runtimes
I didn't want a layer that only works inside one tool, since at that point it's really a feature of the tool. So the checks live in a single host-neutral core, and each runtime reaches them through a thin adapter that translates the tool's own events into one shared vocabulary. You get the same poisoned-input check, egress guard, and tamper-evident record whether the work happens in an agentic coding CLI, an open-source coding agent, or a managed enterprise execution runtime.
"The same" gets checked by a conformance test. For an equivalent operation, the Claude Code and OpenCode adapters have to produce identical canonical events (the managed runtime, which the harness can only watch, isn't part of that test), and if they diverge I treat it as a bug in that adapter and go fix it there.
Reconciled Against the Real Thing
The fair question about any layer like this is whether it's real or a diagram. So I read each product's actual installed interface and reconciled the adapters against that, instead of against how I'd imagined each tool worked, and it caught a few of my guesses right away.
| Runtime | Reconciled against | What reading the real API corrected |
|---|---|---|
| Claude Code | its native hooks | the reference adapter |
| OpenCode | its public plugin interface | three shapes I'd guessed wrong: an "idle" signal I'd treated as "finished," a separate approval hook I'd been double-counting, and where the tool's arguments actually live |
| managed runtime | its installed types | it's more observable than I assumed, with a native approval step, but it's observe-only, so the harness reconciles a change after the fact rather than pre-gating it |
Checking the adapters against each product's real interface is a real step past a mock, and it still isn't the same as watching them fire inside a live session. When I wrote this, that live in-host capture (a real session watched end to end, with the controls observed actually firing) hadn't run, so the controls were proven in tests and hadn't been seen live inside a running host. And because the managed runtime's event stream is observe-only by nature, enforcement there lives on the platform side. Its own MCP server, which I hooked up to Claude Code on 2026-09-30, might be a way to gate that work up front, and the harness wasn't using it as of 2026-10-01.
It Attacked Its Own Code
The egress control came straight out of a real, public attack class. An agent reads a poisoned record, and data walks out the door inside a URL that a rendered image quietly resolves... no click, no obvious "send." So I built the guard to treat any resolvable URL as a way out, including the ones that don't look like sending at all.
Then I turned the same adversarial process on the harness itself, with two passes each trying to break what the last one built and then a fuzzer going after what both of them missed. Together they found and fixed roughly 28 real defects in the harness's own code, including one in the egress guard I'd written specifically to stop that attack, which had its own version of the exact bug it was meant to catch.
I'd spent the whole build refusing to let anything grade itself, and it would've made no sense to exempt the harness from that, so its code got caught the same way everything else does, before any of it went live. I tried hard to break the gate, and it fired on cue and held.
What You Actually Get to Keep
You can't own the frontier model, you rent it, and it changes under you every few months. What lasts is the layer wrapped around it, the checks that catch how the work goes wrong, the evals that say whether the output is any good, the record of what actually happened, and the custody that decides who's allowed to change any of it.
Part 7 showed that layer can evolve itself while the model underneath stays frozen. What Part 8 adds is that it travels across whichever runtime the work happens in, and it stays yours when the model you're renting changes. I'm not the only one betting on that either... NVIDIA's SoL-Pi built a set of harness improvements on one model and carried them to another with no retraining.
It's a first draft of the argument, proven in tests and not shipped to production when I wrote it, so if you build agents that touch anything you'd mind losing, poke holes in it before you take any of it on faith.
Everything through Part 8 I improved by hand. Part 9 is the first time the harness improves itself, and the hard part there turns out not to be the code that writes the change, it's the check that refuses to be fooled by it. Read Part 9 →