Back to Intelligence

Hawley Probe of OpenAI Over Hugging Face Breach: Defending Against AI Supply Chain and Token Exposure Risk

SA
Security Arsenal Team
September 12, 2026
10 min read

Senator Josh Hawley (R-MO) has opened an inquiry into OpenAI following the Hugging Face breach, publicly characterizing the company's leadership decisions as "reckless" and invoking OpenAI's own warnings about existential AI risk to justify the probe. Regardless of where you land on the politics, the underlying event — a compromise touching one of the most critical distribution points in the AI ecosystem — deserves every defender's attention. Hugging Face is not a niche developer toy; it is the de facto package registry for machine learning models, datasets, and the API tokens that gate access to them. A breach there is functionally equivalent to a compromise of npm or PyPI for the AI stack.

This post is not about the Senate inquiry itself. It is about what the breach means for your environment: exposed Hugging Face access tokens, poisoned or tampered model artifacts, and third-party AI integrations your developers stood up without telling you. If your organization fine-tunes models, pulls open-weight models for internal tooling, or lets developers authenticate to HF hubs from build pipelines, you have exposure to assess today.

What Is Actually at Risk

No CVE has been published in connection with this incident, and defenders should not wait for one — this is a supply chain and credential exposure scenario, not a single patchable flaw. The practical risk concentrates in three areas:

