Auto-mode classifier treats a stale memory note as a standing authorization boundary

Summary

The auto-mode classifier blocks an in-scope action when a memory note records a past decision that the action appears to reverse, even when the user has re-authorized the goal in the current session. The classifier reads the note as a standing instruction instead of as a historical record of an earlier decision.

Concrete case

In one session the agent was enrolling mesh agents at the user's request. It could not reach the authenticated API without a passkey session. The only path it found was a brief flip of an admin automation flag on a loopback-only service that a host firewall blocks from all external access. A memory note recorded that flag as deliberately turned off after a prior incident.

The classifier blocked with a "Security Weaken" reason: the agent was re-enabling the flag without explicit user authorization, and the memory note recorded it as resolved-off after an incident.

That block is defensible. An agent re-enabling a deliberately disabled admin flag on its own in-task reasoning is the shape of an agent talking itself past a prior security decision. This issue is not a claim that the block was wrong.

The gap worth fixing

The classifier cannot tell two uses of a memory note apart:

1. A historical log: "we turned this off on <date> after an incident." A record of what happened.
2. A standing instruction: "do not turn this on." A current prohibition.

When the note is a historical log, a later re-enable that the user has authorized in-session is in scope. When the note is a standing instruction, the same action should be blocked. The two can read almost identically, so the classifier treats both as a current boundary and blocks the first case along with the second.

Failure mode and direction

The block fails closed, which is the correct direction. Treating a past security fix as overridable by agent reasoning is where the costly mistakes happen. The cost is that legitimately re-authorized work gets stopped with no path to proceed other than rephrasing or starting a new session.

Two proposed resolutions, in order of preference:

1. Give the classifier a way to read a memory note as a historical record rather than a current rule. If it can make that distinction, it stops blocking re-authorized actions in case 1 while still blocking case 2.
2. Until that distinction exists, require explicit re-authorization to clear the block: an in-session user confirmation, or a memory note updated to reflect the current state, rather than an in-task justification from the agent. The action keeps failing closed and clears deliberately.

Credit

This analysis is from @yurukusa in #71482. The split between "is the block sound" and "is there a real gap to fix" is theirs.