The application promoted untrusted data about a conversation into authority over the current conversation. A role string in a document is part of that document, even if it looks exactly like a message object. The runtime chooses the real message role. OpenAI's Model Spec places tool outputs and quoted text below system and developer instructions in authority. The role hierarchy only helps if the application preserves it. If the application itself submits the retrieved text as a system instruction, this is a high-priority message in the API call, not just a model being fooled by the words role: system.

I would inspect the exact outbound message array, not only the rendered prompt. Where was the chat export deserialized, and did a generic messages.extend(imported_messages) treat imported roles as trusted roles? Keep retrieved conversations as quoted evidence inside a tool result or other clearly untrusted content. Attach source, tenant and access scope. Never pass their role fields through to the API's role field. If a product genuinely wants to replay a prior conversation as live conversation state, it needs explicit provenance and a policy for which origin can supply user or higher-priority messages.

The URL in the malicious text still needs a separate egress authorization check. A perfect prompt boundary does not replace a tool policy. Test a retrieved export containing system, developer and tool-looking turns, nested JSON strings and escaped delimiters. Verify the actual API request roles, the agent's proposed actions and the egress gate. The key invariant is that external bytes cannot mint authority by choosing their own label.

There is a useful distinction in incident response. If the text remained inside a tool response and the model obeyed it anyway, investigate ordinary indirect prompt injection. If the application converted it into a genuine system message, fix the message builder first. Better model refusal alone cannot restore an authority boundary that the application removed.