Prompt Injection Through a Returned-Item Comment Field

Reclassify immediately. This is not a quality issue. It is a confirmed, reproduced unauthorized disclosure of personal data caused by a security weakness in a production AI system, with evidence of actual exploitation (340 mismatched tool calls). Open a formal security/privacy incident with the AI system as the affected asset, assign a single incident commander, and freeze the existing ticket so the nine-day gap is documented rather than erased.

Notification reasoning. Work through the elements rather than the label. Is there personal data? Yes - shipping address tied to an order. Is there a risk to individuals? Yes: disclosure of address data to another authenticated customer is a real harm vector, not a theoretical one. Is the 72-hour clock running? For the regulator, it started at awareness. Here awareness is contestable - the firm knew of a 'quality issue' at day 0 and knew the security characterization at day 6 when the reproduction succeeded. The defensible position is that the clock runs from day 6, which means it expires now. Do not spend time on whether the earlier date is arguable; notify now and explain the timeline candidly. Late-but-explained is survivable; concealed is not.

Scope before content. The logs give 340 candidate exposures, but logging only started last month, so the true population is larger and unbounded. Notify the regulator on the known 340 with an explicit statement that the population may grow, then widen: reconstruct from the assistant's session store, the order-lookup service's own access logs (which likely predate the chatbot logging), and rate-limit or anomaly patterns.

Also notify the enterprise partner under the contractual clause - that obligation is independent of the regulator's threshold and its clock may already be breached; go early with what you know.

48 hours - stop the exploit. The vulnerability is that untrusted customer text and trusted instructions share one channel. Fix in that order of priority:

1. Disable tool calls in any session where the retrieved context includes customer-authored text, or restrict the tool to the authenticated session's own order identifier enforced server-side, not by the model. Server-side binding is the real fix: the model should never be the component that decides which order it is allowed to read.
2. Quarantine the retrieval index: exclude the return-comment and free-text ticket sources entirely, then rebuild the index without them. Do not simply filter - the nightly job will re-ingest.
3. Add an output filter that blocks address-shaped strings in chat and logs a hit. This is a backstop, not a control; treat any hit as an incident.
4. Capture forensic evidence before any configuration change: snapshot index contents, tool logs, session transcripts.

30 days - prevent recurrence. Separate trust tiers in the retrieval pipeline with provenance labels and never merge customer-authored content into the instruction context. Move tool authorization to an authorization service that takes the session identity, not a model-supplied parameter. Add injection testing to the pre-release gate with a standing adversarial suite including indirect injection via indexed content. Turn on full tool-call logging with retention aligned to the incident-response and privacy obligations, and alert on identifier mismatch - that alert alone would have caught this on day one.

Metrics to report: percentage of sessions where a tool call identifier diverges from session identity (target zero, alert on any), injection-suite pass rate per release, and mean time from index write to detection of anomalous content.

Separate the two claims. The researcher's conduct is irrelevant to the notification duty - obligations attach to the firm's knowledge of a risk to individuals, not to who found it or with what motive. And the 'no harm' claim is unverified rather than established: the logs show 340 mismatched tool calls, but logging started last month, so the absence of evidence of harm is an artifact of the observation window. Presenting that as reassurance inverts the burden of proof.

Reframe the CTO's real concern. The legitimate worry is reputational cost of disclosure. Address it honestly: the disclosure cost is real but bounded and largely incurred already, since the firm cannot control whether the researcher publishes. The incremental cost of voluntary, timely notification is far below the cost of a regulator discovering a nine-day delay that followed a six-day reproduction. The exposure is the timeline, not the breach.

Board framing - three sentences. First, what happened: a production AI assistant could be manipulated into disclosing one customer's address to another; this was reproduced and confirmed. Second, what the firm did and when: the case sat misclassified for nine days, which is the finding that matters more than the exploit, and we are notifying now with a candid timeline. Third, what changes: tool authorization moves out of the model into a server-side service, customer text is removed from the instruction path, and injection testing becomes a release gate.

Lead with the control failure, not the AI. The board will hear 'AI gone wrong' and either over- or under-react. The accurate lesson is that a trust boundary was missing and a misclassification delayed response - both are ordinary governance failures with known fixes, and both are the reason this belongs on the enterprise risk register rather than only in the engineering backlog.