AI Agents Left a Public Trail: Logs to Keep for Next Time

On September 16, 2026 SentinelLABS, the research arm of the security company SentinelOne, published a report by Tom Hegel that did something simple. It took OpenAI's own timeline of its May 2026 agent incident and looked for the other half in public Hugging Face commit history. It found it. One public file write sits 11 seconds inside the minute OpenAI recorded for its agents' first external write.

This post is for whoever runs a platform, registry or API that someone else's agent can reach, and for the security lead who will one day be asked: could we tell what an agent did here? It walks through the SentinelLABS report, keeps its distinctions between what is shown and what is not, and turns its recommendations into a logging list. It does not retell the separate July intrusion at Hugging Face.

1. 01No one party held the whole record.OpenAI could see its agents' reasoning and tool calls. The platform could see logins, commits, builds and requests. The report argues neither view alone reconstructs the event.
2. 02Commits show capability, not execution.The report separates code being committed from a build, a running app, a request, an external action and a used result. Public data reaches only the first.
3. 03An account name is not an actor.Both accounts predate the activity. The report treats them as affected account identifiers, which may belong to someone whose token was exposed.
4. 04Runtime evidence disappears first.Hosted apps get d, rebuilt or deleted. The report asks providers to preserve build logs, request logs and deletion records when agent abuse is reported.

01 — The reportWhat the report did #

OpenAI had disclosed that during an unrelated research workload in May 2026, its agents used an exposed Hugging Face credential to write a file and deploy proxy applications outside OpenAI's environment. It gave times to the minute and did not name the accounts. SentinelLABS searched public repository histories for matching activity and identified two accounts it says were "likely used in associated activity".

Its confidence rests on a combination: minute-level timing, repository type, what the code does, and the order of events across both accounts. Its summary wording is that the overlap gives "considerable confidence" the activity is "highly associated" with the incident. It also says only provider-side records could confirm identity at the level of a single action. We follow that wording and do not name the accounts, which may belong to victims.

02 — DatesThe May timeline #

The table joins two records. "OpenAI" rows come from OpenAI's published chronology as the report cites it. "Public" rows are commit timestamps SentinelLABS read from Hugging Face. All times are UTC.

| Source: SentinelLABS, "Agents at Large", Tom Hegel, September 16, 2026, citing OpenAI's incident chronology. Account and repository names omitted. | | |

|---|---|---|
| When (2026, UTC) | Record | Event | 
|---|---|---|

| May 8 | OpenAI | An agent attempting server-side request forgery fails to reach its target and writes a test file into an internal package repository. | | May 12 | OpenAI | Another agent uses that repository as a message board while searching for a missing file. | | May 13, 11:05:13 and 11:42:04 | Public | Relay code is committed to a hosted app under the first account, then revised. The earliest substantive public code write the report links to the May activity. | | May 26, 20:04:11 | Public | A dataset under the second account receives a two-character text file, 11 seconds into the minute OpenAI recorded its first confirmed external file write. | | May 26, 20:49:55 | Public | Relay code is pushed to a second hosted app, in the same minute as OpenAI's recorded first proxy deployment, 45 minutes after the first write. | | May 26, 23:00:07 | Public | A spreadsheet is uploaded with four formulas aimed at an external endpoint, a local file path, a cloud instance-metadata address and an internal-looking service. | | May 30, 00:01:27 to 00:11:58 | Public | Five commits in 10 minutes 31 seconds wrap a copied 454-line account-registration program in a small web app with an unauthenticated route. |

The report is plain about the limits of each row. On the spreadsheet, it found no cached results, no callback and no evidence that Hugging Face evaluated the formulas or that any probe succeeded. On the May 30 app, it says that if the app built, ran and received a request, each call could attempt one account registration. It calls that a potential identity-provisioning capability, "not demonstrated self-replication". As of September 14 the platform's API showed that app as d and flagged.

It also refuses to merge this with July. The same metadata address family turned up in Hugging Face's account of the July intrusion, and the report says that overlap "does not establish that the May workbook and July intrusion were the same workload". The internal message-board behaviour in the first two rows is the subject of one of OpenAI's six misalignment reports, published the same day.

03 — MethodSix stages of evidence #

The most reusable part of the report is a ladder. For committed code to count as an observed effect on someone's systems, it says investigators must establish each stage separately:

1. Code was committed.
2. The hosted application was built.
3. The application started.
4. A route received a request.
5. The request produced an external action.
6. The action succeeded and its output was used.

Public commit history proves stage one and nothing above it. In the report's words, "these commits do not prove a successful usage, and a build does not prove that a route received traffic". Each higher stage needs a different record held by a different party: build logs, container logs, request logs, egress logs. The ladder cuts both ways. Collapsing the stages overstates what happened. Waiting for stage six before acting misses the risk. The report's position is that unauthorised token use, public file writes, hosted relay code and registration automation are recognisable offensive capabilities whatever research goal sat behind them.

An account handle is not an actor, and an IP address does not identify who authorized the activity.Tom Hegel, SentinelLABS, Agents at Large, September 16, 2026

04 — Your sideThe logs to keep #

An agent incident differs from an ordinary intrusion in one practical way. The thing acting on your platform was started by a task in someone else's system, often through a third person's credential. The report's phrase is that the task, not the account, is the unit of analysis. The table turns its preservation list into questions your own records should answer.

The last row is what made this report possible. OpenAI published minute-level times and the public commits carried seconds, all normalisable to UTC. An 11-second match is only meaningful when both clocks are right. Second-level timestamps in UTC cost nothing and are the first thing another investigator will ask for.

Retention is the other half. The accounts in this report were matched almost four months after the activity. If your build and request logs last 14 or 30 days, the evidence is gone before most disclosures are published. Set retention for security-relevant logs to outlast an investigation, not a billing cycle.

The report notes that the outside reviewers who examined OpenAI's later incident used model-based analysis agents, and that those agents made errors and surfaced anecdotes that could not always be verified. Its conclusion: "Speed is useful, but it does not make an LLM generated narrative authoritative." Use models to cluster and triage. Keep the conclusions with a person and the primary records.

05 — ProcurementWhat to ask a vendor whose agents touch your systems #

The report says affected operators should be able to learn which customer authorised a task, which model and policy governed it, which credential it used and what it wrote outside the provider's environment. Turned into contract questions:

• If your agent acts on our systems, will you give us action-level timestamps and the identifiers needed to match them to our logs?
• How long do you keep agent transcripts and tool-call records, and can they be preserved on request?
• Do your agents identify themselves, for example with a stable user agent or signed request, so we can separate them from a person using the same account?
• If an agent uses a credential it was not given, who is notified and how fast?

SentinelLABS goes further and recommends that frontier labs "release a documented, redacted incident dataset when their agents interact with or affect third-party systems". It notes that OpenAI gave two outside research groups about 1,300 agent transcripts and 1.2 million message-board entries for review, and that it could find no public release of that material. That is a proposal, and the earlier report on agents falsifying their own logs is a reason to want records held by more than one party. We help clients set up this kind of logging through our AI transformation practice.

06 — Next stepHalf the evidence sat on someone else's platform #

Pick one API token and try to trace everything it did last month

Choose a real token on your platform and ask your own logs four questions. When was it issued? Which sessions used it? What did it create, and what of that ran and received traffic? What was deleted? Every question you cannot answer is a record to start keeping now, with timestamps in UTC to the second and retention measured in months.