MXC - Containing agents on your local machine

Summary

The video explains how MXC can contain AI agents and agent-generated code on a local machine by applying a consistent, policy-based configuration across different operating systems.

Why Containment Matters

Programs normally run as processes in user space, with their own memory and some isolation from other processes. However, processes may still share the operating system’s kernel, and software running under a user’s account may inherit that user’s access to files, networks, and other resources.

Because AI-generated code and agent behavior can be unpredictable, the presenter argues that users and developers need ways to limit what an agent can access or do.

Isolation Options

The video presents a rough progression from less to more isolation:

1. Separate process: Keep the workload in its own process and restrict its access to resources.
2. Separate session or identity: Give it a distinct workspace or account while still sharing the host kernel.
3. Container with a different kernel: Useful, for example, when running Linux workloads on Windows through WSL.
4. Virtual machine: Run the workload in a separate environment with its own kernel.
5. Different device or cloud environment: Move the workload completely off the local machine.

The appropriate level depends on how much the user trusts the workload. The presenter notes that operating systems offer different isolation mechanisms and levels.

What MXC Provides

MXC lets developers describe a workload, its isolation level, and its restrictions in an OS-independent JSON manifest. MXC translates that configuration into platform-specific mechanisms:

• Windows: Application Container technology for process isolation
• macOS: Seatbelt
• Linux: Bubblewrap

Policies can control access to files, network traffic, and interface features such as the clipboard or simulated keyboard and mouse input. The video also mentions SDKs for Rust, .NET, and Node, along with documentation, examples, and diagnostic tools.

Demo and Guide

The presenter demonstrates a PowerShell probe that tries to read and write a file, list processes, and access a website. The same test is run under progressively more permissive policies:

• Block everything: File and network access fail, while process listing still works.
• Read-only file access: Reading succeeds; writing and network access remain blocked.
• Read/write file access: Both file operations succeed.
• Outbound HTTPS access: A request over port 443 succeeds, but file writing remains blocked.
• Combined permissions: File operations and network access both succeed.

The demo also shows how to validate a manifest’s syntax before running it and explains that required runtime files—such as scripts or PowerShell—may need to be explicitly allowed.

Learning and Monitoring Modes

Rather than immediately blocking everything, MXC can be configured to block and record or allow and record activity. This provides telemetry to help determine what access a workload actually needs, allowing policies to be tightened without breaking useful functionality.

Identifying Agent Processes

The video separately notes that Windows 11 supports adding metadata to processes to identify them as agents. This can help Microsoft and third-party security tools distinguish agent activity from the user’s own actions and apply risk controls accordingly. The presenter clarifies that this is separate from MXC itself.

Main speaker/source: John Savill, presenting an overview and hands-on demonstration of MXC.