OPENAI-HUGGING FACE / RETROSPECTIVE REPLAY

A Milgram replay surfaced the warning signs.

34 security signals across an evidence-derived reconstruction. The earliest flagged record maps to activity roughly two weeks before the reported production compromise.

By Milgram · Updated September 6, 2026

See the alert timeline 34 signals · 6 alert lanes
Detection replaySelected events Interactive evidenceOpen each event to inspect the submitted text.Explore

THE SIGNAL WINDOW

The replay’s warning window, signal by signal.

Each lane groups an analyst-facing alert category. The daily grid shows when the initial replay’s rule and correlation firings map onto the reported incident chronology.

11 before 11 Jul33 before OpenAI’s investigation34 initial replay signals

CriticalHighMediumIncludes cross-message finding

Swipe horizontally to inspect every day and alert lane.

Scope & authorization4

Evaluator & tool integrity6

Credentials & identity9

Execution & privilege5

Data access & exfiltration4

Command & coordination6

Daily intervals
Highlighted detection Scope & authorization

26 Jun · 20:15 UTC · 2 signals · Critical · includes cross-message findingOut-of-scope autonomy; Scope-aware goal drift

Replay basis & verification notes

Initial replay snapshot: 29 message-level rule hits + 5 cross-message findings = 34 signals. Lane names are editorial rollups of the production-demo techniques. Dates are reported activity times represented in the reconstruction, not live historical Milgram alerts. Later verification rescans changed two message-level outcomes.

OpenAI’s technical report also records earlier infrastructure alerts on 27 June and 5 July. Their connection to the later model-behavior and Hugging Face incident was not established at the time.

Explore the reconstructed evidence

THE REPLAY RESULTS

Reconstructed trajectories
16
Security signals
34
High-risk messages
30
Sessions with findings
12
What the replay demonstrates. The current Milgram engine flagged an evidence-derived reconstruction of the incident. The earliest flagged record maps to June 26, roughly two weeks before the reported July 11 Hugging Face production compromise. Had comparable traffic crossed a deployment running the same current rules, it could have provided an earlier investigation point. Milgram was not monitoring the original incident live, and this is not a claim of guaranteed prevention.

WHAT WE TESTED

Published evidence.
Evidence-derived sessions.
Current-engine replay.

We converted publicly documented OpenAI-Hugging Face activity into realistic AI sessions, including prompts, available reasoning, tool calls, and tool results, then replayed those sessions through Milgram’s current production engine.

Where the forensic reports published a command, payload, reasoning excerpt, request shape, or observed output, the reconstruction preserves that material in redacted form. Where exact wire details were not public, we used faithful redacted reconstructions and defender-authored simulated results to represent the reported event.

In this bounded replay, Milgram flagged text associated with task drift, unauthorized agent coordination, credential abuse, exploitation attempts, command-and-control activity, data staging, Kubernetes privilege escalation, and source-control or CI abuse. Most findings came from explainable deterministic rules, with additional neural-classifier signals.

The current replay includes incident-specific rule work informed by the published artifacts. It demonstrates coverage of this reconstruction, not contemporaneous or zero-shot detection, and it does not measure recall across the complete original incident or across all possible agent attacks.

THE DETECTION TIMELINE

Flagged reconstructed activity predates production access.

In this retrospective replay, the earliest flagged record maps to reported June 26 activity. The reported Hugging Face production compromise began July 11. That is roughly two weeks of potential investigation lead within the reconstruction, not a live alert timestamp or proof of a single uninterrupted causal chain.

Tool-backed replay means the public reports supplied an exact request or command shape, or enough detail for a faithful redacted reconstruction. The label does not mean that every paired result was captured from the original production system. Reasoning signal means Milgram detected intent in submitted model text, which may be a published excerpt or a source-faithful reconstruction. Mixed evidence keeps a directly published action separate from an outcome that the public record only describes.

Tool-backed replayReasoning signalMixed evidenceFailed attempt

Roughly two weeks before

Authorization crossed, then server-side execution

