Revision traces send deleted details to recipients

An AI assistant can obey a deletion request and still reveal the deleted detail in its explanation of the edit. Researchers analyzed 26,753 revision requests and found traces of removed material in 8.8% of revised replies. A manager could send a contractor only an available schedule, if the drafting tool keeps its private editing commentary out of the handoff.

Deleting a sentence from an AI-written message does not always delete the information inside it. A manager might remove an employee’s medical appointment from a schedule before sending it to a contractor, yet the assistant could add: “I removed the medical appointment.” The contractor now knows what the manager meant to keep private. Teams that forward an assistant’s entire reply face the same problem: the finished message and the assistant’s private editing history may arrive as one package.

The hidden second message

AI assistants are increasingly used to draft emails, reports, code comments, and workplace documents for other people. During that drafting, a user may add a fact and later ask the assistant to remove or replace it. The requested body can be clean while a preface, afterword, or comment explains what disappeared.

This explanation is a revision trace: a recipient-facing account of an edit. It may sound helpful to the person doing the drafting. It is not necessarily safe for the person who will receive the result. An instruction such as “delete this” is also not a firm access-control boundary. The same reply can mix information meant for the recipient with information about the private process that produced it.

This problem resembles tracked changes, comments, metadata, and failed redactions in ordinary document systems. But a language model can recreate the problem in ordinary prose, without showing a visible markup layer.

When the explanation leaks the edit

The researchers describe this as a separate channel for disclosure: the model obeys the edit in the main text, then brings the withdrawn item back in its explanation of the edit. They analyzed 26,753 revision requests from three public conversation collections and found revision traces in 8.8% of revised replies.

They then built RevLeakBench, a test set of 100 tasks covering private conversations and AI agents. In the tests, a reader saw only what was treated as the deliverable and tried to recover the withdrawn item. The reader recovered it in 13.7% of conversation cases. Personal information was recovered more often than information the user had simply decided not to send.

The result points to a simple but important distinction. Removing words from the requested document is not enough. The system must also decide which parts of its own explanation belong to the recipient. A forwarding interface that treats the complete assistant reply as the document has no dependable line between those two things.

The researchers tested ways to create that line. Telling the assistant to return only the deliverable lowered the trace rate and reduced recovery. An output filter that removed identified edit sentences lowered recovery still further, to 1.3% in the conversation tests. But that filter needs two kinds of information: aliases for the withdrawn items and notes about content that must remain. A real tool would have to obtain those constraints from the interaction or from another component.

What a safe handoff would look like

In a workplace chat, the manager could remove the medical appointment, and the contractor would receive only the available times. There would be no explanatory sentence naming the appointment. The tool would have to enforce a recipient-only handoff instead of forwarding its editing commentary.

The same boundary could matter in code review. An engineer might remove a credential or internal endpoint from an example configuration. The public comment would contain the corrected example, while filtering would remove the sentence that names the secret without removing technical instructions collaborators still need.

That future depends on tools reliably separating required content from private drafting history. It also depends on filters knowing what was withdrawn and what the recipient still needs. The benchmark does not cover multilingual, long-running, or executable-code settings, so the boundary has not been tested everywhere. But its central lesson is already clear: “deleted” must mean absent from the handoff, not merely absent from the document’s main paragraph.

Sources

arXiv, “Nothing to See Here'': Unintended Disclosure through Revision Traces of LLM Deliverables