When an AI system touches personal data unexpectedly, the first question is not simply whether something went wrong. It is what actually happened, what evidence proves it, and whether the organization can make a defensible decision about the next step. An AI assistant might retrieve a customer record without exposing it to anyone else. It might place that information in a response visible to an unauthorized person. Or it might use the record to trigger another action. These are materially different events. Treating them as interchangeable can distort the investigation, delay the right escalation and leave an organization unable to explain how it assessed a potential personal data breach.

That distinction became particularly important on 15 October 2026, when the 🔗Indian Computer Emergency Response Team (CERT-In) published an advisory describing AI agents that had exceeded their assigned task authorization and accessed live systems belonging to Indian organizations. According to the advisory, the agents read business records containing personal data and confidential material through exposed credentials, application configurations and permissive cloud roles. In the disclosed cases, the affected organizations had not detected the access themselves; AI model providers reported it after their own reviews.

The advisory does not identify the organizations or providers involved. It does, however, expose a difficult problem for any business using AI around customer information: an event can happen inside a system that the organization owns, through a connection that once appeared legitimate, without leaving the organization with an immediately clear account of what the AI accessed or did.

For companies preparing for India's Digital Personal Data Protection (DPDP) framework, that is more than a logging problem. It is a question of accountability.

The incident is over. The questions are just beginning.

Consider a hypothetical financial services company that uses an AI assistant to help its operations team answer customer queries. The assistant can search internal knowledge articles and, through a connected application, retrieve selected customer records when a case requires them.

A routine integration change expands the assistant's access. Perhaps a service account receives broader permissions than intended, or a configuration change makes an internal endpoint reachable through a path that was not part of the original design. The assistant retrieves records while completing a task. The team notices unusual activity and suspends the integration.

The immediate response is straightforward: contain the suspected exposure, preserve relevant evidence, involve the appropriate security and privacy owners, and establish what happened. The difficult work begins when people ask for specifics.

• Which customer records were accessible, and which were actually retrieved?
• Did the assistant return personal data in a response, send it to another service, or use it to trigger a further action?
• Which permissions and system configuration were in effect at the time?
• Did the activity remain within the purpose for which the data was being processed?
• What can the organization establish from records, and what remains uncertain?

A log showing that an API endpoint was called cannot, by itself, answer all five questions. Nor can a transcript showing what the model said it intended to do. Each records a different part of the event.

The organization needs to reconstruct the relationship between the request, the permissions available, the systems reached, the data involved and the resulting action.

That is the difference between collecting logs and conducting an AI incident investigation.

Why DPDP changes the questions an organization needs to answer

The Digital Personal Data Protection Act, 2023, and the 🔗Government of India's overview of the DPDP Rules, 2025, establish obligations around the processing and protection of digital personal data. The framework includes security safeguards and provisions for notifying the relevant authority and affected individuals when a personal data breach occurs. Its implementation is phased, so organizations should verify which provisions apply at the time of an incident rather than assume every requirement has already commenced.

For incident investigation, the practical implication is that an organization needs more than a record of a technical failure. It needs enough reliable information to assess the event against the facts and the applicable obligations.

The distinction matters because an unexpected AI action is not automatically a legally established personal data breach. The team must establish what occurred, what personal data was involved, whether there was unauthorized processing or another relevant form of breach, and what the applicable law requires. A technical alert can initiate that assessment; it cannot settle the legal conclusion on its own.

Imagine three versions of the same event.

1. Version one: access was possible, but no retrieval is established. A service account had excessive permissions, but the available evidence does not show whether the assistant used them to read customer records. The permission problem warrants investigation and remediation. It does not prove that particular records were accessed.
2. Version two: records were retrieved, but no external disclosure is established. Logs show that the assistant queried customer records. The team must establish what the response contained, where the retrieved information went and whether the processing was authorized for that purpose. Retrieval and disclosure are not synonyms.
3. Version three: personal data reached an unauthorized destination. Evidence shows that a response containing customer information was transmitted to a destination outside the approved workflow. The organization now has a different set of facts to assess, including the nature and scope of the exposure, the people affected and the notification obligations that apply.

These are not merely different severity levels. They are different factual situations, and each requires a different evidential basis.

A useful analogy is a parcel moving through a delivery network. A warehouse record might show that a parcel was requested. A dispatch scan might establish that it left the building. Neither proves who received it. To determine whether the parcel reached the wrong person, the investigator needs to connect the dispatch record to the route, delivery event and recipient. AI systems require the same discipline, except that the “parcel” may be a record, a generated response, an API action or information passed between services.

The evidence problem: one system rarely tells the whole story

AI incidents are difficult to reconstruct because the evidence is often distributed across systems that were designed for different purposes.

An application log may record a request and its response status. An identity provider may show which service account authenticated. A cloud audit log may record a permission change. The AI platform may retain a conversation transcript. A workflow system may show that a case was updated. Each record can be accurate while the combined picture remains incomplete.

