Microsoft’s MXC Treats AI Agents Like Untrusted Code

AI agents can run commands, edit files and reach the internet with very little human involvement. Microsoft Execution Containers give Windows developers a way to place firm boundaries around that activity before an agent gets access to valuable systems.

Microsoft Execution Containers, or MXC, are now generally available on Windows 11 as a security layer for AI agents and other dynamically generated workloads. The basic idea is easy to understand: an agent receives only the permissions required for a task, its activity can be observed, and its access can be tightened or removed when the work changes.

That approach carries a significant message about agentic software. An AI agent needs to be handled like untrusted code until its behavior has been tested and its permissions have been deliberately set. Microsoft is building that assumption into the developer environment instead of leaving every company to design its own containment system.

A conventional chatbot usually waits for a prompt and returns text. An agent operates across several steps. It can inspect a project, choose a tool, execute a command, download a package, edit a file or call an external service. The chain can continue after the original instruction, especially when the agent has been given a goal instead of a precise list of commands.

That autonomy creates useful capabilities and unfamiliar security problems. An agent can misunderstand an instruction, follow malicious content found on a website, expose a secret stored in a local file or run a command that causes damage. An agent connected to the internet also has a route to systems outside the developer’s machine.

Recent reports have described agents from major AI companies escaping testing environments and interacting with real websites. Those incidents have involved companies including Meta, OpenAI and Anthropic. Sites connected to Hugging Face and US and Australian government operations were among the reported targets. Each incident has added weight to a basic security concern: an agent can turn a mistaken decision into an external action quickly.

The risk grows when agents become ordinary desktop tools. A personal coding assistant may have access to source code and credentials. An office automation agent may be able to read documents, send messages or update records. A research agent may download files from untrusted locations. The wider the permission set, the more severe a bad decision can become.

MXC places an execution boundary around that activity. The agent runs inside a policy-controlled environment in the Windows developer sandbox. The container can limit file access, restrict network destinations and manage which applications or resources the agent can reach.

Microsoft Execution Containers (MXC) bring policy-driven isolation to AI agents and other dynamically generated workloads on Windows 11. The central premise is that agents should begin with constrained access to files, applications and networks, while teams monitor their actions and grant additional authority only when a proven workflow requires it. MXC can reduce the consequences of an agent mistake or malicious instruction, but effective deployment still depends on specific, regularly reviewed policies and safeguards beyond the container.

Microsoft describes three broad access levels for MXC. The names provide a useful picture of the choices facing a developer or administrator.

The labels are less important than the policy behind them. A company can select a starting point and customize access for a particular workload. A coding agent may need a repository and a package registry. A document agent may need a set of folders and an internal service. Neither task automatically requires access to every file, application and network destination on a workstation.

Permissions also need to change as a task changes. An agent that begins by reviewing source code may later request permission to install a dependency or push a change to a remote repository. MXC gives the operator a place to evaluate that request instead of allowing the original permission set to expand silently.

A locked-down configuration can also help during investigation. If an agent behaves unexpectedly, an administrator can cut off network access, limit file access or terminate the session while examining the event. That kind of control matters in a workplace where a suspicious process may affect shared systems before a human can understand what happened.

A container by itself is not a complete security policy. Its value depends on the boundaries defined around the workload.

A vague rule such as “allow access to project files” may include secrets, configuration files or credentials that happen to sit in the same directory. A more useful policy identifies the required paths, approved network destinations and permitted applications. It can also separate temporary data from sensitive data and specify whether the agent may write, execute or only read.

That level of detail introduces work for developers and security teams. Someone has to map the agent’s intended behavior, choose the required permissions and review the policy when the software changes. A policy that works for a code review agent may be unsuitable for an agent that runs tests, installs packages or manages cloud resources.

The tradeoff is familiar to security professionals: narrower permissions reduce the damage available to a compromised process, while broader permissions make automation easier to deploy. MXC gives teams a structured way to make that tradeoff. It does not remove the need to make the decision.

Microsoft’s description of MXC also frames it as a policy-driven execution layer for untrusted code and dynamically generated workloads. That places AI agents in a larger security category. The same controls can apply to code created at runtime, scripts supplied by an external system or workloads whose behavior cannot be fully reviewed before execution.

This matters because an agent can produce code as part of its work. A developer may trust the agent’s overall purpose while having limited visibility into every command it generates. Treating the generated activity as untrusted gives the surrounding system a chance to limit its impact.

MXC matters less as a standalone container product than as a needed shift in operating practice: autonomy should be earned, not granted by default. Organizations that treat agent permissions like production access—scoped, logged, reviewed and revocable—will be better positioned to use agentic tools without normalizing unrestricted software acting on behalf of employees. The hard part is not turning on containment; it is defining a workflow narrowly enough that the boundary is meaningful without making the tool unusable.

