The OpenAI/Hugging Face incident wasn’t fundamentally novel. An attacker exploited a reachable service, obtained code execution, collected credentials, escalated privilege, and crossed trust boundaries. Security teams have seen this sequence a thousand times. What was different was the rate at which it happened, and the fact that a machine was doing it.
Hugging Face reconstructed approximately 17,600 attacker actions across four-and-a-half days. Put thirty seconds of human review on each action and you get 147 hours of work. Even clustered into 6,280 groups, that’s still 52 hours of triage. Manual approval was never a plausible primary control for this workload.
I think about this problem differently now. The useful mental model is a capable attacker fused with a fuzzer: reasoning about results, probing without fatigue, rebuilding from failure, continuing from another environment without starting over. That’s the AI part of the story. The security question is deceptively simple: what authority should you give a workload that can execute code, hold credentials, reach the network, and keep testing paths long after a human would have stopped?
The Arithmetic Changes Everything
The individual weaknesses exposed during the incident were familiar: unsafe processing paths, accessible cloud metadata, broad privileges, long-lived credentials. A capable human attacker could have chained them too. The difference was the volume of paths tested simultaneously, the speed at which a failed approach was abandoned, and the sheer amount of evidence defenders had to interpret while the campaign continued.
This arithmetic is what changes the operating model. You cannot sit in the control loop for thousands of actions at machine speed. Approval workflows designed for humans become denial-of-service vectors when applied to agents. But removing all friction eliminates the guardrails entirely.
The answer is not binary. Routine and reversible actions should have minimal friction. More sensitive, external, destructive, or unusual actions deserve stronger scrutiny. The point is making friction proportional to consequence, not uniform across all operations.
Constrain First, Observe Always
I use agents daily, and I assume that any sufficiently capable agent will eventually try something I didn’t anticipate. I don’t run a single general-purpose agent with access to everything. Instead, I use task-focused agents, each packaged separately, built on hardened container images and run in isolated sandboxes.
My research agent has broad internet access because desk research requires it. But the image has no compilers, no package manager, no development toolchain. It can retrieve and analyze public information, but has very little machinery to turn something it encounters into an exploit or act on another system. It has no reason to hold my source code or production credentials.
My production coding agent is deliberately richer. It can compile, test, use multiple models, and access an explicit allow list of services: Docker, GitHub, Snowflake, Cloudflare. It doesn’t receive arbitrary internet access simply because a coding task occasionally needs the network. The home kit can interact with an Arduino, but only through a host-side MCP server that brokers allowed operations. The agent sees the capability I chose to expose, not the underlying credential.
These are deliberately different environments. The research agent would be poor at production coding. The coding agent cannot reach arbitrary APIs. This compartmentalization is not about limiting my own agents from misbehavior; it’s about creating a deterministic enforcement boundary where I can apply least capability and least privilege, and observe what’s actually happening.
The Observation Problem Remains Unsolved
There’s still substantial work ahead for everyone. The useful unit of observation is not always a single tool call. It may be a burst of activity, a target, a protocol, a credential, or a pattern visible only across multiple systems. A package request can be normal. Repeatedly probing the service behind it, discovering credentials, and using them to reach another system should trigger escalated scrutiny.
That’s the challenge beyond basic containment: constrain authority, but also observe activity at the right granularity, recognize when it deserves more scrutiny, and respond at agent tempo. Cross-system detection costs money and produces false positives. An approval inserted at the wrong point can eliminate most of the productivity the agent was supposed to provide.
Teams will be tempted to loosen controls until the agent works again. That’s understandable. The failure mode created by strict policy is immediate and visible; the failure mode created by excessive authority remains invisible until incident day. The answer is not to remove the controls or ask humans to approve everything. It’s to measure the operational cost against the risk and potential blast radius. Learn more about security governance and container hardening to understand how these pieces fit together.
Security, capability, and autonomy will always be in tension. None of this is free. The question is whether you’re paying the cost upfront through architectural discipline, or in arrears through incident response.