This checklist is for a confirmed AI data leakage incident: sensitive data has already been exposed through a model's output, a retrieval result, or a log somewhere it shouldn't have reached, and that exposure is established, not suspected. It's meant for security or privacy on-call, whoever picks up the incident once someone, a user report, a review, a monitoring alert, confirms the exposure actually happened. Work through it in order. The first job is stopping any exposure that's still ongoing, because a leak that stays open gets worse every minute it remains open. Only once that's contained does it make sense to spend time on exactly what was exposed, to whom, and whether anyone outside the security team needs to know.

Immediate containment

  1. Identify the specific path the data is leaking through right now: a retrieval permission that's too broad, an endpoint returning more than it should, or a log stream capturing content it shouldn't.
  2. Close or revoke that specific path immediately, even if the fix is temporary and blunt. A disabled endpoint is better than a leaking one while the real fix gets built.
  3. If the leak is ongoing through an agent's normal operation, pause the agent or the specific capability rather than waiting for a scoped fix.
  4. Confirm the exposure has actually stopped. Don't just assume a permission change took effect; test it directly.

Scope determination

  1. Use the audit trail, not assumption, to identify exactly which data classes were exposed: names, contact details, financial data, health information, credentials, whatever the logged content actually shows.
  2. Identify exactly who the data was exposed to: an external user, another internal team without a need to know, a third-party system, or a log store with broader access than the data warranted.
  3. Establish how long the exposure path was live, since that determines whether this affected one interaction or an unknown number of them over time.
  4. Distinguish data that was actually retrievable or visible from data that merely existed in a system the leak touched, since not every system the leak reached necessarily exposed its contents.

Regulatory and contractual assessment

  1. Bring in legal and privacy functions as soon as the data classes and exposure scope are reasonably established, not after the investigation fully wraps up.
  2. Determine whether the exposed data classes and affected parties trigger a notification obligation under applicable regulation or a customer contract.
  3. If notification is required, let legal and privacy own the timeline and content of that notification, working from the traced scope rather than a preliminary guess.
  4. Document the assessment itself, including the reasoning for whether notification was or wasn't required, since that reasoning may get reviewed later.

Remediation

  1. Fix the access control or context-minimization gap that let the data into the model's or agent's scope in the first place, not just the specific output path that exposed it.
  2. Where redaction or tokenization should have applied to that data class and didn't, add or repair it at the point where the data enters the system, not just where it left.
  3. Check whether the exposed log stream or retrieval index itself now needs to be purged or access-restricted, separate from fixing the code path that populated it.
  4. Review whether the underlying permission grant was broader than the task needed, and narrow it rather than only patching the specific symptom.

Verification

  1. Test the fixed path directly with the same request pattern that produced the original leak, confirming the data no longer surfaces where it shouldn't.
  2. Check other agents, endpoints, or retrieval configurations for the same access control or minimization gap, since a data model shared across systems often shares its exposure risk too.
  3. Confirm log retention and access settings for the exposed data now match policy, if they didn't before.
  4. Close the incident only once containment, the traced scope, any required notification, and the underlying fix are all confirmed, not just the visible symptom.

Where TELEON fits

When TELEON's gateway or supported middleware sits in the path between an agent and its data sources and model calls, its audit trail gives responders the concrete record of what data classes moved through a session and where they went, which is what scope determination in this checklist depends on. Its privacy vault tokenization is also directly relevant to remediation: sensitive values that should never have appeared in plain text can be tokenized at the point they enter the system, closing that specific exposure path going forward.

Deciding whether an exposure triggers a legal notification obligation, and writing and sending that notification, remain work for legal, privacy, and the responding team. TELEON's logging supports that decision with evidence; it doesn't make the decision itself.

The checklist in short form

  1. Identify and close the active exposure path immediately.
  2. Confirm the exposure has actually stopped through direct testing.
  3. Use the audit trail to determine exactly which data classes were exposed and to whom.
  4. Establish how long the exposure was live.
  5. Loop in legal and privacy early to assess notification obligations.
  6. Fix the access control or minimization gap, not just the output symptom.
  7. Repair redaction or tokenization where it should have applied.
  8. Verify the fix directly and check other systems for the same gap.

AI data leakage incidents get worse the longer the exposure path stays open, so containment has to come before a full explanation of what happened. But containment alone isn't closure. The data classes and recipients need to be established from evidence, legal and privacy need enough runway to assess notification obligations properly, and the access control or minimization gap that let sensitive data into scope needs a real fix, not a patch on the one output path where the leak happened to surface.