CSIPE

Published

- 20 min read

Project Zenith Puts AI on the PC. Its Security Boundary Is Still a Preview

AI Agents Application Security Windows

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

A new developer PC arrives. It can run a large language model locally, it comes with the usual coding tools ready, and the operating system offers a place to contain code produced by an agent. That sounds much safer than giving a cloud agent a shell on an ordinary laptop.

The last sentence hides the important question. Safer in what way, against which action, and enforced by which part of the machine?

Microsoft announced Project Zenith on 4 September 2026 as a ready-to-code Windows 11 experience for developer-class computers. The first machines are expected to use AMD Ryzen AI Halo hardware. Microsoft set a baseline of at least 64 GB of unified memory and 250 GB/s of memory bandwidth, enough to run some models with more than 30 billion parameters locally, according to both the Microsoft announcement and independent reports from Help Net Security and Tom’s Hardware.

The security part deserves more attention than the hardware number. Microsoft says the experience will include operating-system-enforced identity, Microsoft Execution Containers, and management controls for agents. Yet the public Microsoft Execution Containers repository currently carries an unusually direct warning: its code is an early preview, some generated policies are known to be too permissive, and no current profile should be treated as a security boundary. That warning does not make Project Zenith a bad idea. It tells developers exactly how to evaluate it: welcome the direction, then test the boundary that actually ships.

What Microsoft announced, and what it did not

Project Zenith is better understood as a prepared developer workstation than as one magic security feature. The announced experience combines capable local-AI hardware, a quieter Windows configuration, preinstalled development tools, Windows Subsystem for Linux support, and platform features intended to govern agents. The attraction is easy to see. A developer can unpack a machine and begin work without spending the first afternoon installing runtimes, changing File Explorer settings, and moving every model interaction through a metered cloud service.

The local model is the headline because 30 billion parameters is an easy number to compare. It is also the least interesting security guarantee. Running a model on the desk can keep a prompt away from a remote model provider, reduce dependence on an internet connection, and change the cost of repeated inference. It does not automatically stop the model’s tools from reading a private key, changing a repository, launching a process, or sending data through another application.

Location and authority are different properties. A local calculator has little authority. A local coding agent may inherit the logged-in developer’s files, browser sessions, cloud command-line credentials, package-publishing token, source-control identity, and access to the company network. Moving inference from a data centre to a laptop changes where model computation occurs. It does not answer what the resulting process can cause.

Microsoft’s announcement points toward a stronger answer. Its agent security model includes a distinct identity, containment through Microsoft Execution Containers (MXC), and enterprise management. In plain English, the goal is to know which agent acted, place its code inside a constrained workspace, and let administrators set and inspect rules across a fleet. Those are the right layers. A prompt window alone cannot provide them.

There are limits to what was announced on 4 September. Project Zenith is not yet a general download for any existing laptop, and Microsoft has not published a complete, final security contract for every Zenith configuration. Independent coverage describes first systems based on AMD Ryzen AI Halo and more hardware partners later, but exact device dates and final policies remain product details to watch. As of 8 September 2026, the public material supports a direction, not a claim that every coding-agent workload has gained a finished isolation wall.

That distinction matters because developers routinely turn a named feature into a broad assumption. “Runs in MXC” can become “cannot touch the host” in a design review even when a selected backend shares part of the host, permits outbound traffic, or mounts more files than the reviewer realised. The name is useful shorthand. It is not evidence.

Local inference moves the risk instead of deleting it

Imagine a developer asks a local model to upgrade a dependency and fix the resulting tests. The model reads the repository, edits three files, runs the package manager, follows a link in an error message, and opens a pull request. No source code needed to become a prompt sent to a cloud model. That is a genuine privacy benefit.

The agent still crossed five boundaries. It read local files, wrote to the working tree, executed package scripts, reached the public internet, and used a source-control identity. A malicious package instruction, a poisoned repository file, or a simple model mistake can travel along those same paths. The model’s weights sitting in local memory do not make any of those paths narrower.

This is why “local” should appear in an architecture diagram as the location of inference, not as a green security check over the whole system. The useful questions are more specific. Which directories are readable? Which directories are writable? Can child processes escape the same policy? Can the workload reach arbitrary internet hosts? Which credentials exist in its environment? What human or automated gate stands between a generated change and a release?

A local model can even increase the need for clear limits. Cheap, low-latency inference encourages longer runs and more automatic retries. A developer may let an agent inspect a larger repository, run a broad test suite, or work while the screen is locked because each step no longer consumes an obvious cloud token budget. More useful autonomy means more opportunities for one mistaken instruction to meet a powerful tool.