1. Leaked or abused Hugging Face tokens. HF access tokens (hf_...) are frequently stored in plaintext at ~/.cache/huggingface/token, embedded in environment variables (HF_TOKEN, HUGGING_FACE_HUB_TOKEN), hard-coded in notebooks and CI/CD pipelines, and passed directly on command lines. Any breach touching user secrets, org tokens, or integrated third parties (like OpenAI's infrastructure relationships) means those tokens may be in adversary hands. A stolen write-scope token lets an attacker push a backdoored model into a repo your developers trust.

2. Malicious model artifacts. The HF ecosystem has a documented, ongoing problem with malicious models using Python pickle deserialization to execute arbitrary code on load. When a victim calls torch.load() or pickle.load() on a tampered .pkl or .bin file, the payload executes with the victim's privileges. This is the highest-impact post-breach scenario: an attacker with valid tokens swaps a popular or internally used model with a trojanized version, and every downstream pipeline that pulls it gets compromised.

3. Shadow AI integrations. The Hawley probe underscores a governance gap most enterprises share: leadership often cannot enumerate which vendors, APIs, and model hubs their engineers depend on. If you cannot inventory where huggingface_hub is installed and who is calling huggingface.co, you cannot assess breach impact.

Exploitation Status

There is no public proof-of-concept exploit or CISA KEV entry tied to a specific vulnerability here — the threat is opportunistic abuse of compromised credentials and trust relationships. Treat it as an active-risk event: assume tokens present in affected environments may be compromised, and assume any model pulled from an untrusted or recently modified repo could be hostile until provenance is verified.

Detection & Response

The detections below target the observable behaviors that matter post-breach: token exposure on endpoints, unexpected HF hub activity, and deserialization of untrusted model artifacts.

YAML
---
title: Hugging Face Token Exposed on Command Line
id: 3f8c2a91-7d44-4b2e-9a61-5c0e8f1b2d3a
status: experimental
description: Detects Hugging Face access tokens (hf_ prefix) passed directly on the command line, which exposes credentials in process telemetry and shell history. Relevant post-breach for identifying potentially compromised token usage.
references:
  - https://cyberscoop.com/openai-hugging-face-probe-senate-hawley/
  - https://attack.mitre.org/techniques/T1552/001/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.credential_access
  - attack.t1552.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - 'hf_'
      - 'HF_TOKEN'
      - 'HUGGING_FACE_HUB_TOKEN'
      - 'huggingface-cli login'
  filter_known_auth_tools:
    Image|endswith:
      - '\git.exe'
  condition: selection and not filter_known_auth_tools
falsepositives:
  - Developers legitimately logging in via huggingface-cli
  - CI/CD pipeline steps passing tokens (should be migrated to secret stores)
level: medium
---
title: Suspicious Download or Execution Involving Pickled Model Artifacts
id: 9b1d4e72-3c58-4f1a-a7e2-8d6f0c5b9e14
status: experimental
description: Detects Python loading pickle-based model files (.pkl, .bin, .pt) from temp, download, or user-writable directories, a common pattern when a trojanized Hugging Face model executes code via deserialization.
references:
  - https://attack.mitre.org/techniques/T1059/006/
  - https://attack.mitre.org/techniques/T1195/002/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.execution
  - attack.t1059.006
  - attack.t1195.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\python.exe'
      - '\python3.exe'
      - '\pythonw.exe'
  selection_cli:
    CommandLine|contains:
      - 'torch.load'
      - 'pickle.load'
      - 'joblib.load'
      - 'from_pretrained'
  selection_path:
    CommandLine|contains:
      - '\Temp\'
      - '\AppData\Local\Temp\'
      - '\Downloads\'
      - '\AppData\Roaming\'
  condition: selection_img and selection_cli and selection_path
falsepositives:
  - Legitimate local model development and testing
level: high
---
title: Non-Standard Process Connecting to Hugging Face Infrastructure
id: 5e2a7c63-1f94-4d8b-b3c6-2a9d7e4f8c01
status: experimental
description: Detects scripting engines, download utilities, or shells initiating network connections to huggingface.co or its CDN, which may indicate an attacker pulling a model or exfiltrating via HF hubs using living-off-the-land tooling.
references:
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.command_and_control
  - attack.t1105
logsource:
  category: network_connection
  product: windows
detection:
  selection_host:
    DestinationHostname|contains:
      - 'huggingface.co'
      - 'cdn-lfs.huggingface.co'
      - 'cas-bridge.xethub.hf.co'
  selection_img:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\curl.exe'
      - '\wget.exe'
      - '\cmd.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  condition: selection_host and selection_img
falsepositives:
  - Developer workstations using curl to test HF API endpoints
level: medium

On the Linux side (where most ML workloads actually live), hunt for token exposure and model-loading behavior in Sentinel via Syslog ingestion:

KQL — Microsoft Sentinel / Defender
// Hunt 1: Processes referencing Hugging Face tokens or login activity (Linux Syslog + Windows)
union isfuzzy=true
(Syslog
| where Facility == "user" or Facility == "auth"
| where ProcessName has_any ("python", "python3", "huggingface-cli", "hf", "pip")
| where SyslogMessage has_any ("hf_", "HF_TOKEN", "HUGGING_FACE_HUB_TOKEN", "from_pretrained", "huggingface-cli login")
| project TimeGenerated, Computer, ProcessName, SyslogMessage),
(DeviceProcessEvents
| where ProcessCommandLine has_any ("hf_", "HF_TOKEN", "HUGGING_FACE_HUB_TOKEN", "huggingface-cli login")
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine, AccountName)
| order by TimeGenerated desc

// Hunt 2: Network connections to Hugging Face infrastructure from unexpected processes
union isfuzzy=true
(DeviceNetworkEvents
| where RemoteUrl has_any ("huggingface.co", "xethub.hf.co")
| where InitiatingProcessFileName !in~ ("python", "python3", "git", "huggingface-cli", "hf", "msedge", "chrome", "firefox")
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteUrl
| order by ConnectionCount desc),
(CommonSecurityLog
| where RequestURL has_any ("huggingface.co", "xethub.hf.co")
| summarize count() by SourceIP, RequestURL, ApplicationProtocol, DeviceAction
| order by count_ desc)

// Hunt 3: New or modified model artifacts in user-writable paths (defender file events)
DeviceFileEvents
| where FileName endswith_any (".pkl", ".pt", ".bin", ".ckpt", ".safetensors")
| where FolderPath has_any ("\\Temp\\", "\\Downloads\\", "\\AppData\\", "/tmp/", "/var/tmp/", "/home/")
| project TimeGenerated, DeviceName, FileName, FolderPath, InitiatingProcessFileName, SHA256
| order by TimeGenerated desc

For endpoint forensics, sweep your fleet for HF token files and cache artifacts with Velociraptor:

VQL — Velociraptor
-- Hunt for exposed Hugging Face tokens and model cache artifacts across endpoints
SELECT OS,
       glob,
       FullPath,
       Size,
       Mtime,
       read_file(filename=FullPath, length=100) AS TokenPreview
FROM glob(globs=['C:/Users/*/.cache/huggingface/token',
                 'C:/Users/*/.huggingface/token',
                 '/home/*/.cache/huggingface/token',
                 '/root/.cache/huggingface/token'])
WHERE TokenPreview =~ 'hf_'
VQL — Velociraptor
-- Hunt for processes loading models or referencing HF infrastructure
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'from_pretrained|torch\\.load|pickle\\.load|huggingface'
   OR Exe =~ 'huggingface'

Finally, use this audit script to locate exposed tokens on Linux ML hosts and build servers before an attacker does:

Bash / Shell
#!/bin/bash
# hf_token_audit.sh - Locate exposed Hugging Face tokens and risky model artifacts
# Run on ML workstations, build runners, and Jupyter hosts. Requires sudo for full coverage.

echo "=== [1] HF token files on disk ==="
find /home /root /opt /srv -type f \( -path "*/.cache/huggingface/token" -o -path "*/.huggingface/token" \) 2>/dev/null -exec ls -la {} \;

echo "=== [2] HF tokens in environment and process args ==="
grep -rE "hf_[A-Za-z0-9]{20,}" /home /root /etc/profile.d /opt 2>/dev/null | grep -v Binary | head -50
ps auxww | grep -E "hf_[A-Za-z0-9]|HF_TOKEN" | grep -v grep

echo "=== [3] Hardcoded tokens in notebooks and source ==="
find /home /opt /srv -type f \( -name "*.ipynb" -o -name "*.py" -o -name "*.env" -o -name "*.yaml" -o -name "*.yml" \) 2>/dev/null -exec grep -lE "hf_[A-Za-z0-9]{20,}" {} \;

echo "=== [4] Pickle-based model files in world-writable/temp dirs ==="
find /tmp /var/tmp /dev/shm -type f \( -name "*.pkl" -o -name "*.pt" -o -name "*.bin" -o -name "*.ckpt" \) -mtime -30 2>/dev/null -exec ls -la {} \;

echo "=== [5] Token file permissions (should be 600) ==="
find /home /root -type f -path "*huggingface/token" 2>/dev/null -exec stat -c '%a %U %n' {} \;

echo "=== AUDIT COMPLETE - rotate any tokens found in sections 2-3 ==="

Remediation

  1. Rotate all Hugging Face tokens immediately — user tokens, organization tokens, and any token that existed in an environment touched by the breach. Do this from the HF settings portal (https://huggingface.co/settings/tokens), then invalidate CI/CD secrets and redeploy. Assume any token visible in process lists, shell history, or source control is burned.

  2. Migrate tokens out of plaintext. Remove tokens from ~/.cache/huggingface/token where possible (use huggingface-cli logout), enforce 0600 permissions where files must exist, and move pipeline credentials into a proper secrets manager (Vault, AWS Secrets Manager, Azure Key Vault). Never pass tokens as CLI arguments — they persist in ps output and EDR telemetry.

  3. Pin and verify model provenance. Pin model pulls to specific commit hashes rather than floating main revisions. Prefer safetensors format over pickle-based formats wherever available — safetensors does not permit code execution on load. Where pickle formats are unavoidable, scan artifacts with tooling such as picklescan or ModelScan before loading, and consider loading models in a sandboxed, unprivileged container.

  4. Inventory your AI supply chain. This is the governance lesson the Hawley probe is really about. Produce a definitive list of: every HF organization your teams belong to, every third-party AI vendor with API access to your data, every internal pipeline that calls external model hubs, and every service account with write access to model repos. You cannot respond to the next breach if you cannot enumerate dependencies.

  5. Restrict egress to model hubs. Limit outbound access to huggingface.co and its LFS/Xet CDNs to approved build systems and ML workstations. Alert on any connection from servers or endpoints outside that allowlist — there is almost no legitimate reason for a domain controller or database server to pull a model.

  6. Monitor repo integrity. For models your organization publishes or depends on, watch for unexpected commits, new files, or permission changes on HF repos. A sudden new revision of a model your pipeline auto-pulls is a high-fidelity indicator worth paging on.

  7. Update vendor risk assessments. If your organization is an OpenAI (or any AI vendor) customer, the Senate inquiry is a forcing function: request written incident details, scope of exposed data, and evidence of token rotation from any vendor implicated in the breach chain. Contractual breach-notification clauses exist for exactly this scenario.

The Bottom Line

Congressional inquiries come and go, but the defensive reality persists: the AI supply chain runs on bearer tokens and implicitly trusted artifacts, and both are now demonstrated targets. Rotate credentials, verify provenance, inventory dependencies, and instrument the detections above. The organizations that treat this breach as a fire drill — rather than a news story — will be the ones that survive the actual fire.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.