The agent’s version of events
An agent’s log can be complete and still prove nothing about what changed in the systems it touched.

After an agent incident, someone has to say what the agent did. A record on the agent’s side may show the action selected and the request sent. It cannot by itself establish how another system handled that request or what changed there. For an APRA-regulated entity, the distinction matters whenever agent activity becomes an operational risk incident or near miss that must be identified, escalated, recorded and addressed in a timely manner.
An agent-side record has two limits
Two limits apply to any record on the agent’s side: who controlled it, and what its producer could observe.
Some records are written by the agent. Others come from its framework, sandbox or a monitor watching it. Each has different controls, but none can establish a change in another system unless it was generated or preserved beyond the agent’s control.
Control is only half the problem. A well-preserved record still covers what its producer could observe. It may be complete within that scope and silent about events elsewhere.
Trade finance has long separated a document from the performance it describes. Under a letter of credit, the seller presents a set of documents to a bank. Article 5 of UCP 600 states the bank’s task: “Banks deal with documents and not with goods, services or performance to which the documents may relate.”
The bank examines whether the documents comply. It does not establish whether the goods were shipped. Nobody at the bank has seen the ship.
Other arrangements cover inspection, insurance and remedies against a seller who shipped nothing. The error begins when documentary conformity is treated as proof of the underlying performance. An agent’s log deserves the same reading discipline.
Four questions sit behind every agent action
Establishing what an agent did requires four separate questions, each answered by a record with a different field of view.
Figure 1
No single record answers all four questions.
| Stage | Question answered | Evidence source | Does not establish |
|---|---|---|---|
| Intention | What action did the agent select? | The agent or its framework | That a request left the agent’s environment |
| Dispatch | What request left the agent’s environment? | The sending system or an outbound intermediary | How the receiving system handled it |
| Receipt | How did the receiving system handle the request? | The receiving system | That the requested change occurred |
| Effect | What changed in the receiving system? | The changed system or its own records | Whether the change persisted |
Only intention sits squarely within the agent’s own field of view. The other questions depend on records created elsewhere. A receiving system may accept a request without completing the requested change, so evidence of effect has to come from the resulting state.
Hugging Face compared attempts with receiving-system records
Hugging Face used that distinction in its published reconstruction. It recovered some logs from the external sandbox where the agent held administrator rights, then correlated those logs with records from its own platform. The incident’s full sequence, with sources, is in Arkna’s Anatomy of an agent escape.
One reported action created a software workload with elevated access to the underlying host system. The resulting workload existed in Hugging Face’s computing environment, so evidence of that effect lived there rather than in the agent’s account of the request.
A separate route ended at receipt. The agent tried to change the cloud environment using temporary credentials it had replayed. Hugging Face reports that the receiving system denied every attempted change under the permissions attached to that role. The denial establishes what happened on that route, not what happened elsewhere.
The agent-side logs contained copies of the replies the agent received. A copy retained only in a record under the agent’s control is not independent confirmation. Hugging Face could compare attempted activity with observations in its own systems because it held both records.
The receiving system’s record also has a limit. It may show acceptance without showing the resulting state, and it may have gaps or integrity problems of its own. No record should be asked to establish more than its producer could observe.
The missing record can be named before an incident
For every system an agent can reach, two records matter: how that system handled the request, and what state followed. They may be kept by different teams, under different controls, for different periods.
If either answer exists only in a record the agent controlled, the organisation holds evidence of the attempt rather than the effect. If producing the answer requires a reconstruction project, it cannot yet be read directly from the retained record.
An institution can therefore identify which part of an incident account already exists, which party owns it, and which part would have to be rebuilt under pressure.
Primary evidence register
- S01ICC, Uniform Customs and Practice for Documentary Credits (UCP 600, 2007)Rule · Article 5, documents rather than goods, services or performance
- S02Hugging Face, Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident (27 July 2026)Primary · the reconstruction and correlation method, administrator access on the sandbox, the reported effect and the scoped denial
- S03APRA, Prudential Standard CPS 230 Operational Risk ManagementRegulation · paragraph 32, incidents and near misses identified, escalated, recorded and addressed in a timely manner