The practical failure is rarely a cinematic “model escape.” It is usually ordinary authority used in the wrong context. The agent reads a configuration file because it is inside the project tree. A test command inherits a cloud token because the developer’s shell had it. A package installer runs a project hook because that is normal package-manager behaviour. An outbound request reaches an unapproved host because nothing below the model was told to refuse it.

Project Zenith is interesting precisely because Microsoft is trying to put controls below the chat interface. Operating-system identity and execution policy can still act when the model is confused, when an approval request looks harmless, or when generated code behaves differently from its description. But the control only works to the extent that its configured backend and policy enforce the intended limit.

A useful mental model is a workshop. Keeping the worker inside your building stops work from being performed at a remote contractor’s premises. It does not decide which cupboards the worker can open, whether the loading bay is unlocked, or who may approve a shipment. Those remain separate controls. Local AI solves the location question. The workstation still needs answers for access, execution, communication, and release.

What MXC currently promises

Microsoft describes MXC as a sandboxed code-execution system for model output, plugins, and tools on Windows, Linux, and macOS. The public repository exposes one policy shape across several containment backends, including Windows process containers, Windows Sandbox, WSL containers, Bubblewrap and LXC on Linux, Seatbelt on macOS, and experimental virtual-machine options. That common interface is valuable because agent builders otherwise write one collection of ad hoc subprocess rules per operating system.

The policy model covers the places where coding agents usually gain unintended reach. It can describe read-only and read-write file paths, govern outbound network access, constrain clipboard and display access, set a timeout, and record execution diagnostics. A developer can ask for a temporary writable directory while keeping source tools read-only and denying outbound traffic. The public TypeScript example does exactly that for a short Python process.

The design also separates policy from backend. That sounds like an implementation detail, but it is central to the security argument. “Run this command with no outbound network and only these writable paths” is the intended policy. A process container, a Linux namespace tool, or a small virtual machine is the mechanism chosen to enforce it. Teams can keep one higher-level contract while selecting different mechanisms for different trust levels and host platforms.

The mechanisms do not offer identical strength. MXC’s own documentation lists backend-dependent network filtering, notes that denied file paths are not yet supported on Windows, and labels several backends experimental. Microsoft’s general Windows container security guidance also makes a broader point: process isolation that shares a host kernel is not the same security boundary as hypervisor isolation for hostile multi-tenant work. Faster containment can be appropriate for many developer tasks, but speed does not turn every backend into a virtual machine.

This is the heart of the current warning. The MXC repository says the preview is published for early integration and feedback. It says the underlying sandboxes may change, acknowledges known cases where generated policies are too permissive, and tells readers not to treat current profiles as security boundaries. Those are Microsoft’s words as of 8 September 2026, not an inference drawn from a missing feature.

The warning and the Zenith announcement can both be true. Microsoft can ship a developer experience with agent security features from day one while the public integration code remains a preview whose profiles are not yet ready to carry a strong boundary claim. A production image may include newer components or a restricted configuration. It may also expose preview features for developers to test. Until final device documentation names the version, backend, policy, and support status, buyers should avoid filling that gap with optimism.

This is good security communication. Teams often hide preview limitations behind a generic “use at your own risk” note. Here, the repository states the exact conclusion a reviewer must not draw. The right response is to preserve that honesty through procurement, design review, and rollout rather than letting the shorter product message erase it.

A container name is not a threat model

A team cannot choose sensible containment until it names the workload it distrusts. Generated code is one source of risk, but coding agents also execute ordinary tools whose behaviour depends on local files, package metadata, environment variables, and network responses. The boundary has to cover the whole process tree and every route by which that tree can affect something valuable.

Start with the asset, not the product. On a developer machine, the valuable asset might be an SSH key, a browser session, a cloud credential, an unpublished branch, a signing identity, customer data in a test fixture, or the ability to publish a package. Each asset has a path by which an agent could reach it. Some paths are files. Others are local sockets, command-line helpers, desktop automation, inherited environment variables, or a service already logged in as the developer.

Now name the action that would hurt. Reading a private repository is different from overwriting it. Changing a local file is different from pushing a branch. Downloading public documentation is different from sending a source archive to the same host. A policy that says only “network allowed” collapses all of those effects into one switch and usually gives away too much.

A realistic example is a dependency update. The agent needs to read the repository, write to a disposable branch, resolve packages from a known registry, and run tests. It does not need the developer’s personal home directory, production cloud credentials, the browser profile, arbitrary internet destinations, or direct permission to merge. If the package manager requires a private registry token, that token can be minted for a narrow repository and a short time rather than copied from the host’s long-lived configuration.

