Security for AI and Agent Augmented Coding on Windows | OD853

Key Takeaways

Hey everyone, uh welcome to build. I'm Clarita from the Windows developer platform team and I'm here with Sakib from Windows Enterprise and Security. >> Hi. >> Today we want to talk about how Windows can help developers build and run agents safely at scale. We are at a moment where agents are starting to feel like a new unit of software. They are not just answering questions. They can reason, use tools, remember context, and increasingly they're taking action in ways that feel more collaborative and alive. So the experience is starting to shift from asking software to do something for you to actually building with it and evolving it over time. That is why I love the terrarium metaphor. It is not only about automation. It is about creativity, customization and shared building. You start with something someone else built. You make it your own and then you keep building together. And that matters because it changes what people expect from software. Instead of just consuming a finished product, people are increasingly shaping the experience. they're adapting it to their own world and sharing those changes back with each other. That is a much more participatory model and one that makes agents feel less like a feature and more like a medium for collaboration. So there's the real story behind this slide. Agent Terrarium here is a project a friend of mine, Alexclar created. What he did is he built the initial world. He shared the GitHub repo with me and what I did is I extended it with my own theme. You see here on the bottom right corner there is the Albanian mountains theme and I also added Zanna. This is an Albanian fairy as an agent. Then I shared my version back and now we both built on top of each other's work. It is fun and it's also made our collaboration better and that is where the platform matters. As agents become something that people can shape, extend and collaborate with the operating [snorts] system has to do more than just host them, right? It has to remove the friction and it has to also provide a safe governable environment where people together can create and they can run and they can build things with confidence. That is why Windows matters here, right? And why we believe it is the best platform to run and build agents at scale. Now, that matters because customers are no longer just asking whether agents can do something impressive or something cool, right? They're asking whether those agents can be trusted in these real environments on their actual machines that they're running with real business data, right? So, Windows has to answer these two questions at the same time. Can the agent be powerful? And at the same time, can the platform still keep it governable? Let's start first with what makes agents different. So agents are non-deterministic. We know that they operate on data that can itself contain instructions or some adversarial content. And they can act fast at machine speed fast. That means that even a mistake or a bad inference or an attack can scale so much faster than in more traditional user-driven type of flows. The key shift is that this is no longer just a prompt and answer problem, right? It is an execution problem. Agents can read files, they can invoke tools, they can call services, they can modify entire environments, right? And that means that the risk is not just what the model is saying. The risk is where execution happens, what the agent can reach and how much author authority it inherits by default. Once you understand the risk model that I just explained, right, the first three needs are super clear. Containment to limit the blast radius, detection and response to catch problems early, and then the agent identities that are distinct from humans so permissions and attribution remain meaningful. These are not abstract architecture ideas, right? there. What makes the difference between an agent that feels impressive in a demo and one that can actually be trusted in a real environment? Governance is the one that completes that model. Agents need to be manageable, discoverable, observable, and configurable in enterprise environments. These are not separate check boxes that you'll have to go and check, right? Together, containment, detection, identity, and governance form the foundation for trustworthy agentic systems. All right, it's time for me to hand it to Sakib. He's going to go through the containment details. >> Thanks, Clarita. Now that we framed the problem, let's get concrete about containment and the Windows building blocks that make safer agents possible. Containment is one of the most important ideas in this talk. If agent behavior is non-deterministic, then containment becomes the deterministic guardrail around it. The reason containment matters is simple. Agents should be able to do useful work without inheriting the full blast radius of the user's session. In both ordinary and adversarial cases, containment reduces the blast radius and constrains what a risky operation can touch. That is the shift from traditional software to agentic software. In traditional apps, a mistake is often bounded by the feature itself. With agents, the execution surface is larger because the system can read, act, and chain together multiple steps. Containment is how you keep that larger surface from turning into a larger blast radius. Given the importance of containment, we are excited to introduce the Microsoft Execution Containers SDK. This single SDK will allow applying containment policies on agents enforced by the OS. The MXC SDK will provide an abstraction layer across various isolation primitives that simplifies containing many different types of workloads. Microsoft execution containers are built around a composable sandbox model. The same policy and SDK can map to different isolation boundaries depending on the workload. So developers are not locked into one rigid container. Winners can apply the right isolation primitive for the task while preserving one coherent abstraction. Different agents and tools need different isolation levels. Our goal is simple. Let developers declare intent with policies and let Windows enforce the appropriate boundary. What makes this model powerful is that it meets developers where they are. A coding agent, an interactive agent, and a cloud-managed agent do not all need the same boundary, but they do need one coherent trust story. That is what the composable sandbox gives you. Flexibility and implementation without fragmentation and governance. For developers, the implementation story is practical and incremental. Think of a four-stage plan. First plan by identifying the sensitive operations your agent needs to perform, especially ones that may be exposed to prompt injection risk or handle customer data. Then focus on design. Identify the model driven parts so that they can be contained. With the design in hand, you can then move to implement. Contain the highest risk operations with our MXC SDK. Finally, refine your solution by testing what is allowed and denied and ensure that it meets your experience and security goals. Containment is not a bolt-on. It is a design tool for building safer agentic apps from the beginning. Containment should not add friction. A single SDK and policy model make it easier to adopt the right isolation level. >> Thanks, Akib. Um, the composable sandbox is the big idea that you're going to see in the next several slides here with me. Windows is not giving developers one rigid container and asking them to force every workload into it. It's offering a spectrum of containment options so the boundary can match the risk of the task. It's the same overall trust model but different levels of isolation. This is where the story shifts from principle to architecture. And we are no longer just saying contain these agents. We're showing a practical scalable execution model that can go from a tool call on the device to a broader agent workflow across client and cloud. So that breadth is one of the reasons Windows has a differentiated story here and that is important because Windows can start with a lightweight local isolation and when that is not enough and then when moved all the way to the stronger boundaries when the workload or the enterprise requirement needs it. So we're rolling this initiative out on a monthly cadence with the developer community. Some of these capabilities are already showing up in Windows Insider builds and there's more that are going to come later this month and we'll keep building and learning together as the platform evolves. We're excited and I know you are too. So let's dig a little bit deeper into the containment spectrum now. I'm going to start with a microVM. So at the stronger end of the spectrum is the microVM. This is the right fit when the workload is higher risk and it needs a clearly isolated space while still preserving the same overall agent experience. And the message is not to use this everywhere, right? It's to step up isolation when the workload calls for it. MicroVMs are also about density. They provide a stronger separation without having to pay the full cost of a larger VM every single time that you're running your agent. I just explained the Hyperlite microVM, the execution primitive at the top of the agent containment stack. Let me show you what that looks like in practice. Imagine Maya, a freelance interior designer. She's been using GitHub Copilot CLI to manage her client projects and her previous task has just wrapped up. She has three client PDFs with comments and review feedback that she needs to consolidate. Let's watch her ask Copilot for help. She types a natural language request, pull the review comments from all three client PDFs, group them by theme, and produce a clean prioritized summary. No scripts to write, no tools to configure. It's just a plain English ask. Copilot understands a task immediately, and it lays out its plan. Notice that it asks for permission before accessing Maya's files. The user stays in control. Maya grants access and now Copilot gets to work. Behind the scenes, Copilot is figuring out how to extract annotations from those PDFs. It needs to run code to parse them, right? But here's the key question. Where does that code execute? There it is. Extract PDF annotations in Hyperllight MicroVM. Copilot chose to run this code inside a Hyperllight MicroVM. And I hope you didn't miss the WXC XZ that appeared in task manager. That's the microVM host process. And once the task is done, Copilot cleans up the temporary config. And just like that, the microVM is gone. No traces left behind. But notice in the file explorer, there's a new file that has appeared. Client feedback summary. Copilot has delivered a wellorganized summary. Comments from all three client PDFs grouped by theme and ranked by priority. All of this processed inside a hyperllight microVM. Hardware level isolation with subsecond startup. That's the power of MXC. Safe code execution that's fast enough to be invisible. Process isolation on the other side sits at this lighter weight end of the spectrum. It is a strong fit for coding agents and focused tool execution scenarios where speed matters for you. So developers keep the familiar coding flow while Windows applies platform level boundaries to the riskiest operations. This is especially important for developer scenarios because the inner loop needs to stay fast. If the smallest riskiest operations like running model generated code can be isolated at process level then developers get a safety benefit without losing responsiveness and that is how containment becomes something developers actually adopt rather than something that they need to avoid because it's slowing them down. Now, let me pick up where I left off earlier and show you process level isolation. I have GitHub Copilot CLI with an experimental feature enabled. So, code is run in a process sandbox. Going back to Maya, it's late evening and everyone has gone to bed, but she has a personal task to do. Her daughter Laura's birthday is coming up. Maya types sandbox enabled to turn on sandboxing. Now, every tool execution Copilot runs will be contained in a sandbox. She then asks Copilot to make a birthday card using cat photos from a folder on her laptop. Again, just a natural language request. Pick the best images, resize them, combine them, add a birthday message. Copilot understands and outlines its approach and requests access to the Laura Pictures folder. Same consent flow. The user is always in the loop and in control. Maya grants access. And now here's the sandbox in action. You see that blue dot next to sandbox shell? That means this PowerShell code is executing inside a sandbox. The script is loading and manipulating Maya's cat photos, but it's doing so within a kernel enforced sandbox boundary. It can only access what it's been explicitly granted. And done. PowerShell code generated and executed all within the sandbox. Notice in the file explorer, happy birthday Laura has appeared right alongside the source images. Let's see what it looks like. It's a custom birthday card with Maya's favorite cat photos arranged and captioned, all executed in a process sandbox. The code ran, the file was created, and at no point did the execution escape its boundary. This is MXC, Microsoft execution containers, composable sandboxes for running dynamically generated code with controlled isolation. We're moving on to Windows and Linux uh VM. A full VM gives broader separation and stronger assurance. This is the right fit for workloads that need a different kernel, complete isolation, and stronger guarantees, especially for high assurance or more controlled enterprise scenarios. This is exactly where the message now shifts from efficiency to assurance. A full VM is the answer when the workload needs much more distance from the host environment. Whether because the code is highly untrusted, the environment is maybe tightly managed or the trust requirement is simply much much higher. This slide shows how Windows is prepared for that higher assurance end of the spectrum too. Right? For enterprise customers, this is where policy and assurance start to matter even more than convenience. A full VM gives organizations a boundary they already understand and one they can reason about when the workload is especially sensitive or if the cost of compromise is high. Cloud VMs extend containment beyond the local device. Now in the enterprise this can be a Windows 365 powered giving the agent a cloud PC that is separate from the user's device separate from its identity separate from the user's kernel device and session. The agent runs remotely in a managed environment not alongside the user on the same machine. And because it is built on Windows 365, the environment comes with all the enterprise management that is built already in like security policies that can be provisioned up front. Identity compliance can be managed centrally through Microsoft entry ID and in tune. As you can see, this is the highest assurance end of the spectrum and offers the strongest blast radius reduction. If the agent is compromised, the impact is contained to a disposable cloud instance with no direct path back to the user's local device. So far, we focused on containment and its spectrum. And we showed you that Windows can support both the developer productivity and the enterprise assurance by letting the boundary scale with the workload instead of forcing every scenario into the same model. But containment is only part of this picture. Let me hand it back to Sakib to cover the other side of the equation. How we detect, respond, and make the broader security ecosystem part of the story. >> Thanks, Clarita. Agents increasingly depend on tools, skills, services, and sometimes even other agents to complete a task. So, developers and administrators need a clear view of what capabilities are present, what is enabled, what is allowed, and what is being used. Local capabilities discovery provides that source of truth and makes those actions admin manageable. Capabilities discovery matters because once agents compose with tools and services, the local environment becomes part of the trust model. With local capability discovery for agents, we can then complement the security provided by containers. One of the most powerful capabilities this adds is better detection and response. Hooks before tool use, after tool use, and at prompt submission create stable integration points for security products like Defender to inspect, evaluate, and respond. That consistent inspection is essential for customers in enterprise environments to mitigate risks like indirect prompt injection. Here, a developer asks their AI agent, GitHub Copilot, to investigate and fix an externally reported issue in their repo. At first glance, the issue looks routine, but hidden within one of its attachments is a prompt injection attack. GitHub Copilot gets to work on the user's behalf. It pulls in the issue and its attachments from the repository and begins analyzing the content. As the agent gets to work, but before the attack can take hold, Microsoft Defender can step in. It inspects the data flowing into the agent in real time, recognizes the prompt injection, and blocks it. The detection details, including the analyze network prompt stream, are surfaced directly to the user in Windows. This protection isn't limited to GitHub Copilot. Agents built with frameworks like Open Claw that expose two calling hooks are similarly covered. The same attack is attempted and once again, Defender detects and blocks it. For enterprises, these detections flow into the Microsoft Defender portal, providing full visibility into the attack and enabling critical sec ops workflows. Another core principle is that the agent is not you. If agents are going to do meaningful work in enterprise environments, we need a clear distinction between what the human did and what the agent did. Without that distinction, audit becomes ambiguous. Permissions become harder to reason about and accountability starts to blur. Identity matters because it shapes permissions and policy before the action happens, not just after. There are at least two useful methods to identify agents and their actions. Sometimes the right solution is where the agent acts on behalf of the user. The agent acts with the user's delegated context, but the action is still clearly marked and attributable as agent driven. Increasingly though, the stronger model is a unique agent identity managed, permissioned, and governed independently with more precise lease privilege controls. How should we pick the best method to identify agents and their actions? The delegated path is best if you're using process-based isolation. Work that the agent does on a human user's behalf still gets a lowcost agent identification tag. This allows downstream systems like Entra to apply agentic risk controls. The contained coding agent process is a good example of using this model. If you can go beyond process level isolation to sessionbased isolation, you can benefit from using distinct agent identities. Doing so will provide deep integration with the Entra agent ID system that will provide comprehensive authentication and authorization support for agentic actions. Complex interactive agents like clause are an ideal example of this use case. Let's see how the primitives we talked about come together. Earlier we talked about the MXC SDK and how it can make containment of different types of apps and agents easier. In this example, we have a modified version of the open-source openclaw agent. Since openclaw is a sophisticated agent, cessin isolation is a much better fit for the collection of components it needs compared to process isolation. I've set up and started our MXC integrated Open Claw. The gateway was running earlier and you just saw the Open Claw dashboard. This should be familiar to anyone that has tried OpenClaw. Let's take one small look under the covers. In the Windows Task Manager users pane, you can see we have two users active on the system. Me, of course, and my agent user account. Open clause agent loop runs under the agent user account and you can see its processes in the task manager. Apps I use like the browser that hosts the openclaw dashboard run under my account. Let's use the dashboard with our openclaw agent. First I will ask openclaw to run the windows identity utility. Who am I? I can see that this OpenClaw agent has its own user account in the Entra directory for the tenant. This is thanks to new provisioning capabilities introduced in Entra and Intune when OpenClaw was set up and run. The agent session seamlessly logged in with the right Entra agent user account thanks to updates to the Windows identity stack. If you recall, the different session and user account gives us robust isolation. Here's a quick look at my documents folder. If I ask open cloud to list what is there, it won't actually see my documents folder. It will see what it has it in its documents folder and it should return a result for a configuration script. And if you look, my documents folder has financial projections, and the agent can't automatically access it. Now, let's have our isolated agent do something useful for us. I haven't looked at that data in a while. Let's ask our agent to remind me what the key details are. How do I give it access? Well, no special instru instructions. I'll just attach the file like in any chat with OpenClaw. And look, since this is a user authorized action, access to the doc will flow through the agent and it will use various tools to give me the insights I'm looking for. All with the right containment and agent identity constructs working together in Windows to provide safer agentic productivity. Additionally, any threats like prompt injection the defender detects while using open claw can be associated with the entra agent identity to facilitate sec ops actions in the defender portal. Let me hand back to clarita for the close. >> As we bring this together, the broader point is that windows is not just adding isolated security features for agent. It is becoming part of a much more complete platform across Windows, Entra, Intune, Defender, Purview, Agent 365, GitHub, and the rest of the Microsoft system. The story is that agent governance should not be fragmented. Every agent on every Windows device needs a path to being discovered, governed, and audited. Identity and containment are foundational, but they are only the start, right? Enterprises also need centralized life cycle management. They need policy enforcement across devices, realtime threat detection and response, and end-to-end audit and compliance tracking. It is not enough to know that an agent exists. Organizations need to manage its life cycle, understand what it can access, see what it has done, and apply policy consistently across devices and environments. Microsoft solutions turn governance from a concept into an operational capability. Now going back to everything that we discussed today, we have a CTA, a call to action for building agents for you all. If you are building agents, the practical takeaway is very simple. Design for governance from the beginning. Think about packaging, identity, containment, network mediation, and event emission as core parts of the system, not as something that you got to do later. So, a good agent is not just one that just works, right? It is one that can be identified, monitored, and governed in a real enterprise environment. And this is what excites us most. Windows is the best place to build agents that can really do work across device and cloud with a built-in path to trust, governance, and enterprise scale. >> Thanks for joining us today. We're excited to see what all of you build. Go try it out and enjoy the rest of build. >> Thank you.