Docker Inc. has added a governance framework through which organizations can limit and manage the IT resources artificial intelligence (AI) agents can access.
The Docker AI Governance framework provides a means to centrally manage everything from how AI agents execute, what they can reach on the network, which credentials they can use, and which Model Context Protocol (MCP) tools they can call.
Based on a micro virtual machine (MVM) the company developed to run workloads more securely, the Docker AI Governance framework adds a complementary control plane to Docker Sandbox, a runtime environment that Docker introduced earlier this year to run AI agents safely. Every agent session runs inside a microVM-based isolated environment where filesystem and network access are controlled by a hard boundary.
Every tool call is then routed through an MCP gateway that Docker also launched earlier this year to provide a single chokepoint where access can be authenticated, authorized, and logged as AI agents access external systems.
At the same time, every agent session runs inside an isolated sandbox where only approved endpoints are reachable and only approved directories are mountable, with enforcement happening at the proxy and mount level. Docker AI Governance controls which credentials, tokens, and secrets an agent session can see, scopes them to the duration of that session, and blocks exfiltration to unapproved destinations. There is no longer a need to paste tokens into prompts, and every policy update is applied any time a machine connects.
From a single admin console, IT and cybersecurity teams gain access to a neutral layer that can then define and enforce policy across four control surfaces: network, filesystem, credentials, and MCP tools that consistently works across thousands of machines, says Srini Sekaran, principal product marketer of AI at Docker. “It enables complete visibility,” he says.
The goal is to apply a set of granular controls at the runtime layer where the agent actually executes, rather than relying on advisory rules or guardrails that a prompt might enable an AI agent to route around in a way that could, for example, lead to a production database being deleted, says Sekaran.
There are, of course, multiple ways to now securely deploy AI agents using various runtimes. Each organization will need to determine which approach makes the most sense for them and, in many cases, it’s probable they may employ multiple runtimes to safely deploy AI agents. Additionally, organizations will need to determine which teams in their IT organizations will ultimately assume responsibility for ensuring that AI agents have been safely deployed. In most instances, that responsibility might initially fall to a cybersecurity team before being passed over to an IT operations team to implement.
Regardless of approach, the one thing that is clear is that in terms of upgrading IT environments, to ensure AI agents are deployed safely, there remains much work to be done. The challenge now is to create the secure runtimes needed to responsibly deploy thousands of AI agents before any potential agentic AI havoc might otherwise ensue.
