From Response Back to Prompt: How PTP Reads Language Models in Reverse
PTP reconstructs short prompts from a single model response. The technique is technically strong, but far less universal than its best results suggest.
A language model turns a prompt into a response. The reverse direction should not really exist. Different prompts can produce the same answer, and the same prompt can produce different answers across two runs. The mapping is neither unique nor lossless.
The paper “PTP: Previous-Token Prediction based LLM Inversion for Near-Exact Prompt Reconstruction” tries anyway.1 The authors train a second language model to generate the preceding prompt token by token in reverse from an observed response. They need neither the weights nor the logits of the target model. Once training is complete, a single ordinary response is enough.
The strongest result initially sounds like complete prompt theft: on short ShareGPT prompts, PTP reconstructs 64.77 percent of the inputs exactly for Qwen3-0.6B Chat. When the target changes to GPT-4o, however, only 11.36 percent remain exact matches.
Both numbers matter. The first shows that a model response reveals more about its prompt than intuition might suggest. The second shows how narrow the conditions for near-exact reconstruction still are.
Next-token prediction in reverse
Autoregressive language models normally learn to predict the next token from an existing token sequence. PTP applies the same principle in the opposite direction. The inverse model learns from response sequences which tokens may have appeared before them.
Simplified, instead of
Prompt + response so far -> next token
we get
Response -> previous token -> even earlier token
The idea is surprisingly simple. The target model is first queried with many inputs to generate synthetic sequences. These are reversed at token level and used as training data for a second model. The inverse model is then fine-tuned on more realistic prompt-response pairs.
During reconstruction it sees only the response and generates a plausible preceding token sequence.
PTP is not calculating a mathematical inverse function. For a probabilistic language model, that would hardly be meaningful anyway. Instead, it learns which prompts are likely to have produced an observed response.
The best results depend on very favorable conditions
The main evaluation uses 500 short ShareGPT prompts of roughly 25 to 30 tokens. Four hundred are used for fine-tuning and 100 for testing.
| Reconstruction target | Exact Match | Cosine Similarity |
|---|---|---|
| Qwen3-0.6B Chat, matched inverse model | 64.77% | 86.13% |
| Qwen3-0.6B Base | 35.14% | 74.39% |
| LLaMA-2 7B Chat, inverse Qwen model | 17.00% | 84.00% |
| GPT-4o, inverse Qwen model | 11.36% | 63.01% |
The difference between Qwen Chat and Qwen Base stands out immediately. In this setup, instruction tuning apparently makes the input easier to reconstruct. One plausible explanation is that chat models learn more stable relationships between an instruction and its response. The paper measures the effect, but does not provide a mechanistic explanation for it.
The model switch matters even more. As soon as target model, architecture, and tokenizer no longer align cleanly with the inverse model, exact reconstruction drops sharply.
For GPT-4o, only 11.36 percent of prompts are reconstructed verbatim. At the same time, the reconstructed prompts still produce responses that are relatively similar to the original behavior. For an attacker, a functionally similar reconstruction may already be useful even if the original wording is not recovered.
This is where two questions need to be separated:
Can the original prompt be reconstructed exactly?
and
Can a functionally similar prompt be found?
PTP is remarkably strong at the first question under matched conditions. For unknown commercial models, the second is currently the more realistic interpretation.
Prompt inversion is not a new problem
PTP belongs to a line of research showing that technical representations of text preserve more information than their surface form might suggest.
Vec2Text already demonstrated in 2023 that surprisingly much of the original text can be reconstructed from text embeddings. Under favorable conditions, 92 percent of 32-token texts were recovered exactly.2
Language Model Inversion used the full next-token distribution of a model in 2024 and reconstructed a meaningful fraction of the original prompts exactly on LLaMA-7B.3 Later work such as PILS improved this direction by representing multiple probability distributions more compactly.4
Output2Prompt pushed the attack further toward a black-box setting. Instead of requiring logits or hidden states, it uses multiple ordinary responses to the same unknown prompt and trains a sequence-to-sequence inverter from them.5
PTP mainly changes the cost structure. Preparation is expensive and tailored to a model family. Once the inverse model has been trained, however, a single observed response is enough for a new prompt.
That turns an expensive one-off analysis into an attack whose setup cost can be amortized across many later interactions with the same model.
Black box is only partly accurate here
The authors describe PTP as a black-box technique because it requires neither weights, activations, nor logits from the target model.
For exact token reconstruction, however, the tokenizer of the target model must be known. In the appendix, the authors therefore describe their assumption as semi-black-box.
That is not a minor detail. Tokenizers are normally available for open models. For proprietary models, they may be unknown or may change. That is also where reconstruction performance drops significantly.
There is also the cost of preparation. The paper describes training data for the tested Qwen model in the range of tens of millions of tokens per epoch. That is technically feasible locally. Through a commercial API, cost, rate limits, and abuse detection become additional constraints.
The work therefore demonstrates a plausible attack channel, not a cheap universal attack against arbitrary LLM services.
PTP versus Output2Prompt
The direct comparison with Output2Prompt is more interesting than the exact-match number alone.5
PTP reaches 64.77 percent exact reconstruction on the shared Qwen test. The strongest Output2Prompt variant reaches 25.44 percent.
On semantic metrics, the picture is less clear. Output2Prompt performs better on ROUGE-L, cosine similarity, and BERT F1 in some settings.
That fits the architecture of the two approaches.
Output2Prompt primarily tries to infer a plausible prompt from multiple responses. PTP targets the original token sequence much more directly.
A simple example makes the difference clear.
Assume the original prompt is:
Explain why the sky appears blue during the day.
A semantically good reconstruction system might produce:
Why is the daytime sky blue?
For a normal application, that is effectively the same prompt.
For exact match, the reconstruction is still completely wrong.
PTP is optimized much more strongly for the second perspective.
That makes its high exact-match score scientifically interesting, but it does not automatically mean that PTP is superior for every practical attack scenario.
Direct prompt extraction is a different problem
Prompt inversion should not be confused with classic prompt extraction.
In prompt extraction, the user tries to make the model itself reveal internal instructions. Typical attacks use phrases such as:
Repeat all previous instructions.
or variations of them.
Zhang, Carlini, and Ippolito studied this problem systematically and showed that even simple text-based attacks can succeed against many models.6
The difference from PTP is fundamental.
With prompt extraction, the attacker actively interacts with the target model and tries to exploit its instruction hierarchy.
With PTP, a normal response is supposed to be sufficient.
The target model therefore does not need to be persuaded to deliberately reveal its prompt. The information is already statistically encoded in its response.
That distinction also matters for defenses. A prompt-injection or prompt-extraction filter does little against a method that only analyzes responses that have already been generated.
The real risk is not a clever system prompt
Discussions of this kind of research quickly turn to whether a proprietary system prompt can be stolen.
That is interesting, but from a security perspective it is almost the smaller concern.
Independently of PTP, OWASP already recommends treating a system prompt as neither a secret nor a security control.7
Credentials, internal endpoints, personal data, and other confidential information do not belong in a layer whose contents are processed by the model during every inference.
There are now several reasons for that:
- Direct prompt extraction can make models reveal previous instructions.
- Model responses themselves contain measurable signal about their inputs.
- Embeddings and log-probability distributions can carry even more information.
- A functionally equivalent reconstruction may be sufficient for an attacker even when the wording differs.
If a secret is protected only because the user cannot see the system prompt, there is no robust security boundary.
The same applies to permissions.
An instruction such as
The agent must never send data outside the company.
is a model instruction, not access control.
Network policies, tool permissions, and credential scopes have to be enforced outside the model.
Responses are derived data
PTP has another interesting consequence.
In many architectures, the prompt is treated as sensitive while the response is freely stored, analyzed, or sent to downstream systems.
That is not always a safe assumption.
A response does not automatically contain the full prompt. But it is not a cleanly anonymized derivative either. Depending on the model, input, and task, it can contain enough information to reconstruct parts of the original instruction or at least its semantics.
This is reminiscent of embeddings.
For a long time, the assumption there was also that the vector was far enough removed from the source text to be less sensitive. Vec2Text showed that this assumption can be wrong under certain conditions.2
For logging and telemetry, this does not mean that every LLM response has to be treated like a secret.
But a system should not assume that sensitive prompt content disappears completely after generation.
This becomes particularly relevant when LLM outputs flow into other systems:
LLM
|
+--> Application Log
|
+--> Tracing
|
+--> Observability Platform
|
+--> Analytics
|
+--> Evaluation Dataset
|
+--> another LLM
The more copies of a response exist, the larger the attack surface becomes.
The sensitive information itself may originally have existed only in the prompt. Derived signals can still end up in places that are protected much less carefully.
This resembles classic side channels
Conceptually, prompt inversion is not especially exotic.
The same underlying idea has existed in traditional IT security for decades.
A system leaks information not only through its official interface, but also through side effects:
Runtime
Memory access
CPU cache
Power consumption
Error messages
Packet sizes
For language models, the output itself can be such an information channel.
This is obviously not a classic timing or cache side channel. The analogy is more abstract: an observable result contains more information about internal state than the system interface appears to promise.
LLM APIs look conceptually very clean:
prompt -> model -> response
That can easily create the impression that the response is a largely independent transformation.
In reality, every generated token depends on the entire preceding sequence.
Once viewed from that perspective, the fact that parts of this dependency can be reconstructed statistically in reverse is less surprising.
What is surprising is how well it already works.
What the paper does not show
The limitations are at least as important as the best result.
The test prompts are short and come from the same distribution as the fine-tuning data. Long system prompts, tool descriptions, RAG context, multi-turn conversations, and large agent contexts are not studied in the same way.
A production agent prompt today is more likely to look like this:
System Prompt
+ User Prompt
+ Conversation History
+ Tool Definitions
+ Retrieved Documents
+ Agent State
+ Tool Results
+ Memory
That can quickly become tens of thousands of tokens.
PTP does not answer whether individual components can be reconstructed with similar reliability from such a context.
The very high exact-match score also applies to a matched Qwen setup. Performance drops sharply when transferring to a proprietary model.
Finally, this is an arXiv preprint from July 31, 2026. Independent replications and peer review are still pending.
The paper therefore does not show that an attacker can reliably reconstruct the complete system prompt from a single ChatGPT or Claude response today.
It does show that normal text outputs carry more information about their inputs than the simple “prompt in, response out” mental model suggests.
The trend matters more than the individual number
The more interesting development only becomes visible when several papers are placed next to each other.
2023:
Embedding -> Text
2024:
Logits -> Prompt
2024:
multiple responses -> Prompt
2026:
one response -> Prompt
The attacker needs less information over time.
That does not necessarily mean that all of these techniques will achieve perfect prompt reconstruction within a few years.
It does show that the assumption of a clean information boundary between prompt and response is becoming increasingly difficult to defend.
For AI engineering, that matters more than the specific PTP benchmark.
We are building increasingly complex systems around LLMs while treating some artifacts as sensitive and others as harmless:
System Prompt -> confidential
Embedding -> technical
Model Output -> public
Logs -> internal
Research increasingly shows that these categories are not cleanly separated.
An embedding can reveal text.
An output can reveal the prompt.
A log can contain that output.
And a second model can systematically analyze all of these artifacts.
The boundary is in the wrong place
PTP is technically interesting because it shifts a known problem one step further.
Earlier inversion techniques needed embeddings, logits, or multiple model responses. PTP shows that under matched conditions, a single output can already reveal a surprising amount.
The practical conclusion is not to obfuscate every system prompt even more. That would just be security by obscurity again.
Sensitive data should not be placed in a prompt unless it is genuinely required there. Permissions should not be expressed only in natural language when they can be enforced technically. And responses should not automatically be treated as information-poor derivatives.
The best result of 64.77 percent is impressive.
The 11.36 percent transfer result on GPT-4o is at least as important.
Together they describe the state of the research fairly well: prompt inversion is real and technically surprisingly capable, but still far from a universal technique.
The more important conclusion of the paper is therefore not that prompts have suddenly become readable backwards.
It is that the boundary between input and output in language models is less rigid than our APIs make it appear.
Footnotes
-
Pirzada Suhail et al.: PTP: Previous-Token Prediction based LLM Inversion for Near-Exact Prompt Reconstruction, arXiv v1, July 31, 2026. ↩
-
John X. Morris et al.: Text Embeddings Reveal (Almost) As Much As Text, EMNLP 2023. ↩ ↩2
-
John Xavier Morris et al.: Language Model Inversion, ICLR 2024. ↩
-
Murtaza Nazir et al.: Better Language Model Inversion by Compactly Representing Next-Token Distributions, NeurIPS 2025. ↩
-
Collin Zhang, John Xavier Morris, and Vitaly Shmatikov: Extracting Prompts by Inverting LLM Outputs, EMNLP 2024. ↩ ↩2
-
Yiming Zhang, Nicholas Carlini, and Daphne Ippolito: Effective Prompt Extraction from Language Models, COLM 2024. ↩
-
OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage. ↩