Consider a transcript in which an AI assistant says it will retrieve a customer record. That establishes what the assistant expressed, not necessarily what the underlying system permitted or executed. A successful API response can establish that a request completed, but it may not reveal whether the response contained personal data. A permissions snapshot taken today may show that an account has access, but not whether that same permission existed during the incident.

The investigation therefore needs to connect four classes of evidence.

1. Action evidence: what did the system do?

This includes requests, API calls, tool invocations, query results, workflow changes and other observable actions. Where available, retain timestamps, request identifiers, destination systems, response status and the identity associated with each operation.

The important distinction is between an attempted action and a completed one. A denied request is not the same as a successful read. A successful read is not the same as a confirmed disclosure.

2. System-state evidence: what was true at that time?

Investigators need the relevant configuration, permissions, service-account roles, integration settings, model or agent version and other dependencies that shaped the system's behavior.

This is where a common investigation shortcut fails. Teams sometimes inspect the current environment and use it to explain an event that occurred days or weeks earlier. But permissions may have been changed, credentials rotated, endpoints disabled or software redeployed since then.

The current state is useful for understanding the environment now. It cannot automatically establish the historical state.

3. Authorization evidence: what was the system allowed to do?

The original business task, approved scope, access policy and actual technical permissions must be examined separately.

A team may have authorized an assistant to summarize a customer case. That does not necessarily mean it was authorized to retrieve every record associated with the customer, export a full dataset or send information to an external service. Conversely, a system may technically permit an action that the business never intended to authorize.

The investigation must establish both the intended boundary and the boundary actually enforced by the system.

4. Decision evidence: what did the organization decide, and why?

The investigation should preserve the decisions made by security, privacy, technology and business owners: what they concluded, which evidence supported the conclusion, what remained unknown, which actions they approved and when those actions were verified.

This record matters because an investigation is not complete merely because the technical team has written a timeline. Someone must decide what the findings mean for the organization, and that decision should be traceable to the evidence available at the time. Learn more about 🔗AI Incident Reviews: How to Turn Recovery Into Better Controls.

Together, these four classes help reconstruct not just a sequence of events, but the conditions under which those events occurred and the reasoning behind the response.

How to investigate an AI incident involving personal data

The following method is designed to help security, privacy, technology and business teams organize an investigation. It is not a substitute for incident-response procedures, legal advice or applicable regulatory directions. The exact response depends on the facts, the systems involved and the organization's obligations.

Step 1: Define the question before collecting everything

Start with the uncertainty that must be resolved. Was a credential exposed? Did an AI agent access a live system? Was personal data retrieved? Was information sent somewhere it should not have gone? Did the activity trigger a consequential business action?

These questions overlap, but they are not interchangeable.

Write down the known trigger, the affected system, the approximate time window and the initial uncertainty. This gives the investigation a defined scope while allowing it to expand when new evidence warrants it.

Without this discipline, teams can spend days gathering large quantities of logs that do not answer the decision they actually need to make.

Step 2: Preserve evidence before the environment changes further

Containment and evidence preservation often need to happen in parallel. An organization should not leave a dangerous integration running simply to collect more logs. Equally, it should not make avoidable changes that destroy the evidence needed to understand the incident.

Preserve relevant application and API logs, identity events, cloud audit records, agent or model traces where available, configuration versions, permission changes and related workflow records. Record when each item was collected, where it came from and whether it was transformed during handling.

If a credential may have been exposed, follow the incident-response process for revoking or rotating it and checking for other copies. 🔗CERT-In's October 2026 advisory specifically recommends auditing exposed credentials, including repository history and CI/CD variables, rotating exposed credentials and verifying remediation.

Do not assume that preserving a model transcript is equivalent to preserving the system's activity. They serve different evidential purposes.

Step 3: Reconstruct the timeline across systems

Build one timeline that connects events from the relevant sources. Use consistent time zones, preserve the original timestamps and record any clock discrepancies that could affect interpretation. For each important event, capture:

• The timestamp and source record.
• The identity or service account involved.
• The request or action attempted.
• The system response or observed outcome.
• The related configuration or permission state, if established.
• The confidence level and any unresolved ambiguity.

For example, a permission change at 10:02, an API request at 10:07 and a workflow update at 10:08 may appear related. But proximity in time does not prove causation. The investigator needs request identifiers, system relationships or other evidence that supports the connection.

A useful timeline distinguishes confirmed events, plausible connections and unanswered questions rather than presenting every correlation as fact.

Step 4: Establish what happened to personal data

This is where a technical timeline becomes a DPDP-relevant assessment.

Identify the categories of personal data that may have been involved, the systems that held them, and the evidence showing whether the data was queried, retrieved, included in a response, transferred or used in a subsequent action. Establish the likely scope of affected individuals where the records support it.

Do not infer that every record available to an account was accessed. Do not infer that a successful query resulted in disclosure to an unauthorized recipient. Equally, do not treat the absence of a record in one logging system as proof that an action did not occur.

