We Read About the Hugging Face Hack. Then We Audited Our Own App.

Last week, Hugging Face published a detailed post-mortem about how an autonomous AI agent — built on OpenAI models and running inside a cybersecurity evaluation — broke into their systems over four and a half days, executing 17,600 actions without a single human stepping in to stop it.

It wasn't a rogue agent. It wasn't disobeying orders. It was doing exactly what it was designed to do — find exploits — just against the wrong target. One leaked password opened a chain of compromises that ultimately reached several company systems.

Hugging Face's conclusion was blunt: the agent exploited unsafe dataset processing, exposed cloud metadata, overly broad access permissions, and long-lived credentials. A capable human hacker could have found the same flaws. The difference was scale and relentlessness.

That summary sat with us for a while.

"Are We Actually Protected?"

We're a team building an internal AI platform — a production web app with a Python/FastAPI backend, React frontend, and infrastructure on Azure Kubernetes Service. Nothing exotic. But we realized we'd never systematically checked our codebase against exactly the four vulnerability categories the Hugging Face report named.

So we did. Here's what we found.

The Four Categories, Checked

1. Unsafe Data Processing

The path traversal issue was subtle. Two endpoints that served locally stored files used normpath to resolve the path from a database record. The problem: normpath doesn't resolve symlinks and doesn't verify the path stays inside the upload directory.

2. Exposed Cloud Metadata

Azure's Instance Metadata Service lives at 169.x.x.x — a link-local address. Our app had a solid url_safety module that blocked requests to private IPs, loopback, and link-local ranges. But it was only wired up in one code path. An admin-only backfill endpoint that fetched external article URLs was calling some get-requests directly — no validation. A compromised admin account could have used it to probe internal infrastructure or steal identity tokens from Azure IMDS.

3. Overly Broad Access Permissions

This was the most sobering category. Every Kubernetes deployment manifest — backend, frontend, AI scraper, sync jobs — was missing a securityContext block entirely. In Kubernetes, that means containers run as root with no privilege restrictions unless the cluster enforces a Pod Security Admission policy at the namespace level.

4. Long-Lived Credentials

The SAS token stood out. Seven-day Azure blob storage tokens mean that if a token leaks — in a log file, an error response, a misconfigured header — it stays valid for a full week. The JWT access token at 30 minutes is fine. The gap between the two is the real exposure window.

What We Fixed

We immediately patched the two code-level vulnerabilities — the ones where a single HTTP request could cause direct harm.

Fix 1 — SSRF in the backfill endpoint

Fix 2 — Path traversal in file-serving endpoints

What We're Still Fixing

The securityContext and NetworkPolicy gaps are real, but they're infrastructure changes that need coordination with the team managing the AKS cluster. The SAS token lifetime will be reduced from 7 days to 1 hour — a config change that first needs verification that no client flow assumes token reuse across sessions.

We're being honest about this: a post saying "we found everything and fixed everything in an afternoon" would be fiction. The code-level bugs are gone. The infrastructure hardening is in progress.

The Actual Takeaway

The Hugging Face incident wasn't about a superintelligent AI exploiting zero-days. It was about an agent that checked everything, relentlessly, until something opened. The vulnerabilities it found were ordinary: a leaked password, overly permissive credentials, an endpoint that trusted too much.

What made it alarming was scale: 17,600 actions over four days. A human pentester might have found the same flaws eventually. The agent found them all, without getting tired.

The practical question for any team isn't "are we theoretically secure?" It's "have we checked ourselves against the things that actually got exploited?"

We hadn't — until we read their post-mortem. It took an afternoon.

All code snippets are simplified. The fixes described are real changes made to a production codebase on the same day we ran the audit.