AI Agent Sandboxing: Enforcing Authority Boundaries

A coding assistant has been asked to fix a broken customer-notification service. It can read the repository, run tests and edit a working branch. While investigating, it discovers that changing a production configuration would make the test pass. The change looks sensible in the context of its assignment. It is also outside its authority.

This is an illustrative scenario, but it exposes the architectural problem behind many agent deployments. A system can understand a goal and still misunderstand the permission implied by that goal. Improving the model may reduce mistakes. It does not provide an independent boundary around their consequences.

On 7 October 2026, Microsoft announced the general availability of Microsoft Execution Containers, or MXC, a policy-driven containment layer for agent workloads. The significant change is the availability of a runtime mechanism for constraining resource access. It is not evidence that agents have become safe in every enterprise setting. Microsoft's associated Entra and Intune extensions are described as coming soon, so the released containment capability and the future management story should be evaluated separately. Microsoft announcement.

Put authority outside the reasoning loop

The architectural principle is straightforward: the component deciding how to achieve an objective should not be able to enlarge its own authority. An agent may propose a new command or tool call. A separate control must decide whether that operation is permitted.

For an enterprise architect, this suggests separating three decisions. A business owner defines the purpose of the task. A policy owner defines the resources and operations allowed for that purpose. An execution environment enforces those limits while the agent works. These responsibilities may be implemented by different products, but they should remain distinct in the architecture and operating model.

Consider an agent preparing a payment-service change. Its working copy can be writable, while the release configuration remains read-only. A controlled package service can be reachable, while arbitrary internet destinations are unavailable. Production credentials can be absent altogether. The agent can still complete useful engineering work within those limits. If a task requires more authority, the system should expose that need as an explicit exception rather than quietly granting the employee's full access.

This pattern also changes failure handling. A denied request is valuable evidence about a mismatch between task, policy and implementation. It should identify the attempted operation, the relevant boundary and the legitimate next step. Repeated denials must not trigger an automated expansion of permissions merely because expansion would improve task completion.

A sandbox is a location, not a universal guarantee

Microsoft's accompanying GitHub Copilot technical explanation makes a particularly useful distinction. Child processes and local MCP servers can execute inside a process sandbox, while built-in file tools are checked within the agent harness. Remote MCP servers sit outside that local process boundary. Those are different enforcement locations, even when they are presented through one assistant experience. Copilot technical explanation, 7 October 2026.

The implication is architectural, not a criticism of a particular implementation. A remote service remains responsible for its own authorization. Restricting the local shell does not constrain a cloud connector that holds permission to send messages, change a backlog or publish an article. Each path to an external effect needs a control at the point where that effect occurs.

An organization should therefore inventory execution paths rather than approve a product based on the word sandbox. For each tool, it needs to identify where the request is checked, which identity reaches the destination, what data leaves the environment, and what evidence survives. A narrow local policy combined with an overprivileged remote connector still produces an overprivileged workflow.

The inline diagram accompanying this article shows a conceptual division: local commands pass through a runtime boundary; remote business actions pass through service-side authorization. It is a reference pattern, not a diagram of MXC internals.

Local inference does not settle data residency

The same technical publication describes forthcoming routing between local and cloud inference. That is a separate decision from execution containment. An agent can reason locally and call a remote service. It can also use a cloud model while running tightly constrained local commands. Copilot technical explanation.

For a European bank, the relevant unit of analysis is the complete data path. A model-placement setting alone does not reveal where repository content, customer information, tool results or diagnostic records travel. The architecture must account for inference, connectors, package downloads, telemetry and retained outputs independently. This is an architectural assessment, not a claim that a particular configuration satisfies regulatory obligations.

Take a modernization discovery workflow that reads application documentation and produces a dependency assessment. Keeping inference local could reduce one form of external processing. If the same workflow uploads raw documents to a cloud search service or returns sensitive extracts through a collaboration connector, that reduction is incomplete. The correct review follows the actual information flow and the permissions at every destination.

Test the boundary with deliberately wrong requests

A useful pilot would start with one bounded engineering task and synthetic data. Define a writable working directory, a read-only reference directory, approved network destinations and an explicit absence of production secrets. Then verify both success and denial: the task should complete, while an attempted write outside its scope, an unapproved connection and an unauthorized business action should fail visibly.

The last test must occur at the remote service as well as the local runtime. Otherwise the pilot proves only that one execution path is constrained. Teams should also test whether subprocesses inherit the expected restrictions and whether a tool update introduces a new path around the chosen boundary.

Policy exceptions need an owner and an expiry. A temporary grant to diagnose a problem should not become the default for future work. The resulting evidence should connect the task, effective policy, execution identity, requested operation and outcome. Logging a natural-language conversation alone is insufficient for reconstructing an external effect.

The strategic opportunity is the boundary contract

My assessment is that platform containment raises the expected standard for agent orchestration. An open orchestration platform should be able to describe what a workload requires, accept a narrower enterprise policy and report what could not be completed. It should integrate with appropriate runtimes instead of treating access inherited from a user account as the normal execution model.

For Archy, this is a product design direction to evaluate, not a claim of implemented MXC support. Portable workload contracts, service-side action controls and evidence that links a business objective to its effects could provide value across heterogeneous tools. The difficult work is preserving those contracts when execution moves between a developer device, a cloud worker and a remote business service.

For Architech, a concrete consulting engagement would map one existing agent workflow, identify its execution paths, define a least-privilege contract and test that contract against failure scenarios. The deliverable would be a working control design and evidence, rather than another general AI policy document.

Watch the availability and behavior of the announced management integrations, the enforcement differences across supported environments, and the treatment of remote tools. The decisive question is whether an enterprise can explain and demonstrate the limits of an agent's authority. A convincing answer must survive a model choosing the wrong next step.

For the related architecture decisions, see AI Agent Governance: Identity, Authority and Accountability; AI Agent Instruction Governance: Scope, Versions and Audit.