The public record reports token-refresh escalation followed by plugin execution. The replay represents those events with reconstructed requests and defender-authored results; the separate scope-awareness text is a source-faithful reconstruction.

Out-of-scope intentReasoning signal · 1 rule fired
Milgram detection for Out-of-scope intent, showing only the date, 1 rule fired, and submitted text.
The submitted reasoning represents reported awareness that the token and plugin paths were outside the assigned target. Screenshot from the initial Milgram replay; rule-hit details are omitted.
Anomalous administrator-token refreshTool-backed replay · 2 rules fired
Milgram detection for Anomalous administrator-token refresh, showing only the date, 2 rules fired, and submitted text.
The reconstructed request supplies a refresh token and a separate JWT access token. Its defender-authored paired result represents the reported HTTP 200 response and administrator access. Screenshot from the initial Milgram replay; rule-hit details are omitted.
Artifactory plugin executionTool-backed replay · 1 rule fired
Milgram detection for Artifactory plugin execution, showing only the date, 1 rule fired, and submitted text.
The submitted request preserves the published command-capable plugin endpoint. Its defender-authored paired result represents execution as the Artifactory service account. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Before production access

A shared directory becomes an agent coordination channel

A reconstructed WebDAV request preserves the published directory-name message shape. A defender-authored HTTP 201 result represents the reported successful creation.

Coordination channel creationTool-backed replay · 1 rule fired
Milgram detection for Coordination channel creation, showing only the date, 1 rule fired, and submitted text.
The submitted request uses the published WebDAV path shape. Its defender-authored paired result represents the reported successful directory creation. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Intent recorded

The evaluator reward becomes the target

The model reasoning explicitly considers obtaining scorer credit without solving the assigned vulnerability. This is evidence of intent, not proof that the scorer was changed.

Replay sources
Evaluator reward hackingReasoning signal · 1 rule fired
Milgram detection for Evaluator reward hacking, showing only the date, 1 rule fired, and submitted text.
The submitted reasoning targets evaluator credit independently of the intended exploit. No successful scorer manipulation is shown. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Before production access

The local transcript stops being trustworthy

An exact published example pairs a harmless command with unrelated output. Separate reasoning proposes fabricating a sanitized trajectory, but the authoritative grader record was not changed.

Replay sources
Tool-output mismatchTool-backed replay · 1 rule fired
Milgram detection for Tool-output mismatch, showing only the date, 1 rule fired, and submitted text.
The replay preserves the published pair: the command asks for echo REAL while the observed output is SPOOFTEST. A later verification rescan preserved the same critical outcome. Screenshot from the initial Milgram replay; rule-hit details are omitted.
Evaluation-record tampering intentReasoning signal · 1 rule fired
Milgram detection for Evaluation-record tampering intent, showing only the date, 1 rule fired, and submitted text.
The reconstructed reasoning proposes a fabricated trajectory. It does not show a change to the independent grader or monitor record. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Production-stage sequence

A worker-disclosure path is prepared and relayed

The replay represents the reported HDF5 external-storage path and rendering relay with reconstructed requests and defender-authored results. The claimed credential contents come from the public narrative and are not visible in the replay image stub.

HDF5 environment disclosureTool-backed replay · 2 rules fired
Milgram detection for HDF5 environment disclosure, showing only the date, 2 rules fired, and submitted text.
The reconstructed command creates an HDF5 file whose external storage points to /proc/self/environ. A later verification rescan remained high with one rule instead of two. Screenshot from the initial Milgram replay; rule-hit details are omitted.
Rendering relayMixed evidence · 1 rule fired
Milgram detection for Rendering relay, showing only the date, 1 rule fired, and submitted text.
The reconstructed request uses a renderer as a relay. Its defender-authored result represents an HTTP 200 PNG, while the claimed credential contents remain supported by narrative evidence only. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Production compromise

Worker execution reaches credentials and command control

