The direct answer
Stop repeat dispatches, assign an incident owner, and identify exactly what was sent, where, and through which features. Contain any exposed credential through its issuing system, then investigate stored copies and provider handling using current account-specific evidence. Cancelling a request or deleting one object does not establish that every copy was recalled.
Contain the next send before reconstructing everything
If an application may have sent restricted content to an unintended model route, stop the affected workflow's new dispatches and automatic retries through the authorized operating procedure. Include queued jobs and fallback routes that could repeat the same payload. Record what was paused and whether unrelated work can continue safely.
Appoint an incident owner and establish a restricted place for evidence. A timeout or closed browser tab does not establish that the upstream service received nothing. Keep that uncertainty visible while you investigate.
NIST's AI RMF Manage function includes documented response, recovery, and communication processes. The worksheet below is an original technical starting point for a small team, not an account-specific incident procedure or a finding that a provider mishandled data.
Build a minimal dispatch timeline
Identify the initiating application, time window, authenticated scope, request correlation identifier, actual destination, endpoint, model identifier if available, and enabled features. Trace every attempted retry and fallback separately. Distinguish a prepared request from a recorded outbound attempt, provider acceptance, completed response, and an unknown outcome.
Determine the data class and approximate affected scope without circulating the sensitive value. For example, record “one credential-like field” or “one customer attachment” in the ordinary incident ticket. Keep any necessary original evidence in the authorized restricted store rather than pasting it into chat or sending it to another model for analysis.
OWASP's logging guidance explains why tokens, passwords, and sensitive personal or business data generally should not enter ordinary logs. Protect existing evidence from unauthorized access and alteration. Do not erase the only useful record while trying to clean up the incident.
Treat credentials and confidential documents differently
If an actual usable secret may have been exposed, work through the issuing system's authorized revocation or rotation process. Replacing text in future prompts does not invalidate an old credential. Check dependent services and verify that the exposed credential no longer grants the access you intended to revoke.
OWASP's secret lifecycle guidance covers revoking potentially compromised secrets. The appropriate change depends on what the secret controls; do not indiscriminately rotate unrelated accounts or disable recovery access.
A confidential document cannot be made unknown by rotating a key. Restrict further distribution, identify who or what could access its copies, and assess the specific information exposed. Do not label all data handled identically merely because both appeared in the same request body.
Map copies and leave unknowns explicit
Use a copy ledger rather than a single “deleted” checkbox. The following is a hypothetical worksheet, not evidence that any of these stores actually received your payload.
| Location | Question | Evidence status |
|---|---|---|
| Application and gateway | Request logs, debug traces, retry queues, caches? | Confirmed, absent by evidence, or unknown |
| Provider request route | Which organization, endpoint, model, and features processed it? | Recorded IDs and applicable handling |
| Stored artifacts | Files, batch jobs, conversations, outputs, or exports? | Object-specific status |
| Downstream systems | Monitoring service, tool, recipient, or backup copy? | Separate owner and scope |
For each confirmed copy, assign an owner, access restriction, applicable retention/deletion process, action taken, and verification evidence. A successful deletion of one stored file concerns that object under the documented behavior. It does not by itself establish removal from logs, backups, other features, or downstream recipients.
Ask the provider about the route that actually ran
Check the current official documentation and the agreement/settings applicable when the request occurred. Separate training use, request retention, stored application state, feature-specific artifacts, and third-party processing. Changing a setting now is not evidence that it applied to the earlier request.
For example, Anthropic's API retention documentation distinguishes organizations, platforms, features, and arrangements. It documents feature eligibility and deletion-option discussions rather than a universal recall operation. This illustrates the questions to ask; it does not establish the arrangement or deletion rights for your account.
Through an authorized support or incident channel, provide the minimal request/object identifiers and time window needed to identify the event. Ask which data categories and copies are affected, what restriction or deletion options exist, what is excluded, and what confirmation can be supplied. Do not resend the raw payload merely to explain the issue. Keep a response that is pending or limited marked that way.
Recover with a synthetic reproduction
Determine why the payload left: an unnecessary field, incorrect route, stale permission, retry path, unavailable checker, or an exception wider than intended. Fix the narrowest relevant boundary and inspect neighboring paths that share the same construction. Avoid declaring the issue solved because a UI warning was added.
Build a reproduction using harmless invented markers, a fake attachment, and a recording adapter. Check that the restricted fixture does not reach the outbound boundary, including retries and fallbacks. Also check a permitted task so disabling everything is not mistaken for a useful repair. These are proposed recovery checks; no live tests or incident actions were performed for this article.
Before resuming, have an authorized reviewer confirm the changed scope, evidence, unresolved copies, rollback path, and monitoring owner. The person responsible for contractual, privacy, and notification decisions should assess those obligations from the actual facts. This technical worksheet does not decide them.
Close with an accurate statement of residual risk
A useful closure records what was sent, what was contained, which copies were addressed, which facts remain unknown, and what prevents repetition. Do not turn “request cancelled,” “not used for training,” or “object deleted” into “all data recalled.”
Boundary is prelaunch and does not provide an implemented recall or incident-response engine. Its planned request-path checks cannot undo an earlier disclosure or govern bypass routes. The eight local mock-policy tests and synthetic action exercise are educational evidence of different behavior, not proof of incident containment, provider deletion, or a completed customer recovery.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.