On August 19, OpenAI announced Private Safety Processing, a system designed to identify patterns across related interactions without giving OpenAI personnel access to the underlying content. Microsoft and Databricks are early testers, with a broader release and technical paper expected in September. The announcement frames this as compatible with zero data retention. Risks are emerging not just by looking at one single prompt and response pair, but over time at multiple interactions.
This is not about better logging. This is admission that the threat model changed and nobody's retention policy caught up.
I run systems with zero-retention promises. The estimating SaaS at estimate.pro doesn't log job details after the estimate renders. The review-request pipeline at Valhalla K9 doesn't keep SMS message bodies past delivery confirmation. The construction ERP promises contractors that bid data disappears after the RFP closes. Those are contract terms, not best practices. I can't retroactively decide to keep thirty days of logs because a new attack pattern needs it.
The slow-burn attack doesn't fit in one session
A person may ask about a weakness in a company's software in one conversation, then later ask about remote access or security tools; looking at these questions separately may not reveal a threat, but together they could point to a possible cyberattack. The example is clean. The sequence isn't.
Private Safety Processing can analyze inputs and responses across multiple conversations, a form of long-horizon safety monitoring that assesses multiple conversations—not just one. The system fills that gap without giving OpenAI employees access to the underlying prompts or responses. This is the same architectural problem I solved in review gates: you need to see the pattern without storing the data.
I don't log payroll amounts. I log whether the payroll run was inside expected bounds. I don't log invoice line items. I log whether the total matched the estimate within tolerance. I don't log who the Twilio dialer called. I log how many calls went out and whether the list size triggered the rate limit. The data expires. The metadata doesn't.
Cross-session correlation is expensive and most teams skip it
I pulled session logs for the construction ERP last week. A contractor requested the same closed job's detail page four times across two weeks, each time from a different IP. Each request was clean. The fourth one exported a CSV. Alone, that export is normal. In sequence, it's reconnaissance followed by exfiltration.
I only caught it because I was debugging a separate caching bug and happened to grep the access logs before they rotated out. The system had no cross-session visibility. Each request hit the review gate, passed, and disappeared. The pattern was invisible until I manually stitched four log files together.
Building that correlation layer costs more than most teams budget for it. You need session stitching, semantic clustering, and a separate model that scores patterns instead of single requests. Cross-session corroboration matters; repeated offensive steps, exploit targeting, bypass requests, payload crafting, or exfiltration attempts across different session IDs are strong evidence of systematic misuse. The research calls this stateful online monitoring. I call it the thing I should have built in 2022.
I added it to three systems last month. The invoice approval workflow now checks whether the same vendor has been edited multiple times in short succession, even across different login sessions. The database sync job checks whether schema drift requests are clustering around the same tables. The review-request SMS pipeline checks whether the same phone number is being called from multiple campaigns in the same week. None of those are per-request violations. All of them are cross-session red flags.
Zero retention and cross-session monitoring are supposed to be incompatible
Zero Data Retention gives eligible API customers a clear promise: OpenAI does not retain their prompts or model responses after a request is processed, and customer content is not available to OpenAI personnel for review. Anthropic, meanwhile, now wants 30 days of logs. That's the trade-off everyone assumed was mandatory. You either keep the data and get cross-session safety, or you delete it and accept single-request blind spots.
OpenAI is claiming you can have both. The technical paper isn't out yet. My guess is semantic embeddings with extremely short retention windows, pattern matching on derived features instead of raw content, and a separate classifier that only sees aggregated risk scores. That's how I'd build it. Store the suspicion level, not the thing that made you suspicious.
The contract says the data disappears after processing. The threat doesn't care what the contract says.
I'm not waiting for the September paper to fix this. I added cross-session metadata tracking to the ERP's audit system this week. Session ID, timestamp, endpoint hit, whether the response triggered a boundary check, and a rolling suspicion score. No job details, no bid amounts, no contractor names. The data I promised to delete still deletes. The pattern I need to see stays visible for seventy-two hours, then expires.
The first correlation run flagged two things: a subcontractor who requested the same change-order form six times in three days from different devices, and an estimator who exported the same job's labor rates twice in one hour after the estimate closed. Both were benign. Both would have been invisible under the old single-request model. The third flag won't be benign, and now I'll actually see it before it finishes.