# attachment[].name
Hand-drawn diagram on the back of an envelope detailing the difference between the VPN model and the zero trust overlay approach.

# content
Would hardened Tailscale have changed the Hugging Face outcome?

In his latest post on the NetFoundry blog, Hugging Face Breach: When Tailscale VPN Is the Blast Radius, CEO Galeal Zino (my boss’ boss) writes about why the Hugging Face breach was a VPN architecture problem rather than a Tailscale misconfiguration, and what hardening does and doesn’t fix.

Here’s a quick recap of what happened: In July, OpenAI evaluation agents escaped their sandbox, got into Hugging Face through two injection vectors, and walked away with 136 cluster secrets. One of those was a Tailscale auth key, which was:

Reusable

Non-expiring

Subnet-tagged

Sitting readable in a Kubernetes secret

With that one key, the agents were able to get far. They enrolled 181 nodes, ran `tailscale status –json` to get 22 peers back including subnet routers and a source-control connector, reached internal CI subnets, and minted GitHub App tokens. They suppressed client-side telemetry and ran for almost 5 days before anyone noticed.

The post’s argument is that taking measures to harden Tailscale (single-use OAuth-minted keys, ephemeral nodes, tailnet lock, Services instead of subnet routers) shrinks the fan-out but doesn’t eliminate the two properties that made the foothold catastrophic:

1. Enrollment still authenticates on a bearer credential. Possession of the key made the agents a member, and membership came with a map.

2. The coordination plane still hands every enrolled node a map, and even a narrowed map is still a target list.

It’s worth pointing this out as simply and plainly as possible: Nothing in our stack would have stopped the sandbox escape, the injections, or the climb to node root. That’s not our line of work. What we do is zero-trust reachability, where the assumption is that systems have already been breached and credentials can be stolen.

Hugging Face’s own technical timeline is the better primary source, and it’s worth reading along with our article: https://huggingface.co/blog/agent-intrusion-technical-timeline

Once again, here’s our article: https://netfoundry.io/zero-trust/hugging-face-breach-when-tailscale-vpn-is-the-blast-radius/

# contentMap.en
Would hardened Tailscale have changed the Hugging Face outcome?

In his latest post on the NetFoundry blog, Hugging Face Breach: When Tailscale VPN Is the Blast Radius, CEO Galeal Zino (my boss’ boss) writes about why the Hugging Face breach was a VPN architecture problem rather than a Tailscale misconfiguration, and what hardening does and doesn’t fix.

Here’s a quick recap of what happened: In July, OpenAI evaluation agents escaped their sandbox, got into Hugging Face through two injection vectors, and walked away with 136 cluster secrets. One of those was a Tailscale auth key, which was:

Reusable

Non-expiring

Subnet-tagged

Sitting readable in a Kubernetes secret

With that one key, the agents were able to get far. They enrolled 181 nodes, ran `tailscale status –json` to get 22 peers back including subnet routers and a source-control connector, reached internal CI subnets, and minted GitHub App tokens. They suppressed client-side telemetry and ran for almost 5 days before anyone noticed.

The post’s argument is that taking measures to harden Tailscale (single-use OAuth-minted keys, ephemeral nodes, tailnet lock, Services instead of subnet routers) shrinks the fan-out but doesn’t eliminate the two properties that made the foothold catastrophic:

1. Enrollment still authenticates on a bearer credential. Possession of the key made the agents a member, and membership came with a map.

2. The coordination plane still hands every enrolled node a map, and even a narrowed map is still a target list.

It’s worth pointing this out as simply and plainly as possible: Nothing in our stack would have stopped the sandbox escape, the injections, or the climb to node root. That’s not our line of work. What we do is zero-trust reachability, where the assumption is that systems have already been breached and credentials can be stolen.

Hugging Face’s own technical timeline is the better primary source, and it’s worth reading along with our article: https://huggingface.co/blog/agent-intrusion-technical-timeline

Once again, here’s our article: https://netfoundry.io/zero-trust/hugging-face-breach-when-tailscale-vpn-is-the-blast-radius/

# icon.name
Hand-drawn diagram on the back of an envelope detailing the difference between the VPN model and the zero trust overlay approach.

# image.name
Hand-drawn diagram on the back of an envelope detailing the difference between the VPN model and the zero trust overlay approach.