Which stage of an action was actually recorded?
An agent can describe an action before it has the ability or authorization to perform it. A tool request shows a further stage. A returned result shows what the tool reported. Evidence from the destination can show an effect. Preserve these stages as separate observations, even when an interface compresses them into one friendly success message.
This guide explains those distinctions. The existing agent examination guide covers the broader collection and reporting workflow. Neither treats an agent’s account of its own behavior as a complete audit record.
Read each record for the claim it supports
| Evidence or distinction | What it supports | Limit or next question |
|---|---|---|
| Task or planning message | A stated objective or proposed operation. | Does not establish execution. |
| Tool request | A recorded request with available arguments and identifiers. | May be rejected, fail, or be retried. |
| Approval event | An authorization decision for an identified scope. | Does not prove completion or authorization beyond that scope. |
| Tool receipt | The tool’s reported outcome. | May need destination corroboration. |
| Target-system record | A recorded effect or state at the destination. | Still needs an association with the particular request. |
A protocol describes messages, not retention
The MCP Tools specification defines a tool-call interface and result representations for its stated revision. That provides vocabulary for interpreting a compatible record. It does not establish that a particular client saved the full request, that a server retained a result, or that logging captured every operation. Model Context Protocol: Tools, specification 2025-11-25.
Record the implementation and version as well as the protocol revision. An error result, transport timeout, and missing result are different observations. Avoid silently converting any of them into “nothing happened.”
A retry can change the interpretation
Hypothetical example: an agent submits a document upload, receives a timeout, and submits it again. The conversation contains one later success receipt. The first request might have completed before the timeout, or it might never have reached the destination.
Compare available request identifiers, idempotency behavior, destination audit records, and resulting objects. If the destination contains two objects, determine whether their source references distinguish the two requests. If destination history is unavailable, report the recorded retry and leave the number of completed operations unresolved.
What can and cannot be attributed?
Correlated records can support that an identified runtime requested an operation and that a corresponding effect was observed. They can also expose a mismatch between an approval scope and a requested action. The strength of each association depends on the acquired records and their integrity.
The same evidence does not automatically establish a person’s intent, a complete task history, or the identity behind an account. Consider manual actions, shared credentials, delegated tasks, and later state changes where relevant. State the attribution level explicitly: request, runtime, account, configuration, or person.
How the sources support this guide
Source comparison: 2026-10-14. Technical concepts, supporting context, and editorial reasoning are distinguished below.
| Concept | Support | References and limits |
|---|---|---|
| Action-stage distinctions | Editorial interpretation | Model Context Protocol: Tools, specification 2025-11-25; RFC 9110 — HTTP Semantics Task, request, receipt, and destination effect are the project’s analytical distinctions. |
| Tool message semantics | Direct concept | Model Context Protocol: Tools, specification 2025-11-25 MCP 2025-11-25 specifies named calls, structured arguments, result content, and errors; it does not require durable forensic logs. |
| Retries and completion | Supporting context | RFC 9110 — HTTP Semantics; Python — Coroutines and Tasks HTTP idempotency/acceptance and asyncio are concrete examples; the actual tool’s behavior still requires evidence. |
Citation and editorial context
This is an editorial reference. Source checks are separate from independent expert review; no independent reviewer is recorded.
Examples are hypothetical. See the editorial policy, methodology, and correction process.
Shelley, Jesse (ed.). “AI agent forensics: requests, permissions, and observed effects.” Synthetic Forensics, 1.1.0-citation-review-1, 2026-10-14. https://syntheticforensics.org/glossary/terms/ai-agent-forensics/ Accessed: add the date you consulted this page.
Sources & further reading
Source verification checks the official publication and its scope. It is separate from independent technical review of this reference page.
- Model Context Protocol: Tools, specification 2025-11-25
Tool descriptions, calls, and result semantics for the named protocol revision. A protocol definition does not guarantee persistent audit records.
- RFC 9110 — HTTP Semantics
Sections 6, 8, 9.2.2, and 15.3.3 cover messages, representations, idempotency, retries, and accepted requests. HTTP semantics do not guarantee every agent tool has the same behavior.
- Python — Coroutines and Tasks
Dispatch, awaiting, task completion, cancellation, and asynchronous processing in asyncio. Not a universal agent-execution model.
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
IT-oriented forensic process and sources; published 2006. It is not a complete investigative procedure or legal advice.
Canonical reference: https://syntheticforensics.org/glossary/terms/ai-agent-forensics/
Report a technical correction