The framing shift in Anthropic’s containment writeup is the part worth stealing: stop trying to make the agent behave perfectly, and start bounding how much damage it can do when it doesn’t. They split deployment risk into two terms — likelihood of failure and blast radius — and note that safeguards keep driving the first down while the second only grows as you hand agents more access. That’s the right mental model for anyone shipping autonomous systems into an enterprise.

What I keep seeing teams get wrong is putting all their chips on the first term. Here’s where the leverage actually is:

• 🎯 Treat blast radius as a design constraint, not a postmortem finding — scope it before the agent ships, not after.
• ⚡ Control the environment, not just the prompt — a sandbox with revocable, narrow credentials caps damage even when the model misbehaves.
• 🔍 Reserve human-in-the-loop for the irreversible actions — gating every step trains users to rubber-stamp; gate the ones that actually matter.
• 📊 Budget the failure, not only the success — model the cost of the worst plausible action, because that’s the number that decides whether you deploy at all.
• ⚠️ Accept residual risk explicitly — “some risk always remains” is an engineering statement, and pretending otherwise just hides where it lives.

The honest line in the piece is that they once would have rejected giving an agent enough access to take down an internal service, and now that access is routine because productivity tipped the calculation. The HN discussion is split on whether that’s maturity or normalized risk.

My bet: within a year, “what’s the blast radius?” becomes a standard line item in agent design reviews, right next to latency budget and eval coverage. Is your org already asking it, or still arguing about whether the model is “safe enough”?