The selected backend must then match the consequence. For a trusted internal script whose main risk is an accidental write, lightweight process containment may be enough. For code taken from an unreviewed archive, a public pull request, or a package whose install scripts will run, stronger isolation is justified. If the workload is actively hostile, a shared-kernel process boundary should not be promoted into a promise it cannot support. Use a disposable virtual machine or equivalent boundary and keep release credentials elsewhere.

Identity belongs in the same model. A distinct agent identity is useful only when downstream services actually recognise and restrict it. If an agent process ultimately calls Git through the developer’s existing credential helper, an audit log may say “Kubilay pushed” even if an agent performed every step. The separate identity has to survive the path to source control, cloud APIs, ticket systems, and deployment tools. Otherwise it is a local label attached to actions authorised as a human.

Project Zenith’s three layers make sense only together. Containment limits the process. Identity limits and attributes service access. Management makes policy visible and repeatable across machines. Remove any one layer and the story weakens. A named agent with the developer’s full filesystem can still copy secrets. A contained process using the human’s production token can still deploy. A good policy on one laptop does not protect a fleet that silently drifted.

The policy must survive real tools

A policy file can look narrow while the actual workload finds a side door. Coding tools are built to connect systems: package managers launch scripts, source-control clients invoke helpers, browsers hand links to other applications, and test frameworks start local servers. The first proof of a boundary is therefore behavioural, not visual. Run representative tasks and observe what crosses it.

Filesystem tests should include more than opening a forbidden file directly. Ask whether a child process can read it, whether a symbolic link crosses from an allowed directory into a denied one, and whether a tool can reach it through a local service. Check temporary directories and caches. A clean project mount does little if the process also receives the user’s entire home directory through a convenience setting.

Network tests need the same discipline. MXC can express outbound controls, but support varies by backend and platform. A team should verify domain resolution, direct IP connections, redirects, proxy use, local network routes, and calls made by child processes. “No internet” is incomplete if the process can talk to a host-side proxy that has internet access. “Only the package registry” is incomplete if an approved host can redirect the client somewhere else and the policy follows the destination without another check.

Credentials require a negative test. Start the workload with no inherited secrets and ask a harmless probe to enumerate what it can see: environment-variable names, mounted credential directories, active local sockets, credential helpers, and cloud metadata routes. The test should use fake values and documentation addresses, not production secrets. The result becomes evidence that the container received only the identity intended for that task.

MXC’s audit or learning mode needs particular care. The repository explains that permissive learning mode records operations that would have been denied while allowing them to proceed. That can help an engineer discover which files and calls a legitimate workflow needs. It is not containment during that run. Using it on untrusted code against a normal developer profile would give the code the access the team is merely trying to observe.

A safe policy-authoring loop begins with a disposable machine and synthetic data. Run the legitimate task in learning mode, review each observed access, produce a narrow candidate policy, and then switch to enforcement. After that, add tests that attempt forbidden effects and fail the build if any succeeds. Learning tells you what ordinary work tried to do. Adversarial tests tell you whether the wall refuses what ordinary work should never do.

The evidence should name the environment. Record the Windows build, MXC version, selected backend, policy schema, agent version, and test cases. A pass on one backend cannot be copied to another by changing a configuration field. Nor should a pass survive a major update automatically. When the executor or operating system changes, rerun the boundary tests before restoring the agent’s former authority.

A practical rollout for a local coding agent

A Project Zenith machine should enter a team as a measured workstation, not as a pre-approved exception to existing controls. The first deployment can be small. One developer, one representative repository, no production credentials, and a defined set of tasks will reveal more than a month of arguments over the word “sandbox.”

The sequence below works for Zenith when devices arrive, and it also works for any current local-agent setup.

  1. Write down one allowed task. Choose something bounded, such as updating a library on a disposable branch and running unit tests. State the allowed inputs, expected files changed, approved network destinations, maximum runtime, and where the result may go. “Help with the repository” is too broad to test.

  2. Remove ambient authority from the host session. Do not start from a shell full of production tokens. Use a test account or disposable virtual machine, clear inherited credential variables, avoid mounting browser and SSH profiles, and disable access to local management sockets. Give the task a short-lived credential only if the task cannot work without one.

  3. Select the containment backend by consequence. A fast process container may suit a low-impact, trusted workflow. Unreviewed repositories, package install scripts, and hostile samples deserve a stronger virtual-machine boundary. Record the choice explicitly. Do not let a framework silently select a weaker fallback when the preferred backend is unavailable.

  4. Default to no network, then open named routes. If the task needs a package registry, allow that route through a controlled proxy and inspect redirects. Keep internal services, cloud metadata addresses, the local network, and arbitrary destinations closed. The computer should have no quiet way out simply because the model runs locally.

  5. Separate agent identity from developer identity. Use a dedicated source-control or automation identity with access only to the test repository and branch operation it needs. Make direct merge, release, and deployment unavailable. Logs should show the agent identity rather than attributing every automated act to the person at the keyboard.

  6. Test forbidden effects before trusting useful work. Try to read a fake secret outside the mount, write beyond the workspace, reach an unapproved documentation address, invoke a host credential helper, and push to a protected branch. Every attempt should fail below the model. A refusal in chat is not a passing result because the model can phrase a refusal correctly while a child process still succeeds.

  7. Place a release boundary after the agent. Treat the generated branch as an input to normal review, tests, signing, and deployment. The agent’s workspace should not contain the identity that turns code into a production release. This keeps one model mistake or poisoned tool instruction from becoming a customer-facing change.

  8. Save the evidence and set an expiry. Keep the tested policy, versions, results, owner, and review date together. Repeat the suite after changes to Windows, MXC, the agent, its tools, or the repository’s build chain. A boundary that passed in September 2026 is evidence about that configuration, not a permanent certificate.

