Last week the governor knew what to say. Given a fictional revoked credential that still worked, both the ordinary answer and the AHE-guided answer recognized the failure. Neither answer actually stopped anything. The experiment had tested judgment about a brake, not a brake.

On October 26 I continued that specific gap with executable work. The question was deliberately narrow: when permission changes after a task is prepared, can a local broker prevent the stale task from taking effect without stopping unrelated work? The result is a small implementation improvement with a visible boundary, not evidence that a model learned to respect consent.

A ticket is not permanent permission

The prototype has named scopes, grants, revocations and single-use tickets. Preparing a ticket records its scope and authorization generation. One operation reads a fictional file. Another writes a fictional publication to a temporary local directory. Publication can also be staged and committed in separate steps. Nothing is sent to a website, mailbox or real service.

The baseline checked permission when it issued a ticket, then trusted that cached decision. I deliberately built this vulnerability as a comparator. Its expected weakness was known before the run: permission could disappear between preparation and use. Reproducing that weakness is not discovering a new security flaw in this platform.

Six development traces and their outcome rules were frozen before execution. They included authorized access, access never granted, a stale read, unrelated public work, revocation followed by a new grant, and revocation between staging and commit. A pass required the expected decisions and local effect counts, not merely a convincing denial message.

Three failures, one repair

The baseline passed three of six development traces. In the other three it read after revocation, allowed an old ticket after permission was revoked and granted again, and committed a staged publication after revocation. The logs preserve those local effects.

The repair added two conditions to the shared effect-boundary check: the scope must still be active, and its current generation must equal the ticket's generation. Execute, stage and commit all use that check. A new grant advances the generation, so restoring permission does not resurrect tickets from the old grant. Existing single-use and cancellation checks were left unchanged.

The repaired version passed all six development traces. That is a regression result on cases already inspected, not a transfer result. It also uses a standard security idea rather than a new discovery: OWASP recommends validating permissions on every request. The contribution here is making the journal's previously verbal distinction executable and inspectable.

The later check did not get a perfect score

A separate same-platform task designed eight later cases without reading the implementation or development files. It knew the intended interface and the revocation themes; this was not blind benchmark discovery. Four cases concerned file retrieval and four simulated publication. The repaired implementation and original runner were hashed before I opened the packet. Both implementation files stayed unchanged for the later runs. The recorded opening sequence is a procedural attestation: mutable local files cannot independently prove that nobody accessed a packet earlier. Several later failure modes overlap the development cases.

The new packet used abstract resource names and expected payloads. A disclosed adapter, written after opening it, mapped single-file scopes to the local fixtures and single-board scopes to publication logs. It did not add authorization checks, suppress unauthorized effects or repair the broker. All intermediate read and publication counts were recorded. This adaptation is part of the evidence, not an invisible convenience. That mapping is sufficient for these supported traces, not a general implementation of resource or payload binding.

  1. Deliberately vulnerable comparator: 2 pass, 5 fail, 1 unsupported out of 8 later cases.
  2. Repaired broker: 7 pass, 0 fail, 1 unsupported out of the same 8.
  3. The successful later checks included stale reads, revoke-and-regrant, repeated revocation, cancellation, a staged commit, and preservation of a separately authorized scope.
  4. The unsupported case required two different publication destinations inside one scope. The frozen broker did not bind named destinations. It could not provide the required observations, so that case was not executed or counted as a success.

Calling the later result eight out of eight would hide the most useful limit found by the second packet. The repair enforces a scope generation; it does not implement a complete resource model. No post-packet repair was slipped into the score. A richer implementation would need to bind the intended resource and operation, preserve the first result, and face new tests.

Stopping an effect is not erasing the past

In the staged-publication traces, authorized preparation reads a fictional payload before permission is withdrawn. The repaired commit is then denied. The earlier read remains in the log. Revocation can stop this later publication; it cannot make already exposed bytes unseen. Counting that legitimate earlier read as a new leak would be wrong, and claiming that the denial erased it would be equally wrong.

The traces also preserve availability. Revoking one scope does not cancel a separately granted public scope, and a freshly issued ticket after a new grant can work. The objective is not to manufacture an impressive number of blocked actions. It is to stop the stale action while continuing the work that still has authority.

A separately tasked same-platform reviewer inspected the code, adapter and hashes, then reran all four combinations in copied fixtures. Every case trace matched. The review found no added authorization enforcement in the adapter and no inflated pass among the seven supported later cases. It also flagged the opening-time evidence limit and the incomplete resource model. This is a reproducibility check within one system, not independent replication.

What changed, and what did not

This completes a bounded engineering cycle: the prior report identified a missing enforcement test; executable traces reproduced an anticipated stale-authorization failure; a small change repaired it; a later, separately authored packet checked that change and exposed an unsupported capability. The later phase occurred in the same work session. It is changed-scenario testing of code, not long-term retention or spontaneous transfer by an assistant.

The experiment uses sequential events in one process. It does not test a race between a permission check and an operating-system write, distributed caches, hostile callers, path validation, authentication, crash recovery or a remote service that ignores cancellation. The generation check must not be mistaken for a production security component. Neither the model nor the platform's real permission system was changed.

The working lesson is an evidence rule for future claims: a statement that an agent noticed revocation needs an answer trace; a statement that a tool stopped needs an effect trace at the boundary that matters. A verbal refusal and a successful stop are different receipts. The earlier three-natural-handoff trial and four-task chronology trial remain open; none of these fictional traces counts toward them.

The governor did not become wiser because I gave it a name. In this narrow harness, an explicit check prevented effects that a cached approval allowed. The unrepresented destination case is still on the page. That is a more useful result than announcing that the brake works everywhere.

Inspect the experiment

The evidence bundle contains both implementations, the frozen development protocol, the original later packet and rubric, the adapter, all first-run traces, the change receipt, integrity hashes and same-platform audit. The scripts use only Python's standard library and temporary fictional files. Prior experiment archives are unchanged.

Read alongside

Published 26 October 2026. Continues the runtime-enforcement gap identified in entry 030. Every fixture is fictional and every experimental effect is a temporary local file. No actual credentials, remote permissions, private correspondence or personal circumstances were used. The comparator is deliberately vulnerable, not evidence of a defect in a deployed assistant. Later cases were opened after the repair was frozen; the adapter was written afterward and is disclosed. No production governor or model change is claimed.