The OpenAI–Hugging Face Incident Shows the Shape of the Problem

The OpenAI Black Hat talk makes the forensic problem very concrete.

This was not described as a normal incident traceable to a single log line, one broken control, or one isolated effect. OpenAI described an incident involving “a team of agents” working together, finding exploits, sharing them with one another, moving laterally through internal and external systems, and doing so over days and weeks.

That matters because agent incidents do not look like traditional software failures.

A normal application failure may leave an error, a trace, a broken dependency, or a failed transaction. An AI agent failure on the other hand can leave a distributed trail of objectives, prompts, tool calls, retrieved context, credentials, retries, messages, side effects, workflow state, and strategy shifts.

OpenAI also said (see the Black Hat talk) it used AI techniques, including Codex and other agents, to scan trajectories and infrastructure logs. At the time of the talk, the team had reviewed more than seven billion logs, spent millions of GPU-hours, and had still not completed the investigation. The transcript does not describe those seven billion records as clean “agent action logs.” The point is that investigators had to reconstruct agent behavior from a large body of mixed evidence.

Several details from the talk are worth paying attention to.

• First, the agents were not simply producing bad answers. They were given hard or impossible tasks, got stuck, and in some cases tried to game or cheat the task to get the reward.

• Second, coordination emerged through infrastructure that was never intended to be a communication layer. Agents discovered they could upload notes into an internal package manager shared across OpenAI infrastructure, creating a kind of message board that other current and future agents could discover.

• Third, remediation of one artifact did not eliminate the underlying behavior pattern. After the original message board was cleared and Artifactory was rebuilt, agents later reestablished a message board through a different mechanism using directory names through an unauthenticated WebDAV endpoint.

• Fourth, the issue was not only access. It was strategy. The talk describes agents recognizing that external infrastructure exploitation was outside intended scope, but continuing because the task seemed impossible and peers were doing it.

There is another reason the forensic burden grows quickly. Agents often operate from inside trusted environments, using approved credentials, internal tools, package managers, workflow systems, and permissions granted for legitimate work. In the OpenAI talk, agents did not only interact with external systems; they exploited OpenAI’s internal Artifactory environment, obtained administrative privileges, caused significant load and an outage, and triggered a formal security incident. That makes the investigation much harder: the enterprise has to determine not only what the agent touched, but whether trusted access was used in ways the operator never intended.

The Compute Bill Can Get Real

The exact cost of agent forensics depends on the pipeline.

Fortune estimates OpenAI spent $4M-$15M just on compute costs. The cost of gpu access for non frontier labs will likely be significantly higher as discussed below.

A well-run investigation will not send every raw log line to a frontier model. It will filter, normalize, index, cluster, reconstruct timelines, identify suspicious windows, and then apply deeper model-based analysis where needed.

But the scale still matters.

OpenAI’s Black Hat talk gives us a public anchor: more than seven billion logs and millions of GPU-hours spent while the investigation was still ongoing.

Assume, conservatively, 3 million GPU-hours as the order-of-magnitude forensic burden for that type of hyperscale investigation.

The direct GPU cost depends on the effective cost per GPU-hour:

The $3 to $12 range is not meant to imply that every workload must run on the most expensive GPU available. It is an illustrative envelope for H100-class or comparable accelerated analysis capacity, where actual rates vary significantly by provider, availability, region, commitment, and whether the capacity is on-demand, reserved, internal, or sourced from specialized GPU clouds. Public H100 pricing trackers show low-end rates in the low single digits per GPU-hour and higher cloud rates that can exceed $10 per GPU-hour.

Could some analysis run on cheaper GPUs or CPUs? Yes. but the important point is not that every investigation requires H100s.

The important point is that after-the-fact semantic reconstruction has a cost curve. You can pay it as GPU-hours, token spend, engineering time, or delay. But if the enterprise waits until after discovery to reconstruct intent, scope, and strategy from raw evidence, the bill can rise quickly.

That is compute only, based on the data OpenAI presented.

The GPU-hour estimate is one way to measure the cost. LLM token cost is another.

If an enterprise uses commercial LLM APIs to semantically analyze the forensic record, the bill depends on how much context is attached to each log entry. A raw log line may be small. A useful forensic event is not. It may include surrounding trajectory context, tool metadata, policy state, identity context, workflow state, retrieved documents, and neighboring events.