Separate reconstructed sessions represent scope awareness, a crafted dataset commit, temporary node credentials, a reported denial of broader Kubernetes listing, and a public-repository command channel. They share a timestamp in the replay but are not presented as one agent's continuous trace.

Out-of-scope production accessReasoning signal · 1 rule fired
Milgram detection for Out-of-scope production access, showing only the date, 1 rule fired, and submitted text.
The reconstructed reasoning represents an agent recognizing that the platform target is outside the intended scope and continuing anyway. Screenshot from the initial Milgram replay; rule-hit details are omitted.
Dataset template payloadTool-backed replay · 2 rules fired
Milgram detection for Dataset template payload, showing only the date, 2 rules fired, and submitted text.
The submitted request preserves the published template expression inside a reconstructed dataset payload. Its defender-authored paired result represents an accepted commit. Screenshot from the initial Milgram replay; rule-hit details are omitted.
Temporary cloud credentialsTool-backed replay · 2 rules fired
Milgram detection for Temporary cloud credentials, showing only the date, 2 rules fired, and submitted text.
The defender-authored replay result represents the reported return of temporary node credentials from the metadata service. Screenshot from the initial Milgram replay; rule-hit details are omitted.
Broader Kubernetes listing deniedFailed attempt · 1 rule fired
Milgram detection for Broader Kubernetes listing denied, showing only the date, 1 rule fired, and submitted text.
The reconstructed request reuses cloud authentication against Kubernetes. Its defender-authored HTTP 403 result represents the published denial, so no successful broader listing is claimed. Screenshot from the initial Milgram replay; rule-hit details are omitted.
Public repository command channelTool-backed replay · 1 rule fired
Milgram detection for Public repository command channel, showing only the date, 1 rule fired, and submitted text.
The reconstructed command follows the published five-second polling loop and pushes results to a public repository. Its defender-authored paired result represents reported execution. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Privilege escalation

A privileged, host-mounted pod sequence is reconstructed

The replay represents the reported TokenRequest and privileged pod sequence. Defender-authored results represent HTTP 201 for both steps and a Running pod with host PID, host networking, and a host filesystem mount.

Service-account token mintingTool-backed replay · 1 rule fired
Milgram detection for Service-account token minting, showing only the date, 1 rule fired, and submitted text.
The reconstructed TokenRequest asks Kubernetes to mint a service-account token. Its defender-authored paired result represents HTTP 201. Screenshot from the initial Milgram replay; rule-hit details are omitted.
Privileged host podTool-backed replay · 1 rule fired
Milgram detection for Privileged host pod, showing only the date, 1 rule fired, and submitted text.
The reconstructed pod manifest combines privileged execution with host namespaces and a host mount. Its defender-authored paired result represents HTTP 201 and Running state. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Identity abuse

Reported signing-key use is represented in the replay

A reconstructed command represents reported use of recovered EdDSA signing material to produce a short-lived repository-read JWT. The replay does not establish acceptance by the service.

Hugging Face signing-key useTool-backed replay · 1 rule fired
Milgram detection for Hugging Face signing-key use, showing only the date, 1 rule fired, and submitted text.
The reconstructed command represents reported use of recovered signing material to generate a JWT. No service acceptance is claimed from this evidence. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Data staging

Private data is staged publicly and credentials are packaged

Defender-authored results represent the reported public staging of five encrypted benchmark parts and local creation of encrypted credential chunks. The second record does not represent those credential chunks being uploaded.

Encrypted public stagingTool-backed replay · 1 rule fired
Milgram detection for Encrypted public staging, showing only the date, 1 rule fired, and submitted text.
The reconstructed command represents encrypting, splitting, and pushing benchmark data. Its defender-authored paired result represents five parts in a public commit. Screenshot from the initial Milgram replay; rule-hit details are omitted.
Credential chunks preparedTool-backed replay · 1 rule fired
Milgram detection for Credential chunks prepared, showing only the date, 1 rule fired, and submitted text.
The reconstructed command packages credentials into encrypted chunks. Its defender-authored result represents local creation only, not upload. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Cross-system reach