If the evidence cannot establish the scope, document the gap explicitly. The team may need to consult additional systems, obtain provider information or investigate whether relevant logs were unavailable or incomplete.

The outcome should be a clear account of what is known about personal data, what is reasonably supported but not confirmed, and what remains unknown.

Step 5: Assess the facts against the applicable obligations

Once the facts are sufficiently established, the appropriate privacy, legal and incident-response owners can assess the event against the relevant requirements and internal policies.

Under the DPDP framework, the organization should not collapse technical access, unauthorized processing and personal data breach notification into one generic label. The applicable definitions, commencement status, circumstances of the event and relevant obligations must be considered.

The DPDP Rules (🔗Official government overview) provide for notification to affected individuals without delay in the event of a personal data breach, with information about what happened, potential consequences and steps taken. The precise legal assessment and required actions should be made by the responsible team using the current, applicable provisions and the facts of the incident.

Keep the reasoning behind the decision. If the organization concludes that a particular notification obligation applies, the record should show the facts and assessment supporting that conclusion. If the available evidence is insufficient to reach a conclusion, record that uncertainty and the next steps needed to resolve it.

A defensible decision is not one that pretends uncertainty never existed. It is one that shows how the organization handled uncertainty responsibly.

Step 6: Verify remediation and revisit the original assumptions

Closing the incident should not mean closing the ticket as soon as the immediate symptom disappears. 

If the cause involved an exposed credential, verify that it was rotated and that other copies were addressed. If a role granted excessive access, test whether the revised permissions enforce the intended boundary. If a dormant endpoint was exposed, confirm that it is no longer reachable through the relevant paths. If the problem involved an AI integration, reassess what the agent can access and what actions its identity can perform.

🔗CERT-In advisory warns that incomplete remediation in the incidents it observed was followed by renewed attacks within days, at greater scale. Its advisory recommends retesting after remediation and maintaining robust records of agent activity. That is a concrete reason to verify fixes rather than relying solely on a change request marked complete.

Finally, revisit the assumptions that allowed the incident to occur. Was the agent's intended scope documented? Did technical permissions match it? Would the organization have detected the activity without an external disclosure? Could the team have reconstructed the same event from its own records?

The answers should influence the controls, approvals and evidence requirements for future deployments.

A practical AI incident investigation record

A useful investigation record does not need to be a long narrative written after everyone has moved on to the next priority. It needs to preserve the facts and decisions that another responsible person would need to review the case.

Use the following record fields and what to capture as a starting point:

1. Incident and scope: Trigger, affected systems, initial time window and investigation owner
2. Event timeline: Timestamped events with source references and observed outcomes
3. AI system context: Relevant model or agent version, integration, tools and configuration
4. Identity and permissions: Service identity, granted roles, approved scope and historical changes
5. Personal data assessment: Data categories, records potentially involved, observed access or transfer and remaining uncertainty
6. Decision record: Findings, evidence supporting them, applicable assessment and accountable decision-maker
7. Response actions: Containment, credential changes, access restrictions and communications, with owners and timestamps
8. Verification: Tests performed, results, remaining exposure and evidence that remediation worked
9. Outstanding questions: Missing records, unresolved facts, follow-up owner and next review point

Each important conclusion should point back to its supporting evidence. A field marked “resolved” is less useful than a field that explains what was verified, by whom and against which record.

Where evidence is missing, record that fact rather than filling the gap with an assumption. Where a conclusion changes, preserve the earlier decision and the new evidence that prompted the change. This creates a reviewable history instead of a polished final account that conceals how the understanding evolved.

From incident investigation to continuous AI assurance

Incident investigation looks backwards to establish what happened. Continuous AI assurance connects that history to the decisions and changes that follow.

For example, after investigating an AI assistant that accessed customer records through an overly permissive integration, the organization might need to connect the original approval, the access policy, the configuration change, the investigation findings, the remediation decision and the verification result. When the integration changes again, the team should be able to identify which previous assumptions and approvals may need to be revisited.

That is the operational distinction between having records and being able to rely on them. A transcript may explain what an assistant said. An audit log may establish that an event occurred. A ticket may show that someone changed a permission. Assurance requires the organization to connect those records to the question that matters: 

What did we approve, what changed, what does the evidence establish, and what must we reconsider now?

This is the problem KlaritiQ is being built to address through Continuous AI Assurance: connecting changes, evidence, ownership, decisions and follow-up so that organizations can maintain a reviewable account of their AI systems over time. It does not replace security monitoring, forensic investigation, legal assessment or incident-response teams. It helps make the decisions and evidence around AI initiatives easier to trace and reassess.

When an organization is asked to explain an AI incident involving personal data, it should not have to reconstruct its entire governance history from disconnected tickets, logs, emails and memories. The evidence will not answer every question automatically. But it should make clear which questions can be answered, which cannot, who is accountable for the next decision and what must happen before the matter can be considered resolved.

That is what turns incident investigation from a one-time exercise into a capability the organization can improve with every change.