Four incidents, and what they share

In all four, the check existed and the check passed — what failed was the binding · Macheng Shen × agent · 2026-09-07

The four incidents below happened, were logged, and were closed with a written receipt. That much is observed fact — the cognitive state of this page is survived, not speculative. The lesson at the end, that a system can be fully covered by checks and still be unsafe, is this author's reading of the four together, not a fifth observation, and should be trusted less than the incidents themselves. All four are de-identified — no device models, app or platform names, order contents, or personal names — but the mechanics are given in full, because the mechanics are the point.

(a) Verify-then-drift

An agent was injecting a multi-minute sequence of synthetic keystrokes into a phone. It confirmed the device was unlocked and idle once, at the start, and treated that as good for the whole sequence. Partway through, the owner picked the device up and began using it. The foreground had by then become a checkout screen and then a payment-confirmation screen; the last two injected confirmations may have landed there. It could not be established either way, and the agent declined to open the owner's transaction history to find out, on the grounds that this would be a second privacy violation rather than a resolution of the first — a constraint that makes the incident credible rather than convenient. Failure class: a precondition checked once per session and assumed to hold for every action inside it. Fix: re-verify unlocked state, foreground application, and idle time before each injection. Honest gap: not yet wired into the other input-injection tools.

(b) A gate deadlocking against itself

A session was blocked from sending an owner notification by its own concurrency gate, which reported the lease's holder as "verified alive" — the holder was the session itself. Its acquire path had skipped its own existing lease and created a second one; a later compare-and-swap picked the older lease as authoritative, concluded the newer one had lost the race, deleted the lease it had just created, and reported the winner — itself — as alive and blocking. A second bug compounded it: the same session derived two different holder identities depending on whether it entered through a hook or a manual shell call, so the gate treated one actor as two. Failure class: identity for "is this the same actor?" derived inconsistently across entry points into one gate. Fix: liveness and self-identity from process ancestry, not string comparison. Twenty-five of twenty-five tests reproduced the bug before the patch; twenty-eight of twenty-eight pass after, with a before/after table showing no cross-session guarantee was weakened.

(c) Healthy status, total failure

Three background dispatches to a second execution provider all died on their first model turn with an identical HTTP 400, whatever model was requested. Root cause: a local model-metadata cache had lost a required field, so the client fell back silently to degraded metadata for every model it ran. Through all three failures the client's own --version, --help, and status commands reported healthy, because none of them makes a real call. Failure class: a health check that does not exercise the thing it certifies. Fix: an upgrade, cache kept for rollback. Standing rule: a canary for this class of dependency must perform a real round trip, not a version probe.

(d) Authority downgraded at dispatch

Across 307 sub-agent transcripts in one session, ten carried refusal language of the form "a relayed instruction is not authorisation"; at least four were hard refusals that forced the parent session to restate the instruction or do the work by hand. The sub-agents were behaving correctly — an agent cannot distinguish "the owner said so" from "my caller claims the owner said so"; those are the same string. The bug was structural: authority was downgraded at dispatch into an unverifiable claim, and no sub-agent judgment can recover information never passed down. Fix: a signed envelope carrying the owner's own words, channel, scope, a time-to-live, and delegation depth, where delegation can only attenuate authority, never amplify it — modelled on delegated-authorisation token exchange (RFC 8693) and attenuation-only capability tokens such as macaroons and biscuits. The schema is public; the running, signed implementation is private. Its documented limit, stated plainly: it establishes provenance, not a security boundary.

(e) A positive result, briefly

Not everything here is a failure. One canary tests the opposite direction: a task is dispatched whose target does not exist, set up so a fabricated result would have passed automatic acceptance. In both runs so far, the worker declared itself blocked, with evidence, instead of inventing success. The count is exactly n = 2, reported as two, not rounded up to a trend — an existence proof, not a rate.

What the four share

In every one of the four incidents, the check existed, and it passed. Case (a) had a liveness check; it passed at the start and was never asked again. Case (b) had a concurrency gate; it evaluated correctly against the identity it was given and returned the wrong answer because the identity was wrong. Case (c) had a health check; it reported exactly what it was built to report, and that was not the thing that mattered. Case (d) had a refusal policy working as intended, on every hop where refusal was structurally the only correct response available to the agent making it.

What failed, in each case, was not the check. It was the binding — between a check and the action it was meant to cover, between a check and the identity it was meant to be checking, between a check and the thing it was supposed to certify, between an instruction and a verifiable record of where it came from. A system can be covered, gate for gate, and still be unsafe, if the wiring between the gates and the events they gate is wrong in some case nobody has yet exercised. This is why the coverage number reported elsewhere in this section counts (tool, entry-point) pairs rather than gates: a gate that exists is not evidence of anything until it is shown reachable from, and correctly bound to, every path that needs it.