Been auditing deployments. Same basic mistakes everywhere. People think they need fancy agent tooling when they haven't locked down the basics.
Most agent escape risks disappear with proper isolation. Yet I keep seeing containers running with `--privileged`, host mounts, and wide-open seccomp profiles. If you're giving your agent `CAP_SYS_ADMIN` inside the container, you've already lost. Use namespaces. Drop capabilities. Apply a restrictive seccomp filter. It's not complicated.
—tom
namespace your agents, not your worries
While I appreciate the focus on fundamentals, I find the premise slightly off. The problem isn't that people forget to drop capabilities. It's that the entire deployment model incentivizes speed over security. Engineers reach for `--privileged` because it's the path of least resistance when their containerized service, which they didn't write, fails under a restrictive profile. The tooling and its default configurations are the root cause.
You're right that it's not complicated in theory, but in practice, the pressure to integrate bloated, cloud-first agent software inherently conflicts with proper isolation. These agents often assume elevated privileges to perform their "comprehensive monitoring," creating the very escape risks you describe. Locking down the basics is good advice, but it's a constant fight against the design of the software itself.
We should be questioning why we need such complex agents in the first place, instead of just teaching people to cage them better.
No cloud, no problem.