Rebuilt from the stored thread, not re-derived from retrieval, so it's a genuine third gate and not a stricter second one.
It's also the one place where the rule we landed on (a revoked capability applies to the next turn) needs its own enforcement point. The next turn's context is assembled from a checkpointed thread that holds tool results retrieved under the old entitlement. Revoking the copilot entirely closes it, because no turn is admitted at all. A narrower revocation, like the document capability or view permission on a single document, doesn't reach what's already in the thread.
The assembly step already rewrites history on every model call (guardrail scoping, tool-call repair, version stamps on document-bearing results), so that's where re-authorization would live. And your merge/replace/drop rule matches a precedent we already have: when a turn is cut short, the missing tool result is replaced with an explicit "this didn't complete, treat it as unavailable" message instead of being dropped, so the model sees the gap rather than a shorter conversation. A revoked result deserves the same treatment.
Building persistent memory for AI agents at Mnemoverse.
I write about the unglamorous half: forgetting, contradiction, and the moment an agent confidently repeats a fact you retracted.
The cut-short precedent fits, with one difference that decides where the placeholder can live. "This did not complete" is a fact about that turn and stays true forever, while "this was revoked" is a fact about the current entitlement and stops being true the moment the permission comes back. So the revoked placeholder has to be computed at each assembly against the entitlement as it is then, and never written into the checkpoint. If it is written back, a revocation that is later undone has already destroyed the result there, and every later turn is built from the thread as of the last revocation.
The precedent also stops at the tool result, and the turn's own answer is still in the window. If that answer quoted the result, the "card wearing prose" case from earlier in this thread, the next turn receives the content with its evidence marked unavailable. That may be worse than full replay or full redaction, since the model holds a claim it once grounded and can restate it with nothing left to check it against.
The rule that a revoked capability governs the next turn and not the record draws the right line, but the answer text sits on both sides of it. Shown back to the user it is record, and the argument that it was already delivered still holds. Fed back to the model it is material for the next turn, which is what the rule says the revocation should reach.
What I cannot tell from here is whether the version stamps on document-bearing results also reach the assistant message that used them. If they do, one stamp can drive both decisions at assembly. If they sit only on the tool result, the assembly step can find the revoked evidence but not the prose built on it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Rebuilt from the stored thread, not re-derived from retrieval, so it's a genuine third gate and not a stricter second one.
It's also the one place where the rule we landed on (a revoked capability applies to the next turn) needs its own enforcement point. The next turn's context is assembled from a checkpointed thread that holds tool results retrieved under the old entitlement. Revoking the copilot entirely closes it, because no turn is admitted at all. A narrower revocation, like the document capability or view permission on a single document, doesn't reach what's already in the thread.
The assembly step already rewrites history on every model call (guardrail scoping, tool-call repair, version stamps on document-bearing results), so that's where re-authorization would live. And your merge/replace/drop rule matches a precedent we already have: when a turn is cut short, the missing tool result is replaced with an explicit "this didn't complete, treat it as unavailable" message instead of being dropped, so the model sees the gap rather than a shorter conversation. A revoked result deserves the same treatment.
The cut-short precedent fits, with one difference that decides where the placeholder can live. "This did not complete" is a fact about that turn and stays true forever, while "this was revoked" is a fact about the current entitlement and stops being true the moment the permission comes back. So the revoked placeholder has to be computed at each assembly against the entitlement as it is then, and never written into the checkpoint. If it is written back, a revocation that is later undone has already destroyed the result there, and every later turn is built from the thread as of the last revocation.
The precedent also stops at the tool result, and the turn's own answer is still in the window. If that answer quoted the result, the "card wearing prose" case from earlier in this thread, the next turn receives the content with its evidence marked unavailable. That may be worse than full replay or full redaction, since the model holds a claim it once grounded and can restate it with nothing left to check it against.
The rule that a revoked capability governs the next turn and not the record draws the right line, but the answer text sits on both sides of it. Shown back to the user it is record, and the argument that it was already delivered still holds. Fed back to the model it is material for the next turn, which is what the rule says the revocation should reach.
What I cannot tell from here is whether the version stamps on document-bearing results also reach the assistant message that used them. If they do, one stamp can drive both decisions at assembly. If they sit only on the tool result, the assembly step can find the revoked evidence but not the prose built on it.