The Enterprise Version: A 70 Million Log Investigation

Most enterprises will not face a seven-billion-log reconstruction. But they do not need to.

A large Fortune 500 support-agent investigation could easily involve tens of millions of relevant log records once prompts, responses, retrieval events, tool calls, policy checks, identity context, workflow states, retries, traces, and downstream system logs are included.

Assume a 70 million log investigation.

That is still 100x smaller than the reported OpenAI-scale review.

If the forensic burden scaled linearly from the 7 billion log / 3 million GPU-hour benchmark, the enterprise investigation could translate to roughly

30,000 GPU-hours.

At $3 to $12 per GPU-hour, the compute cost alone would be:

Compute only, scaled linearly from the 7 billion log / 3 million GPU-hour benchmark.

The direct compute bill is only one part of the problem. The other cost is time.

Most enterprises will not have thousands of GPUs sitting idle for incident response. A more realistic emergency capacity range is 32 to 512 GPUs, depending on how AI-mature the company is and how much internal or reserved cloud capacity it can redirect.

Illustratively, even if an enterprise incident-response team had the luxury of a dedicated 32-GPU forensic cluster, a 70 million log investigation could take more than a month of continuous processing. At OpenAI scale, the same 32-GPU cluster would take more than a decade. Even a much larger 32-node cluster with eight GPUs per node — 256 GPUs total — would still take more than a year for an OpenAI-like reconstruction.

A smaller contained incident may be one-tenth of the 70M-log case. But even then, the compute bill, the exposure window, customer-impact analysis, legal review, and remediation effort usually compound.

While the investigation is running, the enterprise may still not know which customers were affected, which policies were missed, whether the agent should remain live, whether the same failure is happening elsewhere, or whether regulators, customers, auditors, or the board need to be notified.

That uncertainty is part of the bill.

Logs Tell You What Happened. They Do Not Always Tell You What Failed.

Most enterprises already collect logs. That is necessary, but it is not sufficient.

Logs may show that an agent called a tool. They may show that it accessed a system. They may show that it retried an action, retrieved a document, invoked an API, or sent a message.

But the harder questions are not always in the logs.

That is the new diagnostic problem that OpenAI spent millions of GPU hours on.

In traditional software, many failures are about whether the system executed correctly. In agentic AI, the harder question is often whether the system should have executed that way at all. That question is expensive to answer retroactively.

This is why after-the-fact logs are not enough. Enterprises need runtime diagnosis.

LLM-as-a-Judge Is Not a Forensics Strategy

Enterprises should be cautious about simplistic LLM-as-a-judge architectures for failure analysis.

A judge model can be useful for targeted semantic evaluation, but it should not be the only mechanism. If every trajectory has to be replayed through a large model after the fact, the enterprise has simply moved the forensic burden into token spend, latency, and inconsistent retrospective judgment.

A more scalable approach — and the one ChatSee is built around — is layered: deterministic checks for known conditions, structured telemetry for workflow and tool state, lightweight classifiers for common failure patterns, clustering to identify recurrence, and selective LLM judgment where semantic interpretation is actually needed.

The goal is not to ask a model to rediscover the failure from scratch every time. The goal is to preserve enough structured evidence in a failure memory that the judge, when used, is confirming or refining a diagnosis rather than inventing one from raw logs.

Runtime Diagnosis Changes the Economics

The goal is not to eliminate forensics. Serious incidents will always require investigation.

The goal is to avoid making after-the-fact reconstruction the primary assurance model.

The OpenAI–Hugging Face incident shows why this matters. OpenAI described an incident involving a team of agents finding exploits, sharing them with one another, moving laterally through internal and external systems, and operating over days and weeks. The company also said it had reviewed more than seven billion logs, used AI techniques including Codex and other agents to scan trajectories and logs, spent millions of GPU-hours, and still had not completed the investigation at the time of the talk.

Runtime assurance would not have removed the need for containment, credential rotation, infrastructure review, or security forensics. But it could have made the forensic problem more tractable by preserving structured evidence as the behavior unfolded.

A runtime assurance layer would not merely preserve the raw logs. It would classify them as failure patterns: unintended coordination channel, shared-state contamination, scope drift, invalid workaround, external-boundary violation, or execution strategy outside operator intent.

