One agent incident needs two records: disclosure and reconstruction

The UK is asking how incidents involving autonomous agents and near misses should be identified and reported. The government says these incidents may unfold faster and more broadly than existing response arrangements anticipate, but its announcement describes work under consideration rather than a settled reporting regime (GOV.UK).

At the same time, the Information Commissioner’s Office has opened a consultation through 20 November 2026 to inform future agentic-AI data-protection guidance. Its questions span security, transparency, accountability, automated decision-making, fairness, purpose limitations, and lawfulness of processing (ICO). Those questions establish the consultation’s scope, not final obligations.

Operators therefore face a practical tension before the policy shape is settled: preserve enough evidence to understand an agent incident, while controlling what leaves the investigation boundary.

The reporting object and the reconstruction object serve different jobs

Current security research proposes agent-specific reporting elements that include memory access, actual and potential autonomy, tool use, data provenance, reads and writes, and trajectory records. The same paper identifies confidentiality leakage and attacks on reporting infrastructure as risks (research paper).

That combination informs our operating view: one incident can produce two linked records.

The disclosure record is a bounded account prepared for an authorized recipient. It identifies the event, affected system boundary, known consequences, response state, evidence contact, and references to protected material. Its purpose is to communicate the incident without automatically copying the full technical history.

The reconstruction record is the protected evidence set used to investigate what the agent encountered and did. Depending on the event and available instrumentation, it may contain memory access, tool calls, provenance, reads, writes, autonomy state, and trajectory material. These fields come from the research proposal; their inclusion in a particular record is an operator decision, not an announced UK requirement.

The split is about exposure control, not omission. A short disclosure that cannot lead an authorized investigator to the underlying evidence is too weak. A disclosure that embeds every prompt, retrieved object, tool response, and credential-bearing trace may reproduce the confidentiality risk the investigation is meant to contain.

A field map for the two records

We propose assigning each field to disclosure, protected reconstruction, or both before an incident occurs:

Field	Disclosure record	Protected reconstruction	Operating boundary
Incident identifier	Yes	Yes	Use the same stable identifier in both records.
Detection and event times	Yes	Yes	Preserve the source clock and timezone in reconstruction.
System and configuration identity	Summary	Full version detail	Keep the disclosed description sufficient to identify the affected boundary.
Known and potential impact	Yes	Supporting analysis	Mark preliminary assessments as preliminary.
Agent autonomy	Bounded description	Actual and potential authority detail	Separate configured authority from authority exercised.
Tool use	Relevant tools or classes	Ordered calls, inputs, outputs, and errors when retained	Do not place sensitive payloads in the disclosure by default.
Memory access	Presence and relevance	Accessed stores, operations, and retained provenance when available	Treat memory contents as protected evidence.
Data provenance	Source classes	Object-level lineage when available	Keep unresolved provenance visible as a gap.
Reads and writes	Consequence-level summary	Ordered operations and results when available	Distinguish attempted, accepted, rejected, and uncertain operations.
Agent trajectory	Reference or bounded summary	Retained trajectory material	Restrict access according to the content it contains.
Containment and recovery	Current state	Commands, approvals, results, and verification evidence	Do not describe containment as complete while verification remains open.
Near-miss status	Yes	Counterfactual path and prevented action	Record why the event did not become an incident.
Evidence owner	Yes	Yes	Name the role accountable for producing and preserving each record.
Access boundary	Recipient class	Named authorization policy or equivalent control	Log access separately where the system supports it.

This map is a design proposal. The cited sources do not prescribe these exact fields, placements, or custody rules.

Link the records without collapsing their boundaries

A shared incident identifier provides the join. It does not grant access.

For each record, we would attach four custody attributes: owner, authorized audience, retention decision, and release authority. The disclosure can then point to protected evidence by identifier and custodian instead of duplicating it. If an authorized reviewer needs more detail, the release decision happens at that boundary.

The reconstruction also benefits from an evidence manifest. The manifest can list the artifact type, collection time, source system, integrity reference where one exists, and access classification. This does not prove that every relevant event was captured. It makes the retained set and its gaps inspectable.

That limitation matters for trajectories in particular. A reconstructed sequence may reflect only the events an implementation recorded. Teams can label missing spans, unavailable payloads, clock disagreements, and overwritten state rather than turning partial telemetry into a complete narrative.

Near misses belong in the model

The UK announcement explicitly says the government is considering how AI incidents and near misses should be identified and reported (GOV.UK). It does not yet define the resulting approach.

Our proposed records can accommodate a near miss without pretending harm occurred. The disclosure states the attempted or emerging event, the control or circumstance that prevented escalation, and the remaining uncertainty. The reconstruction preserves the technical path far enough to examine the prevented action, including relevant tool use, reads, writes, memory access, or autonomy state when that evidence exists.

This makes the distinction explicit: an observed incident records realized consequences; a near-miss record describes a path that stopped before those consequences were realized. Where the counterfactual outcome is uncertain, the record can say so.

Prepare the join now

While the UK approaches remain under development, teams can prepare without guessing at final reporting obligations. Choose an incident identifier format, nominate the owner of each record, define the protected evidence boundary, and rehearse producing a concise disclosure from a synthetic agent event.

The rehearsal question is simple: can an authorized reader understand the event and locate the evidence without the disclosure becoming an unrestricted forensic dump?

For teams building agent systems, that join between communication and reconstruction is the useful artifact. It leaves room for future reporting instructions while keeping sensitive technical evidence behind an explicit access decision.