AI Agent Forensics

What does AI agent forensics examine?

An AI agent can carry out a task through connected tools: editing a document, running a command, querying a service, or handing work to another agent. Each step may leave records in a different place. A conversation can explain the request; the affected system can help establish the result.

This guide covers the examination of those relationships, sometimes described as agentic AI forensics. Start with a specific question, such as whether a file was changed or a message was sent. The AI Agent Forensics field reference sets out the broader scope and its relationships to other forensic work.

When is an agent examination useful?

• A file or account changed during an automated task, and the origin of the change is disputed.
• An assistant reported that it completed an action, but the result is missing or different.
• A task used a connected service or delegated work, leaving an incomplete visible history.
• A suspected prompt injection may have redirected an agent from the requested task.
• An incident review needs to establish which actions occurred before and after a task was stopped.

Start with the task and its authority

Record the initiating request, task and session identifiers, runtime version, available tools, and relevant configuration. Identify the accounts used and the permissions in effect at the time. Separate a tool being available from permission to use it for a particular purpose.

Preserve recorded approvals, denials, and later changes in authority. An approval to draft a message may differ from an approval to send it. Examine the scope of each recorded instruction rather than inferring permission from the final outcome. Define the systems and time interval covered by the authorized collection.

What evidence should you preserve?

Collect the original records where available, with their source, collection method, identifiers, timestamps, and integrity information. Retention varies by product and configuration. Use the preservation methods to plan collection before opening applications or rerunning tasks that could alter their state.

A plan, a request, and a result are different evidence

Label the state supported by each source. Confirmation concerns a specific effect: a file existing, a service accepting a job, and a recipient receiving a message are different propositions.

Follow each tool call into the affected system

Keep the request and result together, including identifiers, arguments, errors, and retries. For a command, seek execution records and resulting files. For a browser action, distinguish viewing a page from submitting a form. For an API, compare the response with the destination service’s record of the operation.

The MCP tools specification, revision 2025-11-25, describes tool names, inputs, results, and error handling. These semantics help interpret a captured exchange. They do not establish which records a particular implementation retained or whether a requested external change became durable.

Keep parent agents and delegated work connected

An initiating agent may hand a task to another agent or process. Retain the parent-child identifiers, assigned scope, permissions, and returned result. Follow the delegated task to its own tool records and external effects. A parent’s final summary may omit failed attempts or intermediate changes.

Use a graph when tasks branch or overlap. A simple transcript can flatten relationships that matter: one agent requests a change, another makes it, and a third reports it. Missing links should remain visible rather than being filled with assumptions.

Build a timeline that another examiner can check

• Link the initiating task to its tool requests using preserved identifiers.
• Match those requests to process, browser, filesystem, or service records.
• Compare object identifiers, file bytes, versions, and before-and-after state where available.
• Retain raw timestamps. Verify their clock, timezone, units, and event meaning before normalizing them.
• Reference the source supporting each relationship and record conflicting evidence or alternative explanations.

Check what happened after the agent stopped

A cancelled conversation does not establish that all external work stopped. A service may already have accepted a job, a process may still be running, or an earlier change may remain. Examine completion, cancellation, retry, and rollback records where available. Extend the collection interval to cover relevant later activity.

Treat each retry as a separate event until records establish its relationship to earlier attempts. A repeated request might fail, update an existing object, or create another object. Report the behavior observed in the examined system.

Investigating a suspected prompt injection

Prompt injection can involve instructions supplied directly or embedded in external material such as a page or document. OWASP’s LLM01:2025 reference describes these direct and indirect forms. In an examination, preserve the suspected material, its version, and records showing whether it was retrieved or included in available context.

Compare the authorized task with the subsequent tool requests and system effects. Suspicious wording alone does not establish that it caused an action. Record the proposed link, the supporting evidence, and other explanations, including legitimate instructions or a configuration error.

Example: did the agent send the report?

Hypothetical educational example. An assistant says, “I sent the report.” Its tool record contains a send request, and the service response says “accepted.” A separately acquired service audit record shows the matching job was queued. No delivery record was acquired.

The supported finding is that the service accepted the matching request and queued it. Delivery to the recipient remains unresolved. The assistant’s statement records its claim; it does not close the gap between acceptance and delivery. A delivery event or recipient-side evidence could address a further question, while opening or reading the message would require its own support.

Report the action, its evidence, and its limits

For each consequential action, identify the task, acting agent, tool request, account context, observed external effect, and supporting sources. State whether it was proposed, attempted, reported, or corroborated. Include the collection interval, validation performed, missing records, and unresolved relationships.

Account attribution and human control require separate analysis. A credential can connect an operation to an account without identifying the person controlling it. Protect secret values in public reports while preserving the original evidence appropriately. Use the Synthetic Forensics Investigation Framework to organize the work and the confidence vocabulary to describe support.

Common questions about AI agent forensics

Continue the examination

Use Interaction Forensics for message relationships and context, AI Artifact Forensics for retained application records, and Provenance Forensics for origin and derivation claims. The hypothetical filesystem case follows a tool request to acquired file evidence.