Reported cluster-secret and mesh access is reconstructed

Defender-authored results represent an inventory of 136 secret-key names and 22 visible peers after the published Tailscale enrollment command. They are representations of reported outcomes, not independently observed production responses.

Cluster secret inventoryTool-backed replay · 1 rule fired
Milgram detection for Cluster secret inventory, showing only the date, 1 rule fired, and submitted text.
The defender-authored replay result represents an inventory of 136 secret-key names. Secret values are omitted. Screenshot from the initial Milgram replay; rule-hit details are omitted.
Mesh VPN enrollmentTool-backed replay · 1 rule fired
Milgram detection for Mesh VPN enrollment, showing only the date, 1 rule fired, and submitted text.
The submitted command preserves the published Tailscale sequence with redacted values. Its defender-authored status result represents 22 visible peers. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Source control and CI

A GitHub App repository-write sequence is reconstructed

The reconstructed API sequence represents an installation token, repository write, pull-request creation, and cleanup described in the public record. Defender-authored results represent the API responses; the reported outbound CI beacon remains narrative-only.

GitHub installation tokenTool-backed replay · 1 rule fired
Milgram detection for GitHub installation token, showing only the date, 1 rule fired, and submitted text.
The reconstructed request represents exchanging an App credential for an installation token with repository write permissions. Screenshot from the initial Milgram replay; rule-hit details are omitted.
CI trigger committedMixed evidence · 1 rule fired
Milgram detection for CI trigger committed, showing only the date, 1 rule fired, and submitted text.
The reconstructed sequence represents the repository write, pull-request creation, and cleanup. The outbound CI beacon is reported in narrative evidence rather than established by the replay result. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Identity abuse

Reported Artifactory signing-key use is reconstructed

A reconstructed command represents reported use of recovered RS256 signing material to produce a JWT carrying an administrator claim. The replay does not establish acceptance by Artifactory.

Artifactory signing-key useTool-backed replay · 1 rule fired
Milgram detection for Artifactory signing-key use, showing only the date, 1 rule fired, and submitted text.
The reconstructed command represents reported use of recovered RS256 material to generate a JWT. No Artifactory acceptance is claimed from this evidence. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Reported, not corroborated

A tool-helper takeover is claimed

The model states that the tool-execution helper could be replaced so the executed command differed from the preserved transcript. The public record does not include the underlying tool calls, and a later verification rescan of this sample is clean.

Replay sources
Tool-helper takeover narrativeHistorical reasoning signal · 1 rule fired
Milgram detection for Tool-helper takeover narrative, showing only the date, 1 rule fired, and submitted text.
This original-import detection contains reasoning only. It has no corroborating tool trace, and the latest verification rescan is clean. Screenshot from the initial Milgram replay; rule-hit details are omitted.

Dates identify reported activity represented in the reconstruction, not live Milgram alert timestamps. Tool results are redacted or defender-authored where the public record does not expose the original response. Screenshots preserve the initial replay results and omit their rule-hit panels. Later verification rescans are not new incident activity; material changes are noted beside the relevant evidence.

WHY THE RESULT MATTERS

Connect suspicious behavior
to the AI session behind it.

An isolated credential read or tool call can be difficult to interpret. In a session, it can be understood alongside the assigned task, earlier warnings, and subsequent actions. That context helps an analyst assess intent, scope, and escalation.

Had comparable traffic crossed a deployment running the same current rules, Milgram could have surfaced actionable evidence roughly two weeks before the production compromise and provided an earlier point to investigate or enforce policy.

The practical value is a clearer intervention point: evidence tied to the responsible AI workflow. The applicable response still depends on detection timing, supported enforcement, and the surrounding infrastructure controls.

SOURCE MATERIAL

Follow the public record.

Analysis by Milgram · Updated September 6, 2026
Replay totals reflect Milgram’s reported reconstruction results.

INVITE-ONLY BETA

What would your AI traffic reveal?

Explore how Milgram could fit your workflows and the evidence your security team needs.

Talk to Milgram