Notifications
Clear all
Topic starter
09/07/2026 12:36 pm
TL;DR: An over-length GPT-5 prompt followed by Retry could produce unrelated replies, suggesting a cross-session context reconstruction flaw that may create contamination risk even without confirmed data exposure, according to Knostic. The issue matters because error handling in AI systems needs the same control discipline as normal conversation paths.
NHIMG editorial — based on content published by Knostic: GPT-5 retry errors and cross-session context contamination risk
Questions worth separating out
Q: How should teams prevent AI retry errors from crossing conversation boundaries?
A: Teams should treat retry handling as a security-sensitive path, not a convenience feature.
Q: Why do AI session reconstruction bugs create governance risk?
A: They can cause the system to answer from the wrong context even when no attacker has changed the prompt.
Q: What breaks when AI systems reuse stale context after an error?
A: The main failure is loss of conversation isolation.
Practitioner guidance
- Test degraded retry paths separately Build test cases for message-length failures, partial state commits, and retry actions that omit the full message array.
- Enforce session-bound context assembly Require the application layer to bind every generation request to a single session identifier and reject any fallback path that can pull from another conversation’s cached state or parent_message_id lineage.
- Log context provenance for each response Record which messages, retrieval results, and cache entries informed every generated answer so investigators can trace contamination, prove isolation, and compare the assembled context against the triggering prompt.
What's in the full article
Knostic's full research post covers the operational detail this post intentionally leaves for the source:
- Reproduction notes showing how the over-length prompt and Retry sequence behaved across multiple accounts and sessions.
- The exact message-length failure condition and the variant call pattern that triggered context reconstruction.
- Knostic's explanation of why the response source looked unrelated to the triggering prompt and what that could mean for enterprise AI governance.
- The product and policy framing around context ring-fencing, prompt-level policy, and audit trails.
👉 Read Knostic's analysis of GPT-5 retry errors and cross-session context bleed →
GPT-5 retry errors and context bleed: are controls keeping up?
Explore further
09/07/2026 12:41 pm
AI session integrity is now a governance control, not a user-experience detail. When retry logic can reconstruct context from partial state, the enterprise has to treat session binding as part of its security boundary. That matters for copilots, AI search, and agent workflows where the output may influence decisions, approvals, or disclosures. Practitioners should govern conversation state as a protected control surface.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37%, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: How can security teams assess whether AI outputs are tied to the right session?
A: They should verify that each response can be traced back to a single session, a specific message chain, and a known retrieval set. If that lineage cannot be reconstructed from logs, the platform is not giving enough evidence to support investigation, compliance review, or safe use in regulated workflows. The phrase to look for is context provenance.
👉 Read our full editorial: GPT-5 retry errors raise cross-session contamination risk