This sequence may feel slower than accepting a vendor default. It is faster than investigating an agent action without knowing which identity, mount, network route, or backend made it possible. The first pass also creates reusable tests. Later workstations can prove they match the approved profile instead of relying on screenshots from a setup guide.

The rollout should preserve a manual stop. Administrators need a way to disable the agent identity, cut its network route, and revoke task credentials without waiting for the developer session to cooperate. Test that stop while nothing is wrong. A kill switch discovered during an incident is usually an aspiration rather than a control.

What to ask before buying the security story

Project Zenith’s prepared environment may remove real setup friction. That is a product benefit, not a reason to relax review. Procurement and platform teams can turn the current preview warning into a short list of questions for Microsoft, hardware partners, and internal implementers.

Ask which exact MXC version ships and whether it differs from the public preview. Ask which backend protects the default agent workload, whether that backend is considered a supported security boundary for the stated threat, and what happens if it cannot start. A secure failure should stop the job. Quietly running on the host or switching to a weaker mechanism defeats the point.

Ask what the default profile can read, write, and contact. “Managed” or “contained” does not answer those questions. Request a machine-readable policy and a way to inspect the effective policy after all defaults, enterprise settings, and tool-specific additions are applied. The configured intent and the effective result can differ.

Ask how identity reaches external services. If Windows assigns an agent identity locally, determine how Git hosting, cloud platforms, issue trackers, and deployment systems receive it. Find out whether administrators can give an agent a separate short-lived identity per task, restrict it at the service, and revoke it centrally. Local attribution without downstream enforcement is useful logging, but weak authorisation.

Ask which events are recorded and where they go. MXC’s public documentation describes optional execution telemetry and local Windows event tracing. A team still needs enough evidence to answer practical questions: which policy ran, which binary started, which files or destinations were refused, which identity called an external service, and whether the process ended cleanly. Free-form secret values should stay out of those records.

Ask how policy changes are signed, deployed, and rolled back. A developer should not be able to widen a centrally required boundary by editing a local file unless the organisation deliberately grants that ability. Conversely, an emergency policy that cuts a dangerous route must arrive quickly and leave an auditable change record.

Finally, ask for the support statement in writing. Preview software can be excellent for evaluation. It should not carry a production guarantee that its own documentation rejects. If a final Zenith image ships with a supported boundary, Microsoft can say which component and configuration create it. Until then, the repository warning is the conservative source to follow.

The encouraging part is below the model

Project Zenith marks a useful change in emphasis. A larger model running on a personal computer gets the headline, while the more consequential promise sits underneath: the operating system begins to treat agent identity, execution, and fleet policy as platform responsibilities rather than optional wrappers around a chat application.

That direction matches how coding agents actually fail. The agent does not need malicious intent to cause damage. It only needs ambiguous instructions, a tool with more authority than the task, and a path from untrusted input to a real effect. Model tuning may reduce mistakes. A boundary decides what a mistake can touch.

The public MXC warning makes the present state clear. As of 8 September 2026, developers can inspect an ambitious cross-platform containment project, test its policy model, and prepare integrations. They should not describe current profiles as security boundaries. Project Zenith may ship a stronger supported configuration, but the final claim has to be proven against the final machine.

This is ordinary engineering, not cynicism. Any control sitting between generated code and a developer’s identity deserves the same standard. Use the product name to find the documentation. Use the effective policy, backend, and failed-action tests to decide what you trust.

A local model changes where the thinking happens. A tested boundary changes what the resulting process can do. The second property is what lets a useful agent work on a real machine without inheriting the whole life of the person who owns it.

If you want more calm, practical security explanations, the newsletter is one email per month. The signup is on this site.

Sources