
Digital forensics has always required caution when moving from an artifact to a conclusion. A login does not prove who sat at the keyboard. An account associated with an action does not establish intent. A timestamp records when something happened, not why.
AI agents introduce a further complication. The person associated with an account can initiate a task without performing the action that causes the incident. The instruction and the consequential act are no longer the same event. Several automated steps may separate them.
Consider a specific case. An employee at Gamack Financial Group, a fictional financial services organization, asks an approved internal AI agent to prepare an audit package for an external auditor and send it. The agent searches corporate records, retrieves customer information, builds a spreadsheet, resolves what it treats as the auditor's address, and sends the file. The address is wrong. 1,847 customer records leave the organization.
The first incident report reads: "Employee used ChatGPT to exfiltrate confidential customer information." It sounds plausible. It also collapses an observation, an attribution, a claim of causation, and a claim of intent into one sentence, before any of the four has been examined.
This article works through that incident using the Zemi Method, Version 1.2. The method does not replace established forensic procedure. NIST SP 800-86, SWGDE examination guidance, vendor acquisition guidance, and validated tools remain necessary for identifying, preserving, acquiring, examining, and analyzing evidence. Zemi governs the reasoning between the evidence collected and the finding an examiner is prepared to defend.
The Incident
Gamack uses ChatGPT Enterprise and an approved internal AI agent. The agent runs inside the Enterprise workspace and executes under the authenticated identity of the employee who invokes it. Through approved apps, and subject to the access granted to them, it can reach SharePoint, an internal customer database, corporate email through a mail app operating under a defined sending identity, and approved external web resources. Employees in commercial claims use it for routine work.
Gamack Financial Group and its implementation are fictional. The case combines capabilities that current ChatGPT Workspace Agents and ChatGPT apps can support, including connected data sources, external actions, different authentication models, and configurable approval requirements. It does not represent a claim about any specific organization's deployment.
At 09:15 on a Monday, Gamack's Data Loss Prevention system raises an alert. A spreadsheet containing 1,847 customer records has been transmitted to an external address.
The alert originates from the outbound mail path. It identifies a message, its payload, and its sending context. It does not, on its own, identify a ChatGPT session. The security team correlates the outbound message to an authenticated ChatGPT session belonging to Alex Morgan, an employee in commercial claims, using the mail connector's audit trail and the identifiers linking the connector action to the originating agent invocation. That correlation is an investigative step, not a single feature the platform exposes.
The incident is escalated with that framing intact. The investigation has barely started.
Phase 0: Authority and Scope
The first Zemi phase occurs before any substantive analysis. Gamack's Legal department and CISO authorize an internal investigation, and the original question is set aside. Rather than asking whether Alex exfiltrated customer information using ChatGPT, the investigation asks a broader and more neutral question:
What sequence of human and AI-mediated actions resulted in the disclosure of customer information, and what does the available evidence support regarding execution, authorization, control, intent, and accountability?
Scope is bounded to the relevant period and systems: ChatGPT Enterprise, identity records, Alex's corporate endpoint, SharePoint, the customer database, the email environment, DLP telemetry, and the infrastructure supporting the agent's tools. Unrelated employee conversations and unrelated corporate information are excluded.
This step looks administrative. It establishes something investigators sometimes assume. Technical access to evidence is not the same as authority to examine it.
Phase 1: Frame the Claim
The incident description now becomes what it should have been from the start: a hypothesis, held alongside its competitors.
| Hypothesis | Explanation |
|---|---|
| H1: Deliberate human disclosure | Alex instructed the agent to send confidential information to the unauthorized recipient. |
| H2: Human error | Alex supplied or selected the incorrect destination inadvertently. |
| H3: Agent-selection error | Alex instructed the agent to send the package to the legitimate auditor, and the agent selected a different recipient. |
| H4: Retrieval or configuration error | The agent obtained incorrect recipient information from an enterprise source available to it. |
| H5: Account compromise | Someone other than Alex operated the authenticated session. |
These five explanations compete to account for the disclosure, and each is testable against the evidence. One further concern runs across all of them without being a rival cause: whether the logs and the user-visible conversation completely represent the consequential execution. Representation completeness is a standing evidentiary condition, examined during corroboration, not a sixth hypothesis.
Zemi requires a breaking condition, a statement of what would falsify the leading claim. For deliberate disclosure it is straightforward. Evidence that Alex did not provide or select the unauthorized destination would materially weaken the claim that he deliberately disclosed the information to that recipient.
The investigation now holds a theory capable of being disproved, which changes how the evidence is approached.
Phase 2: Preserve the Evidence
Technical collection follows applicable forensic procedure and platform guidance. The reasoning framework does not displace either.
Evidence is preserved from the OpenAI environment through the Compliance Platform, which provides workspace logs and metadata through immutable, append-only events and complementary stateful records. Available categories include conversation messages, authentication, audit, and app logs. All app calls are logged through the Compliance Logs Platform. Two constraints govern this collection and shape everything downstream. (OpenAI Compliance Platform, Apps in ChatGPT)
The first is time. The Compliance Logs Platform retains events for 30 days. Longer retention requires continuous export to the organization's own store. Preservation has to begin at once. Delay converts available evidence into unavailable evidence. (OpenAI Compliance Platform)
The second is fidelity. Compliance logs can establish that an app was invoked and an action occurred. Whether they identify the specific document returned or exact recipient resolved depends on the app, action, event type, and organization's implementation. Where the event record lacks that detail, the platform record cannot carry a material finding alone. It has to be corroborated against the source systems the agent touched.
Enterprise evidence is therefore collected independently from Microsoft Entra ID sign-in and audit logs, endpoint telemetry, browser artifacts, the SharePoint unified audit log of file access, the customer database access logs, the corporate mail environment including message tracking and transport logs, DLP incident records and policy configuration, and relevant network and security telemetry.
The agent's execution context is documented where available: its tools, permissions, app configuration, authentication model, approval requirements, instructions, and information sources. Current Workspace Agents can use end-user or agent-owned authentication, and their builders can configure approval behaviour for write actions. Those controls are part of the incident evidence, not background detail. (ChatGPT Workspace Agents)
Reconstructing AI Action Provenance
AI Action Provenance is the ordered account of what the agent did, step by step, from instruction to external effect. The evidence supports the following sequence.
09:14:02. Alex instructs the agent to review claims associated with the Orion account, identify inconsistencies, prepare a spreadsheet for the external auditor, and send the completed package.
09:14:07. The agent searches the claims repository.
09:14:13. SharePoint returns relevant documents.
09:14:31. The agent queries the customer database.
09:14:45. Customer records are returned.
09:15:12. The spreadsheet is generated.
09:15:19. The agent resolves an auditor destination.
09:15:24. The email capability is invoked.
09:15:27. The corporate mail system accepts the message.
09:15:29. DLP detects protected customer information.
09:15:33. The message is released into the external delivery path.
09:15:36. The external domain's mail infrastructure accepts delivery.
The sequence establishes order. It does not yet establish responsibility. One step carries more weight than the rest and depends on the connector-level detail flagged in Phase 2. The claim that the agent resolved the destination from a specific SharePoint document at 09:15:19 cannot rest on the agent's own tool record. It is corroborated against the SharePoint unified audit log, which independently records access to an obsolete auditor-contact document at that time under the agent's connector identity. The AI's account of what it retrieved and the source system's account of what was accessed are then two records of different lineage describing the same retrieval.
Control Provenance
Control Provenance asks a different question from the sequence of events. It asks who or what controlled each consequential part of the process.
| Component | Control |
|---|---|
| Initial business objective | Alex |
| Authenticated account | Alex's account |
| Agent configuration | AI platform team |
| SharePoint permissions | Enterprise access controls |
| Database access | Approved connector or service account |
| Email capability | Agent configuration |
| Recipient resolution | Agent workflow |
| Final approval before transmission | None |
| Outbound DLP enforcement | Detective (monitor) mode |
The last two rows matter. The agent could perform an externally consequential action without requiring Alex to approve the resolved recipient before transmission. The DLP control that caught the payload was recording rather than blocking. Neither fact assigns responsibility. Each identifies a control that failed to interrupt the sequence, and each points at a different place in the design.
Phase 3: Corroborate
The OpenAI evidence indicates that the email tool completed. That establishes tool completion, not transmission. The corporate mail system independently records acceptance of the message at 09:15:27, and DLP independently detects the protected data two seconds later. Transmission is therefore corroborated across systems whose records have materially different origins.
Acceptance by Gamack's own mail system establishes only that the message entered the outbound path. Whether it left the organization or reached anything at the far end is a separate question. The transport records show that the remote server accepted delivery. Microsoft documents that Exchange Online message trace exposes delivery events, destination IP information, and applied DLP rules. (Microsoft Exchange Online message trace)
That is the limit of what the evidence shows. Whether a person at the receiving domain opened the spreadsheet is not visible in Gamack's records and lies outside its reach. The question is recorded as undetermined rather than resolved in either direction. Had the transport logs instead shown a non-delivery response from an unregistered or defunct domain, the reading would change. The unauthorized transmission attempt would still be established, but successful delivery to external infrastructure would not be. Whether the data crossed Gamack's controlled mail boundary would depend on the transport record. The delivery evidence is what separates those outcomes, which is why it is examined rather than inferred from the fact that a send was invoked.
This phase also exposes a trap specific to cloud and AI investigations. Three records inside the AI platform may describe the same tool invocation but derive from one event pipeline. That is one source recorded three times, not three independent sources. Artifact count matters less than lineage. The SharePoint retrieval and message delivery are therefore corroborated against systems outside the AI platform.
Representation Completeness
The user-visible conversation contains a single closing line: "I've prepared the audit package and sent it to the auditor." Viewed alone, that representation tells a clean story in which Alex asked, the agent complied, and the data was sent.
The execution records, corroborated against the SharePoint audit log, tell a fuller one. During recipient resolution the agent searched an internal SharePoint repository for the Orion auditor's contact information and returned an obsolete document created in 2024. That document held audit-review@orion-consulting.example. The organization's current vendor record held audit-review@orionassurance.example. The agent selected the address from the obsolete document. The unauthorized address never appears in Alex's instruction.
The visible conversation was an incomplete representation of the consequential execution. That gap between what the user saw and what the system did is the distinction that reorients the investigation.
Phase 4: Analyze
The original allegation collapses several propositions into one. Separating them is the analytical work.
Alex's account initiated the session, supported by the identity and endpoint evidence. Alex initiated the task, instructing the agent to prepare information for an external auditor and send it. Alex did not select the unauthorized recipient, which was retrieved during execution from an obsolete document and corroborated by the SharePoint audit log. The agent invoked the email capability. Information left the organization, established by the mail transport records and the DLP payload detection. Delivery to the external domain's infrastructure is established, while access by a specific person is not. Alex was authorized to prepare the information for the stated business purpose. Transmission to this recipient was not authorized by any evidence. Intent to send the information to the unauthorized recipient is not established.
The pattern across these findings is the core discipline of an AI-mediated investigation. Identity is not control, control is not execution, execution is not intent, and intent is not accountability. Each proposition requires its own evidentiary support, and the allegation failed because it borrowed support from one link to cover the next.
Test the Alternative Explanations
Account compromise is materially weakened. Authentication, endpoint, and session evidence give no indication that another person controlled the session.
Human entry of the address is materially weakened. The unauthorized address does not appear in the human instruction.
Hallucination is refuted. The address existed in an obsolete SharePoint document and was retrieved during execution, corroborated by the source system's own audit log. Labeling every incorrect AI result a hallucination would obscure what happened here.
Agent selection of outdated organizational information is supported by the evidence, as is the finding that the workflow permitted an external action without human confirmation and that the outbound control was positioned to record rather than prevent it.
The deliberate-disclosure hypothesis deserves explicit treatment, because a defensible exoneration depends on having looked for the evidence that would convict. Deliberate disclosure would be supported by a prior instruction containing the unauthorized address, a manual override of a recipient the agent had suggested, an edit to the resolved address before sending, or communications indicating a motive to route the data to that destination. The investigation examined the conversation history, the connector records, the endpoint, and the mail environment for each of these. None was present. The hypothesis is not merely unproven. The specific evidence that would support it was sought in the places it would appear and did not exist.
Phase 5: Adjudicate
Zemi does not force every open question into a probability. The evidence is classified by what the investigation establishes.
| Classification | Adjudicated propositions |
|---|---|
| Known | Alex initiated the task. The agent retrieved customer information and an obsolete auditor contact, selected that contact, and invoked the email capability. The SharePoint record corroborates the retrieval. The mail system transmitted the spreadsheet, and the external infrastructure accepted delivery. DLP operated in detective mode. The workflow required no human confirmation of the recipient. |
| Assumed | Alex retained control of the authenticated session throughout the interaction. Identity and endpoint evidence support this strongly but do not establish continuous physical control. |
| Undetermined | Whether a person at the receiving domain accessed the records. Whether Alex noticed the incorrect recipient. Whether another configuration would have produced the same action. Whether the agent would have selected the correct recipient without the obsolete document. |
Leaving these unresolved is not a failure of the investigation. Claiming to know their answers without evidence would be.
The Same Case With Weaker Evidence
The reconstruction worked because SharePoint auditing was enabled, transport records documented delivery, and app events existed. What happens when that telemetry is absent?
Suppose the connector records were thin and SharePoint file-access auditing had been disabled. The retrieval of the obsolete document could no longer be corroborated against a second system. The provenance of the unauthorized address would move from Known to Undetermined, because the agent's own account would be the only record of where the address came from. The finding on H4 would weaken accordingly. Without the transport logs, delivery to the external domain would drop to Undetermined as well, leaving only that the message entered the outbound path.
The finding does not collapse. It narrows. More propositions move to Undetermined, and the accountability statement contracts to what remains supported. A method that produces the same confident conclusion regardless of evidence quality is not assessing evidence. The Zemi finding loses scope as the record thins instead of supplying missing links from assumption.
Phase 6: Report
The defensible finding can now be set against the original allegation.
Initial allegation: "Employee used ChatGPT to exfiltrate confidential customer information."
Finding after examination: The evidence supports that Alex Morgan initiated an authorized task to prepare and send information to an external auditor. The consequential transmission was executed through the organization's AI-mediated workflow. Agent records, corroborated by the SharePoint audit log, indicate that the unauthorized recipient address was retrieved from an obsolete internal document and selected during agent execution. Mail transport records establish that the message was delivered to and accepted by the external domain's infrastructure. No evidence established that Alex supplied or deliberately selected that address, or that any person at the receiving domain accessed the records. The workflow did not require human confirmation of the resolved recipient before transmission, and the outbound DLP control was operating in detective mode.
The accountability finding is stated separately. The evidence supports attributing task initiation to Alex and technical execution of the disclosure to the AI-mediated workflow. It does not support attributing deliberate disclosure to Alex. The incident identifies two control weaknesses: permitting an AI agent to perform an externally consequential action using dynamically retrieved recipient information without human confirmation, and operating outbound data loss prevention in a mode that recorded rather than prevented the transmission of a regulated dataset.
An investigation exists to inform a decision, so the finding states what it requires. The organization needs to gate external recipient resolution behind human confirmation for consequential actions, move outbound DLP from detective to preventive enforcement for regulated data, and close the source of the error itself by remediating the obsolete document and the stale vendor record that the agent was able to retrieve. The finding is narrower than the allegation and better supported, and it points at the controls that produced the outcome rather than at the employee who started the task.
The Defensibility Check
Before release, the finding has to survive the Zemi Method's standing defensibility check:
- Was authority established and the claim properly bounded?
- Were competing explanations and a breaking condition defined?
- Can each material proposition be traced to its source?
- Were completeness and evidentiary-lineage independence tested?
- Were transmission, delivery, and access kept separate?
- Was the human-visible representation compared with the underlying execution?
- Were AI Action Provenance and Control Provenance reconstructed?
- Were execution, authorization, intent, and accountability kept distinct?
- Were contrary evidence, assumptions, and unresolved questions made visible?
- Could another competent examiner reconstruct and challenge the finding?
- Did a human adjudicate the result?
If a material control fails, the answer is not to explain it away. The finding returns to the phase where the weakness occurred.
Where NIST and Other Forensic Standards Fit
The Zemi Method is not an acquisition tool. It does not tell an examiner how to parse an OpenAI artifact, acquire an endpoint, export cloud logs, or validate a forensic image. Those activities remain governed by forensic standards, validated procedures, platform documentation, and technical expertise. NIST SP 800-86 describes collection, examination, analysis, and reporting. SWGDE requires conclusions to be supported by data, replicable, defensible, and documented with their basis. (NIST SP 800-86, SWGDE Best Practices for Computer Forensic Examinations, SWGDE Requirements for Report Writing)
Reasoning and interpretation are not new concerns. Established forensic process already contains an analysis phase. Zemi makes a particular reasoning problem explicit: execution, authorization, control, intent, and accountability must be tested separately across an agentic chain before a finding is released. Better logging does not, by itself, produce better findings.
The Distance Problem
AI does not make established forensic principles obsolete. It lengthens the distance between an observable artifact and the human conclusion an investigator is asked to reach. A conventional investigation already moves through several layers, from person to account to application to system to artifact. An agentic system extends the chain: person, identity, instruction, model, agent, tool, external system, action, artifact. An AI-assisted examination can add another AI on the analytical side, from artifact to forensic tool to AI analysis to examiner to finding. Every added layer is another place where an inference can quietly harden into a fact.
That is why provenance alone is insufficient, and why this investigation spent as much effort on control, representation, independence, and completeness as on the sequence of events. The platforms are becoming more capable of producing useful artifacts. Enterprise compliance records, agent traces, tool calls, identity telemetry, connector records, and downstream logs can reconstruct AI-mediated activity in detail. None of that adjudicates responsibility. A log can establish that an account authenticated, that an agent invoked a tool, or that a message was delivered. No log establishes, on its own, what the human intended.
The volume of AI evidence is growing while the chain between human instruction and machine action grows longer and more autonomous. The task for digital forensics is not to collect more of it. It is to determine what each artifact can prove, and to keep the finding inside that boundary. That is the reasoning problem the Zemi Method is built to enforce.
Appendix: Mapping Questions to Evidence
A practitioner can run this investigation by working from the question to the artifact that answers it and the system that holds it. Compliance-platform records establish that an action occurred. Source-system records establish what the action touched. Material findings rest on both.
| Investigative question | Artifact | Source system |
|---|---|---|
| Did the human initiate the task? | Instruction text | ChatGPT conversation log |
| Did the human select the recipient? | Instruction text and resolved recipient value | Conversation log, corroborated by connector and SharePoint audit records |
| What did the agent retrieve? | Tool and connector invocation records | Compliance logs, corroborated by the SharePoint unified audit log |
| Which recipient did the agent resolve, and from where? | Recipient resolution record and document-access event | Connector logs and SharePoint audit log |
| Did the named user control the session? | Authentication and sign-in events | Entra ID sign-in logs and endpoint telemetry |
| Did the message leave the organization? | Message tracking record | Exchange Online message trace |
| Was the message delivered to the external domain? | Delivery status or non-delivery response | Mail transport logs |
| Did the payload contain regulated data? | DLP incident record | DLP system |
| Was human confirmation required before sending? | Approval configuration | Agent and connector configuration |
| Was outbound DLP preventive or detective? | Policy configuration | DLP system |