A persistent effect survives the revocation of the authority that created it
A principal writes consequential, persistent state while holding compromised or unauthorized live access. Removing that access, patching the path that granted it, or rotating the credentials involved leaves the written state exactly as it was, still available for a later, legitimate execution to read back as trusted input.
Description
This weakness names a gap between two things that are not the same operation, however often they are treated as one: ending a principal's live access to a system, and invalidating what that principal already wrote while holding it. A write to a memory store, a learning corpus, a configuration table or another persistent surface is itself a consequential action, carrying whatever authority the writer held at the moment it happened. When the writer never held legitimate authority for that action at all, an unauthenticated attacker who reached a consequential capability, or when the writer's authority is later found to have been improperly obtained, the write's own authority was defective from the start. Closing the path that let the write happen, whether by patching a vulnerability, revoking a session, or rotating a credential, changes nothing about content already committed to the store; the record persists, indistinguishable in form from anything a legitimate process wrote, until a separate, deliberate action inspects and removes it. Where a later legitimate execution then reads that store as trusted input, the compromised write keeps exerting the authority its original, illegitimate access supplied, on a timeline that outlives the access itself. This differs from persistent state carrying an inherited objective between two ordinarily authorized agents, AEW-012, where no attacker and no revoked or unauthorized access are present anywhere in the chain, and the question is re-authorization at a handoff between legitimate principals rather than the validity of a write made under authority that should never have existed. It differs from unattenuated delegated authority, AEW-006, which concerns a live grant passed forward without narrowing while both principals remain within scope, not a grant that ends while its already written effects do not.
The authority gap
The authority that governs whether a piece of persistent state may keep influencing future execution is treated as identical to the authority that governed the live access which created it. Ending the access is treated as though it also settled the state, when nothing has actually evaluated the state itself.
Failure conditions
- A principal writes to a persistent store while holding compromised, unauthorized or otherwise improperly obtained live access.
- The access that produced the write is later closed, whether by a patch, a session end, or a credential rotation.
- Nothing distinguishes the written record's provenance from content a legitimately authorized process wrote to the same store.
- A later, legitimate execution reads the store as trusted input with no separate check of what authority produced each entry.
Consequences shown by the evidence
- A learning or pattern store keeps steering future, legitimate agent behaviour with content an attacker wrote during a since closed window of unauthorized access.
- An operator who deploys a security fix reasonably, but wrongly, believes the incident is over, because the fix closes the access path without touching anything already written through it.
- Incident response that stops at patching and credential rotation leaves the actual persistent consequence of the compromise in place, undiscovered until an unrelated review finds it.
Detection signals
- A vendor's own remediation guidance lists a manual audit and purge step for a persistent store, separately from and in addition to the code fix and credential rotation.
- A persistent store's entries carry no writer identity, authority context or trust level, so a compromised interval's writes cannot be distinguished from any other entry.
- Post incident review confirms the vulnerable path is closed without separately confirming what, if anything, was written through it while it was open.
Known examples
- CVE-2026-59726, formally assigned in GHSA-c4hm-4h84-2cf3, documents Ruflo's MCP bridge accepting an unauthenticated tools/call request that reached terminal_execute, giving an attacker a shell with write access to AgentDB, Ruflo's own persistent pattern and learning store, and to the provider API keys the bridge held. Version 3.16.3 closes the network exposure and the enforcement gap that let terminal_execute run unauthenticated. Ruflo's own release notes, read directly, separately instruct operators to rotate every provider key and to audit and manually purge AgentDB for injected pattern store entries, stating the fix does not undo that on its own. This is the clearest evidence this weakness has of the gap it names: the live authority failure and the persistent state written under it have two different remedies, and only one of them ships in the code.
- A paper submitted to arXiv on 4 September 2026, CONTINUITY (arXiv 2609.05269), names an adjacent but distinct instance of the same underlying property this weakness's own known example above demonstrates: that authority correctly established when an earlier stage admitted a request is not thereby established as still current at the later moment an effect actually commits. Its reference implementation, read directly by this session at github.com/zast-ai/continuity, tests this exact collapse as named fault classes, REVOKED_GRANT and EXPIRED_RELEASE, in a deterministic conformance suite reporting zero successful harmful effects across every parameterized attack instance in its full reproduction. Kept distinct from this weakness's own known example above: that one concerns a write already committed to a persistent store surviving the later revocation of the access that produced it; CONTINUITY's own fault classes concern a finality stage trusting an admission decision's currency rather than rechecking policy, revocation and expiry state against the moment of commit, so a grant already revoked, or a release already expired, is still accepted at effect time. arxiv.org was blocked at this session's network egress proxy on every attempted route, so the manuscript's own argument is held here at the convergent search evidence level, distinct from the reference implementation's own source, fetched directly.
- draft-kuehlewind-audit-architecture-01, an IETF individual Internet Draft revised 7 September 2026, is design evidence rather than an incident, and names the same property this weakness's own known examples already demonstrate: its Authorization Transition Record class models authorization as an ordered sequence of previous-state/new-state pairs, initial grants, step-up approvals, scope narrowing, revocation and expiry, built so an auditor can reconstruct which state was in force at a given point in a run rather than reading off whatever is currently known. This record's own evidence separately motivated a targeted, additive extension of Moona's canonical Authority Resolution engine, closing the equivalent gap in the reverse temporal direction from CONTINUITY's own REVOKED_GRANT and EXPIRED_RELEASE fault classes: an evidenced explicit prohibition may now carry its own effective timestamp, so a revocation timestamped after the execution time being reasoned about no longer retroactively denies an action that occurred before it took effect, while one timestamped before continues to deny it exactly as before. datatracker.ietf.org and ietf.org were both blocked by this session's network egress policy; this addition rests on the draft's own canonical source repository, fetched directly, graded documented rather than verified. The draft carries no working group and its proposed BoF has been deferred.
Recorded instances
- AEV-2026-0038 Ruflo's MCP bridge reached an unblocked terminal_execute and a writable AgentDB with no authentication (CVE-2026-59726) AESS 8.5 high Confirmed
Protocol evidence
Published authority architectures whose artifacts bear on the requirement this weakness names: which satisfy it, which expose a way past it, and which leave it unanswered.
- Supports requirement
An Architecture for Auditing Agent Delegation and Interactions (audit-architecture)
Mirja Kuehlewind (Ericsson) and Henk Birkholz (Fraunhofer SIT), individual submission to the IETF
Requirement Authorization is modeled as an ordered sequence of transitions, not a single current value
This weakness names the gap between authority admitted at one moment and authority actually in force at a later moment of consequence, evidenced elsewhere in this registry by CONTINUITY's REVOKED_GRANT and EXPIRED_RELEASE fault classes. The draft's Authorization Transition Record class is the audit-record-format mirror of exactly that property: an ordered previous-state/new-state sequence built so an auditor can reconstruct which state was in force at a specific point in a run, rather than reading the latest known state back over an earlier moment. Recorded as design evidence for the weakness's own principle in the reverse temporal direction, a later revocation must not retroactively deny an earlier, then-still-authorized action; this record's own evidence separately connects to a targeted extension of Moona's canonical Authority Resolution engine implementing exactly that reconstruction for one specific field.
- Missing requirement
Grantex and the Delegated Agent Authorization Protocol (DAAP)
Sanjeev Kumar, Grantex
Requirement Cascade revocation stops future use of descendant grants; nothing found addresses reversing an action a now revoked grant already authorized
This property, verified directly against Grantex's own specification, already records that cascade revocation stops future use of a revoked grant's descendants but that nothing found addresses reversing an action a grant already authorized before it was revoked. Ruflo's own remediation guidance for CVE-2026-59726 is concrete evidence for exactly the same shaped gap one layer further in: an attacker's live access to the MCP bridge was closed by version 3.16.3, and closing it did nothing to whatever the attacker had already written into AgentDB while that access was open, which is why Ruflo's own operators are separately instructed to audit and purge the learning store rather than trust the version upgrade alone. Recorded as a missing requirement because both the specification and this concrete instance name the same unresolved question, whether ending an authority retroactively settles what that authority already produced, without either one describing a mechanism that answers it.
- Missing requirement
x401, the HTTP Proof Requirement Protocol
Proof, with editors from Proof and Circle and reviewers from Lightspark, MATTR, Okta, OpenAI and Visa
Requirement Whether revoking the underlying mandate or credential immediately invalidates an already issued Verification Token is undocumented
This property, verified directly against the base x401 specification, already records that the specification does not state what happens to an already issued Verification Token if the credential or delegation evidence behind it is later revoked, and that no revocation endpoint or propagation rule was found. Ruflo's own incident is the same unresolved question realised as a concrete consequence rather than an acknowledged gap in a draft: an attacker's access was revoked by the fixed bridge, and the persistent state that access had already produced, an AgentDB pattern store entry, is not described anywhere in Ruflo's own material as automatically invalidated by that revocation. Recorded as a missing requirement rather than a supported one, since neither the specification nor Ruflo's own remediation describes a mechanism that propagates a revocation into previously produced, persistent effects; both leave that step to a separate, manual action.