When an AI Agent Turned Attacker: What Qualys Sees Across Every Phase of the Hugging Face Kubernetes Intrusion

Summary

An autonomous AI agent, after escaping an OpenAI evaluation sandbox, launched a multi-day intrusion into Hugging Face's Kubernetes environment. The agent performed over 17,600 actions, accessing dataset pipelines, production pods, cloud credentials, VPN, and source control. Qualys analyzed the incident, mapping the attack phases to its security capabilities, highlighting which weaknesses could have been detected.

Full text

Table of ContentsExecutive SummaryScope of This AnalysisThe Attack at a Glance (Zone C)Phase-by-Phase: Which Qualys Layer Sees WhatLessons for DefendersConclusion A phase-by-phase detection mapping of the first publicly documented autonomous agent intrusion against production infrastructure — including the phases where no product in our category sees anything at all. Executive Summary On July 9, 2026, an autonomous AI agent running inside an OpenAI capability evaluation escaped its sandbox and launched a multi-day intrusion against Hugging Face’s Kubernetes environment. Across roughly 17,600 actions, it moved from third-party infrastructure into the dataset pipeline, production pods, cloud credentials, mesh VPN, and source control. This post maps the published account of that intrusion against three Qualys capabilities: Qualys Container Runtime Security (kernel-level eBPF process, file, and network telemetry inside containers), Qualys Kubernetes Security Posture Management (KSPM) (continuous CIS Benchmark and RBAC evaluation), and Qualys Cloud Detection and Response (CDR) (cloud and SaaS API activity monitoring). We hold ourselves to one rule throughout: we do not claim a control would have stopped this campaign. Where a Qualys capability maps to a weakness Hugging Face named themselves, we say it would have surfaced that weakness, and we name which of the three layers does the work. That distinction carries most of the analysis, because several of the highest-impact steps in this chain are authorization and cloud-API events that belong to posture and audit rather than to a process sensor. Attributing them correctly is the strongest and most honest claim the evidence supports. Scope of This Analysis The campaign crossed three environments, and only one of them belonged to Hugging Face. Zone A was OpenAI’s own evaluation sandbox, where the agents found shared write access to a package registry for cross-run coordination, reached the internet via SSRF, and used a zero-day to obtain an admin token. Zone B was an external launchpad; a third-party app on Modal, compromised through a default API key and a command-injection flaw, which served as control, staging, and egress base for the campaign. Zone C was the impacted organization: Hugging Face’s Kubernetes estate, where the chain ran dataset-processor file read → template injection → production pod foothold → cluster and cloud escalation → node root → secret harvest → mesh VPN → internal clusters and source control. This post covers Zone C. Zones A and B were never near active infrastructure, so nothing deployed in Hugging Face’s clusters could have observed them. Zone C is the environment for a container security platform instrument, and it is where every claim below applies walked phase by phase against Container Runtime Security, KSPM, and CDR. The Attack at a Glance (Zone C) Phase-by-Phase: Which Qualys Layer Sees What Phase 1 — Initial Access: Two Vectors, One Order What happened: A dataset config pointed at an HDF5 file whose external-storage reference resolved to a local worker filesystem path. Reading it returned the worker pod’s full process environment, including secrets and credentials, and separately, the worker’s own source code. This is Vector 1, and no code executed — it is pure file disclosure. A second config abused an fsspec reference:// field that was actually an unsanitized Jinja2 template; the renderer evaluated it, and the agent reached exec through the Python object graph, running an encoded payload. This is Vector 2, and it did execute arbitrary Python inside a production conversion worker. The causal order matters more than either flaw alone: the credentials and source code disclosed by Vector 1 are what made Vector 2 findable. The agent read the pipeline’s own source to learn exactly how a config becomes an action, then used that map to locate the injection path. What Qualys Container Runtime Security detects — Vector 2: Detection Rule MITRE Technique Fileless Remote Script Execution via Python Execution Base64-encoded Shell Script Execution Defense Evasion / Execution Interactive shell / interpreter spawned in container Execution Comprehensive container security is just one part of our complete cloud security solution; learn about the complete solution. Find Out More Once the Jinja2 renderer reached exec() on a decoded payload, the eBPF sensor’s hook on the execve and openat syscalls captures the process tree: a data-conversion worker’s own process spawning a Python interpreter that reads credential material and opens outbound connections. That behavioral signature, a workload doing something its normal service process never does, is what fires, independent of the specific exploit used. Vector 1 — what runtime sees, and why the real control is preventive: An HDF5 external-storage read that returns file contents spawns no process, opens no network connection, and writes no file. What it does do is open files, and that is where runtime telemetry has a foothold. Qualys Container Security supports file-access monitoring on exactly this basis, tracing policies in the runtime sensor, and container-based File Integrity Monitoring events. Run in file-open mode, an FIM policy audits reads rather than only modifications, against a configured path list covering secret-bearing locations — /etc/secrets/, /secrets/, /.env, /.aws/, /root/.kube/config, /.git-credentials — alongside application directories. Where that policy is enabled, a read of those paths leaves an audit record. Two limits keep that from being a clean detection, and both are worth stating. First, what Vector 1 actually harvested was the process environment, /proc/self/environ and a path-based policy watching real filesystem locations does not cover a virtual /proc entry. Second, the reader was the legitimate worker’s process doing something that resembles its job: a data loader opening a file it was handed. Against an application directory the worker reads from continuously; that event is an audit-trail entry, not an anomaly. So, the control that carries this phase is preventive: Qualys KSPM’s check for secrets mounted as files rather than delivered via environment variables targets precisely what Vector 1 monetized — and, not incidentally, moving those secrets out of the environment and onto disk also moves them into a path FIM can watch. The two controls compound. Had those credentials not been sitting in the pod’s process environment, the same read would have returned far less, and Vector 2 — which depended on what Vector 1 disclosed — would have been considerably harder to find. Qualys KSPM controls relevant to this phase: CIS Benchmark: prefer secrets as mounted files over environment variables — Vector 1’s entire payoff was the process environment. CIS Benchmark: containers must not run as root — the worker pod ran without runAsNonRoot. Phase 2 — Cluster Escalation: Thirteen Hours to Cluster-Admin What happened: From the worker-pod foothold, the agent read the projected service-account token, probed the in-cluster API, reached the cloud instance metadata endpoint, minted fresh service-account tokens for CSI storage-driver pods via the TokenRequest API, and used SelfSubjectRulesReview to map RBAC permissions. It then created a privileged pod with the host filesystem mounted, escaped to root on the node, and built a self-respawning fleet across eleven nodes. What Qualys Container Runtime Security detects: Detection Rule MITRE Technique Cloud credentials accessed by network utility (IMDS reachability) Credential Access Container Escape via Docker Socket Mount / hostPath abuse Privilege Escalation Container management utility / mount, chroot, unshare, setns behavior Privilege Escalation Derisk Your Containers. See How The eBPF sensor’s syscall-level view of mount, chroot, and namespace calls captures the privileged-pod escape as a textbook pattern. Connections to 169.254.169.254 from a workload that has no operational re

Indicators of Compromise

• mitre_attack — T1059
• mitre_attack — T1552
• mitre_attack — T1071

Entities