Copilot Code Interpreter Security - What Actually Happens When Copilot Runs Python

There's a moment in almost every Copilot rollout we've done where the security team asks a question that stops the meeting: "So when Copilot writes and runs Python code... where exactly does that run?"

It's a fair question. Code interpreter is the feature that lets Microsoft 365 Copilot, and agents built with Agent Builder or Copilot Studio, solve problems by generating and executing actual Python. Maths, data analysis, chart generation, file crunching. The LLM writes the code, the code runs somewhere, and results come back into the chat. For a security team that has spent years locking down what code can execute inside the organisation, "the AI runs arbitrary code it wrote itself" sounds like the setup to an incident report.

Microsoft has published the security architecture for this, and having now walked several Australian clients through it during risk assessments, I want to lay out what's actually in there, what holds up well, and where the trade-offs bite. The official documentation is short, so consider this the annotated version.

The core design - fresh VM, no network, then destroyed

The architecture rests on three decisions, and they're the right three.

First, every code interpreter session runs inside an isolated virtual machine on Azure. Not a shared container pool, not a process sandbox on someone else's box. Each session is separated from other sessions and from the core Copilot services themselves. Your analyst's Python session and the one running for the company down the road never touch.

Second, the VM has no network. None. No inbound traffic, no outbound traffic. The code Copilot generates cannot phone home, cannot pull packages from PyPI, cannot post your quarterly numbers to a server in another country. If a prompt injection somehow convinced the model to write exfiltration code, that code would run, fail to reach anything, and die with the session. This is the single most important control in the whole design, and it's worth quoting directly when your CISO asks.

Third, the VM is ephemeral. Every session starts on a fresh machine, and when the session ends, the VM is destroyed. Nothing persists. No leftover files, no cached data, no state waiting around for the next user. There's no disk for an attacker to come back to because the disk no longer exists.

On top of that sit resource quotas - limits on CPU, memory, disk, and execution time - which mostly exist to stop runaway code from becoming a denial-of-service problem on shared infrastructure. Boring but necessary.

What this means in practice

When we've taken this architecture through security review with clients, particularly in financial services and healthcare where the scrutiny is properly forensic, a few points consistently land well.

The no-network rule turns most attack scenarios into non-events. The classic worry with LLM-generated code is that a malicious prompt hidden in a document tricks the model into writing code that sends data somewhere. Here, there is no somewhere. The blast radius of bad code is one temporary VM that gets shredded minutes later.

Data residency carries over. The environments where code runs comply with Microsoft 365 data residency commitments, so if your tenant data is committed to staying in Australian regions, code interpreter doesn't quietly break that promise. For APRA-regulated entities this is usually the question right after the network one, and it has a clean answer.

Microsoft doesn't train foundation models on your customer data, and the whole thing sits under the existing Microsoft 365 compliance umbrella - ISO 27001, SOC 2, GDPR. Whether you find third-party attestations comforting is a personal matter, but they mean the answers to your security questionnaire already exist.

There's also runtime monitoring. Code is scanned as it executes, and suspicious behaviour - attempts to read restricted files, privilege escalation - terminates the session immediately and alerts Microsoft's security teams. I treat this as defence in depth rather than a primary control. The isolation is what protects you; the monitoring is what protects Microsoft's infrastructure.

The trade-offs nobody mentions in the sales deck

Now for the honest bit, because this architecture buys its security by giving things up, and you should know what before users start asking why.

No network means no packages beyond what's preinstalled. Your data analyst who lives in some niche forecasting library will discover that code interpreter can't pip install it, ever, by design. The preinstalled environment covers the common data stack well enough, but the moment someone needs something exotic, they're back to a proper notebook environment. That's fine - it's just worth setting the expectation early, because "the AI can run Python" gets heard as "the AI can run my Python."

No persistence means no memory between sessions. Every session starts cold. If a user builds up a cleaned dataset across a long analysis conversation, the underlying environment behind it isn't something they can return to next week. The conversation history survives; the computed state doesn't. Users who've come from local Jupyter workflows find this jarring at first.

And no network also means the code can't reach your data sources. Code interpreter works on what's brought into the session, not by querying your warehouse directly. People sometimes imagine it as a pipeline tool. It isn't, and the security model is precisely why.

My view: these are the right trade-offs for a tool embedded in Microsoft 365 and exposed to every knowledge worker in the tenant. An interpreter with network access and persistent storage would be more capable and dramatically harder to approve. Microsoft chose approvable, and for this audience that was correct.

What to actually do with this

If you're evaluating code interpreter for your organisation, here's the short version of the advice we give clients.

Don't treat it as a special case. The architecture means it inherits the security posture of your broader Copilot deployment. The real risk surface in Microsoft 365 Copilot has always been oversharing - Copilot surfacing files users technically had access to but never should have - and code interpreter doesn't change that equation. Fix your permissions and sensitivity labels first; that work matters far more than anything specific to the interpreter. It's the bulk of what we cover in our AI strategy engagements for Microsoft-shop clients.

Do brief your security team with the actual architecture rather than letting them assume the worst. A one-page summary covering isolation, no network, ephemeral VMs, and data residency answers ninety percent of objections before they're raised. We've built agents with code interpreter enabled through our Copilot Studio consulting work, and the approval conversation goes from weeks to days when the right document arrives first.

And brief your users on the limits too. The failure mode isn't a breach, it's disappointment - someone expecting a full development environment and getting a sealed calculator. Framed properly ("it can analyse and visualise anything you give it, it can't reach out or remember"), people use it for what it's genuinely good at. This framing is a big part of what we teach in our Copilot training sessions, because a correctly calibrated user gets value from day one instead of bouncing off it.

The bigger picture is that "AI writes and executes code" is becoming a standard capability across every platform, and the security patterns here - isolate, disconnect, destroy - are what good looks like. When you evaluate other vendors' equivalents, and you will, this architecture is a useful benchmark. If a vendor's code execution feature has network access, persistent storage, and shared environments, you now know precisely which questions to ask.

If you're working through a Copilot rollout and the security review is where things have stalled, that's a conversation we have most weeks - get in touch and we'll help you get it unstuck.