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 distinction between the two gates is right, and it catches something most implementations miss. There is a third boundary neither gate covers, because it sits before both: what gets projected into context when the conversation continues. A response gate checks what the model may say back. A history gate checks what a later read may replay. Neither checks what gets assembled into the prompt for the next turn. If a document is hidden after it already sat inside an earlier exchange, and that exchange gets pulled back in as context, the document returns without touching search or the history endpoint at all. It entered through the window itself, so the permission check guarding the other two paths never fires, because nothing routed the request through a checkable interface.
One practitioner building a comparable retrieval system phrased the constraint on that operation this way: never truncate a context window, only merge it, replace it, or drop it entirely. Truncation keeps the record but throws away its status, and nothing in the response signals that anything was cut. Applied here, the redaction decision has to run again at context assembly for every continuation, not once at serialisation, or the revoked state quietly degrades into a shorter version of itself.
What I do not know is whether continuation context in your setup gets rebuilt from a stored transcript or re-derived from the retrieval call each time. That detail decides whether this is a genuine third gate or a stricter version of the second one.
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.
The distinction between the two gates is right, and it catches something most implementations miss. There is a third boundary neither gate covers, because it sits before both: what gets projected into context when the conversation continues. A response gate checks what the model may say back. A history gate checks what a later read may replay. Neither checks what gets assembled into the prompt for the next turn. If a document is hidden after it already sat inside an earlier exchange, and that exchange gets pulled back in as context, the document returns without touching search or the history endpoint at all. It entered through the window itself, so the permission check guarding the other two paths never fires, because nothing routed the request through a checkable interface.
One practitioner building a comparable retrieval system phrased the constraint on that operation this way: never truncate a context window, only merge it, replace it, or drop it entirely. Truncation keeps the record but throws away its status, and nothing in the response signals that anything was cut. Applied here, the redaction decision has to run again at context assembly for every continuation, not once at serialisation, or the revoked state quietly degrades into a shorter version of itself.
What I do not know is whether continuation context in your setup gets rebuilt from a stored transcript or re-derived from the retrieval call each time. That detail decides whether this is a genuine third gate or a stricter version of the second one.
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.