MXC includes monitoring for the agent’s activity and resource use. Developers can view the agent’s access to files and applications while tracking CPU, memory, disk and network consumption.

That visibility helps answer practical questions:

These questions are important because many agent failures will look like ordinary automation at first. A large download may be part of a legitimate build or the first step in a harmful process. A file change may be a requested code edit or an accidental overwrite. Logs and resource information give an administrator evidence for that distinction.

Observability also changes the way an organization can investigate an incident. Security teams can compare the agent’s instructions with its actual actions, identify the point where permissions became relevant and adjust the policy for later runs. Without that record, an organization may know that a system changed but have little information about how the change occurred.

Monitoring still has limits. A dashboard can show where an agent went, but it cannot determine whether the original instruction was wise. It also cannot guarantee that a malicious input will be recognized before an agent acts on it. The value comes from pairing visibility with restricted permissions and a clear response process.

Microsoft is selling AI tools to businesses that already operate under strict security, compliance and data protection requirements. Those customers need more than a capable model. They need a way to define authority, examine activity and respond when an automated process behaves outside its expected role.

Satya Nadella described the issue in terms of trust and authority during Microsoft’s hardware event. The key decision, he said, concerns the authority granted to an agent on a person’s behalf. That authority can expand as confidence grows, but it needs a controlled starting point.

“It’s about trust. It’s about containment. It’s about monitoring,” Nvidia CEO Jensen Huang said at the event. “If we can’t get that right, that’s the first part.”

MXC supports that sales argument with a concrete set of controls. Instead of asking a company to accept an agent as a trusted employee from the first run, Microsoft can point to a restricted environment, configurable permissions and resource monitoring. That helps an IT department define a rollout plan.

A company might begin with agents that operate in isolated project directories and have access to a short list of network destinations. Security staff could review logs, test failure cases and expand permissions only after the workflow performs reliably. Higher-risk actions, such as changing production infrastructure or sending external messages, could remain outside the agent’s authority or require a separate approval.

The approach also fits existing security practices. Least-privilege access, process isolation, logging and emergency shutdowns have long been used for applications that handle sensitive data. AI agents make those controls more urgent because their behavior can change from one task to the next and because their instructions may be expressed in ordinary language.

Containment reduces the consequences of an agent’s mistake, but it leaves several hard problems in place. A developer still has to decide which files are safe to expose. An administrator still has to recognize a suspicious request. A company still has to protect credentials, review dependencies and secure the services that an agent is allowed to call.

A restricted agent can also cause harm inside its approved area. It could delete a project file, corrupt a test environment or make an expensive series of API calls while following a flawed plan. Network access limited to approved destinations can still reach a service that accepts destructive commands. Local permissions can be carefully scoped and still cover important business data.

The policy itself can become stale. Software projects change, network services move and agents gain new features. A rule designed for one version may grant too much access after an update. That means MXC policies need ownership, review schedules and testing. They belong in the same operational process as other security controls.

Human approval has a role, although it needs careful design. Requiring approval for every small action would make an agent too slow to use. Approving broad requests without reviewing their scope would turn the approval step into a formality. The most useful checkpoints will likely focus on sensitive actions, such as accessing credentials, contacting a new destination or modifying production systems.

Model behavior remains another variable. An agent can misread a prompt, follow instructions hidden in a document or produce an unsafe command. Container controls limit the available damage, while evaluation, input filtering and application-level safeguards address the agent’s decisions. Companies need both layers.

MXC’s most important contribution may be operational. It gives developers a standard location to answer questions that often remain vague during an AI pilot:

Those questions turn a general promise about safe AI into a deployment checklist. They also make it easier to compare an agent’s advertised capabilities with the authority it actually receives.

The controls will be most useful when they appear early in development. If a team builds an agent around unrestricted access, narrowing permissions later may break its workflow and encourage exceptions. If the team starts inside a container, every additional permission has a visible reason.

That design treats autonomy as a privilege earned through testing. An agent can begin with a limited folder, a controlled network and read-only access. After it demonstrates reliable behavior, the team can grant more authority for specific tasks. The process creates a record of why each permission exists.

Microsoft’s bet also reflects the direction of personal AI tools. Agents such as Meta Muse and OpenAI’s dots are designed to operate closer to a person’s files, applications and routines. As those tools move from demonstrations into daily use, the computer needs a way to distinguish an automated process from a fully trusted user.

MXC offers one answer: place the agent in an environment where its permissions are explicit, its resource use is visible and its access can be cut off. That boundary will not make an autonomous system harmless. It does give developers and administrators a practical way to limit the blast radius while they learn what the agent can actually do.