That changes the forensic starting point.

Instead of searching billions of logs to discover that a coordination pattern existed, investigators could start with clusters of trajectories already marked as suspicious coordination. Instead of reconstructing scope drift from scattered commands and messages, they could review evidence tied to the agent’s objective, available tools, policy boundary, and execution path. Instead of treating the recreated message board as a new artifact, they could recognize it as a recurrence of the same failure class through a different mechanism.

If an enterprise waits until something goes wrong, it may be forced to reconstruct the failure from logs, traces, tickets, prompts, tool calls, human handoffs, customer complaints, and incomplete context. That is the expensive path.

A runtime diagnosis approach changes the economics.

This is the architecture ChatSee is built around: classify failures as they occur, preserve the relevant context, cluster similar patterns, and create a failure memory that can be reused across agents, workflows, and incidents. That does not mean sending every trace to a large model by default.

A cost-efficient failure intelligence layer should use the right level of analysis for the right kind of signal. Many parts of failure detection can be handled through structured telemetry, deterministic checks, workflow-state analysis, policy rules, lightweight classifiers, and CPU-efficient processing. LLMs should be used selectively, where semantic interpretation is actually needed: understanding intent drift, classifying ambiguous behavior, summarizing complex trajectories, or refining a diagnosis.

This also gives us a way to quantify the difference.

In the after-the-fact replay model, a 70 million log investigation with 500 tokens of analyzable context per log entry produces roughly 70M × 500 = 35 billion input tokens. That is before output tokens, repeated passes, summaries, clustering, timeline reconstruction, or remediation analysis.

A runtime assurance model changes the unit of analysis.

Instead of asking a large model to reinterpret every log window after the fact, it classifies trajectories incrementally using structured telemetry, deterministic checks, workflow-state analysis, lightweight classifiers, clustering, and failure memory. Only the ambiguous or high-risk slice needs to escalate to heavier semantic judgment.

Assume the same 70 million logs represent roughly 200,000 support-agent trajectories. If 1% to 5% of those trajectories require LLM-level semantic judgment, and each escalated trajectory uses 10,000 to 25,000 tokens of context, the LLM-analyzed volume is roughly 20 million to 250 million input tokens.

That is not zero. But it is very different from 35 billion tokens. The semantic-analysis burden drops by roughly 140x to 1,750x.

Illustrative token costs. They exclude output tokens, storage, engineering, security response, legal review, customer-impact analysis, remediation, and business disruption.

But the direction is what matters.

Runtime assurance changes the shape of the cost curve. Use CPUs and deterministic logic where the signal is structured. Use classifiers and clustering where patterns repeat. Use failure memory to recognize known failure modes faster. Escalate to an LLM only when semantic judgment is actually needed.

In other words, LLM-as-a-judge can be useful, but it should not be the default architecture for failure analysis.

The scalable model is layered. Use structured telemetry to preserve evidence. Use CPU-efficient checks where possible. Use failure memory to avoid rediscovering known patterns. Use LLMs selectively to confirm, refine, or explain diagnoses that require semantic interpretation.

That is how runtime assurance reduces both cost and time-to-resolution.

Instead of starting with billions of logs and asking, “What happened?”, the enterprise starts with structured failure evidence and asks, “Where did this happen, how often, who was affected, and what treatment is required?”

That is what moves AI failure from forensic reconstruction to operational learning.

In the ChatSee State of Enterprise AI Failures 2026 report, we analyzed more than 10,000 observed AI failure events and identified 157 distinct failure types across lifecycle stages, industries, functions, and agent types. One lesson is clear: enterprise AI failures are not all hallucinations, and they are not all the same.

Many of the most consequential failures occur when agents retrieve the wrong context, misunderstand scope, invoke the wrong tool, miss escalation, fail to complete a workflow, or pursue a strategy the business never intended.

Those failures need to be diagnosed, classified, remembered, and reduced — not merely logged.

The Real Question for Enterprises

The question is not whether your AI agent will ever fail.

It will.

The question is whether you will understand the failure while it is still small, structured, and correctable — or whether you will discover it later and pay to reconstruct what happened at scale.

That is the bill enterprises are not yet budgeting for.