AI agents are no longer passive assistants. They write code, call APIs, install packages, and interact with production systems. This shift from passive to active changes not only the usefulness of agents, but also the security question around their activities entirely.When an agent can only generate text, the worst outcome is a bad answer. When an agent can execute code, the worst outcome is a deleted production database. That happened last month. 9 seconds, no rollback,no recovery.The question every enterprise team hits sooner or later: how do you safely allow AI agents to execute code and interact with enterprise systems?In a recent post, we outlined a 6-layer defense-in-depth framework for enhancing the security posture of AI agents on Red Hat AI. This post goes deeper into one of those layers: secure sandboxed execution, and how we validated it across various agent frameworks, APIs, and platforms.Running agent-generated code directly on developer laptops, shared infrastructure, or unrestricted runtime environments introduces real risk. Enterprises need isolation boundaries, policy enforcement, credential protection, and runtime audit controls before these systems can be trusted in production.At Red Hat, we have been working on bringing secure sandboxed execution into Red Hat AI through a collaboration with NVIDIA on OpenShell. Today we want to share where we are and what we learned building it.3 ways to sandbox an agentAfter studying more than 20 sandboxing solutions, we found that every approach falls into 1 of 3 modes. Knowing which mode you need matters more than which solution you pick.