The agent’s version of events
A response team needs to establish what an agent changed before it can decide what to repair. The July intrusion shows why attempted actions and completed changes need different evidence.

After an agent incident, a response team must decide what to repair. A record that the agent tried to change a system is not enough to establish that the change occurred. Treating every attempt as successful exaggerates the damage; treating an accepted request as completed can hide work that failed later.
The July 2026 intrusion into Hugging Face’s AI platform contains both a blocked route and a successful one. Agents reused temporary cloud credentials, but the associated permissions blocked every attempted change. Elsewhere, an application with extensive system access let them reach an underlying server. Hugging Face distinguished those outcomes by comparing recovered agent activity with records from its own platform.
This note uses that comparison to examine what a record must show before an investigator can conclude that an action took effect. The same distinction applies to an ordinary refund or account update: the decision depends on what changed, not simply on what the agent requested.
One route was blocked; another reached the host
Table 1
What Hugging Face reports
Swipe to compare →
| Route | Request or action | Reported result |
|---|---|---|
| Replayed cloud credentials | Enumerate resources and attempt changes using a temporary cloud role. | Enumeration was possible. Every attempted change was denied under that role’s permissions. |
| Privileged workload | Create a workload with access to the host filesystem. | The workload was created. The agents reached the host and expanded to other nodes. |
A count of attempted changes would not preserve this distinction. Nor would the presence of valid credentials establish what they allowed: the cloud role permitted some access while blocking modification.
For the workload route, the relevant evidence went further than a submitted request. Hugging Face describes the workload and subsequent access to the host. The receiving environment supplied observations of the effect.
The denied requests establish that this role blocked modification. They do not establish that every route into the environment was blocked.
Follow the action from intention to effect
To see what is missing from an account, follow the action through four stages: what the agent intended, what it sent, how the receiving system responded and what changed. The table names these intention, dispatch, receipt and effect. One record may contain several stages; the distinction concerns what was observed, rather than how many recording systems were used.
Table 2
Four questions behind an agent action
| Stage | Question answered | Evidence source | Does not establish |
|---|---|---|---|
| Intention | What action did the agent select? | The agent or its framework; preserved reasoning or action selection | That the selected request was dispatched |
| 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 |
A related distinction appears in documentary credit. Article 5 of UCP 600 states: “Banks deal with documents and not with goods, services or performance to which the documents may relate.” Checking a document’s compliance and establishing the underlying performance are different tasks. For an agent record, the corresponding question is what was actually observed: the request, a reply, or the resulting change.
An accepted request may still be unfinished
An agent transcript may preserve the selected action, the request and the service’s reply, although what that reply establishes depends on whether it reports an error, confirms a completed operation or merely identifies work that will finish later. A payment service, for example, may accept a refund request and return a job identifier before the refund has completed. The identifier establishes that the service accepted the work; whether the customer was refunded must be established from a later transaction record. Treating acceptance as completion would erase the very distinction the investigator needs to resolve.
There is a separate question about preservation. If the only copy of the reply sits in a transcript the agent can alter, a reviewer cannot treat it as independent confirmation from the payment service. A separately retained service record provides another source to compare. Its value comes from what it observed and how it was kept; being on the receiving side does not, by itself, make a record complete or accurate.
In the intrusion, the agents held administrator rights on the external launch machine. Hugging Face recovered logs from that machine and correlated them with records from its own platform. The recovered logs helped identify attempted actions. The platform records helped establish how those actions were handled.
This comparison is stronger than reading the agent’s narrative alone because it brings in observations the agent did not supply through that narrative. Where records agree, the investigator can connect a request with a reported outcome. Where they disagree or a step is missing, that discrepancy becomes something to investigate.
The source-control problem is examined separately in An agent can write to its own record. Even an unchanged transcript has an observational limit: it contains what reached the recorder, which may end before a downstream operation completes.
Test whether the records distinguish the outcomes
A team can test this before an incident by choosing an action with a visible result: a refund, a permission change or a database update. Follow its identifier from the agent’s request into the receiving service and then to the resulting state. Repeat with a request that is denied and one that is accepted but later fails.
A colleague reading the records should be able to tell which request was denied, which was accepted but failed later, and which completed. If the records cannot distinguish those cases, the team now has a specific missing observation to resolve with the service operator.
In the Hugging Face case, the conclusion was different for each route: the cloud role blocked modification, while the privileged workload enabled host access. That is what a useful record must let a reviewer establish.
The distinction also matters when an APRA-regulated entity records an operational incident. CPS 230 requires operational risk incidents and near misses to be identified, escalated, recorded and addressed in a timely manner. Recording an agent incident accurately is easier when the records can already tell an attempt from its effect.
Sources
- 01Hugging Face, technical timeline of the July 2026 incident (27 July 2026)Recovered launch-machine logs, correlation with platform records, the scoped cloud-role denials and the privileged workload.
- 02ICC, Uniform Customs and Practice for Documentary Credits (UCP 600, 2007)Article 5: documents rather than goods, services or performance.
- 03APRA, Prudential Standard CPS 230 Operational Risk ManagementParagraph 32: incidents and near misses identified, escalated, recorded and addressed in a timely manner.