What Actually Happens to Your Data Inside Copilot Cowork Runtime

One of the things I love most about being a Microsoft MVP is the behind-the-scenes conversations that happen within the community. Plenty of those discussions involve NDA material which, of course, I can’t talk about here. But many of the conversation threads across various sites and platforms become excellent sounding boards for ideas and…occasionally…rogue explorations of Microsoft marketing claims versus real-world experience. One online discussion this week about how Copilot Cowork runs under the covers led to me spending a couple of hours researching the topic in my daughter’s basement here in Minneapolis, ignoring my wife’s calls from upstairs to come spend time with the grandkids…and then dumping my findings and thinking into a blog post. Which is what I do.

Most Cowork conversations follow the same pattern. We start with the product story, which Microsoft has told well: you hand Cowork a piece of work, it builds a plan, acts across Outlook, OneDrive, SharePoint, Teams, and Excel, and comes back with a finished file instead of a chat suggestion. Then someone from security or architecture asks the question they actually came for. Where does my data go while Cowork is doing all of that?

The short answer is that Cowork processes your files in a temporary, isolated environment inside the Microsoft 365 service boundary, and that environment is removed when the task finishes. Anything worth keeping gets written to a per-session folder in the user’s OneDrive. Everything else lives in a box you can’t see, and Microsoft has published surprisingly little about what happens inside it. There’s not much documentation on this, but I found a couple of references on Support.Microsoft.com.

To see why that matters, picture a request like this one:

Hey Cowork, here are four Excel workbooks. Pull the weekly attachments from the finance mailbox, clean the sheets, normalize the columns, join on customer ID, drop duplicates, calculate trailing twelve-month revenue, enrich everything with the account list in SharePoint, and give me a single workbook plus a summary.

That isn’t “summarize this email.” It’s data movement, temporary working sets, multi-step transformation, and file generation, and it forces some very specific questions into the open. My fellow MVPs are asking great questions about the governance surrounding this process.

• Are source files copied somewhere?
• Do intermediate tables stick around?
• Can a follow-up prompt reuse the work, or does everything reload from Graph?
• Does any of it leave the tenant’s residency boundary?

I went looking for a Cowork runtime architecture paper or support doc to answer those questions, and there isn’t one. What exists are fragments spread across admin guidance, FAQs, support articles, and a related product’s security documentation. So I pulled those fragments together, separated what Microsoft has documented from what’s being inferred, and tried to clarify in my own mind where the gaps are. This isn’t a permissions primer, since identity, Graph consent, and Purview labeling are already well covered elsewhere. The focus here is the runtime itself.

Where Cowork does its runtime work

Cowork runs in the cloud, in a Microsoft-managed isolated environment that exists for the life of a task and is destroyed when the task ends. Microsoft’s most precise public statement on this comes from its admin guidance for Cowork (https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/cowork-admin-governance). I shared the following in the MVP discussion:

When Cowork runs a user’s task, it processes the user’s files in a temporary, isolated environment inside the Microsoft 365 service boundary. Cowork uses the files only for the duration of the task and removes the temporary environment when the task finishes. Users can’t view or access this environment.

Almost everything else in this post is a refinement of that paragraph.

The most useful mental shift I’ve found is to stop thinking of Cowork as one service and start thinking of it as three layers sharing a chat window. The orchestration layer is the long-running task itself, consisting of the plan, tool calls, approvals, and chat history. The durable workspace is a per-session folder tree in the user’s OneDrive with input and output folders. The ephemeral compute layer is that isolated environment where files actually get processed. The first two are reasonably well documented. The third is where most people are guessing.

Some things about that compute layer are clear. It isn’t running on your laptop, which sets Cowork apart from some competing “coworker” experiences that run locally on the endpoint. Your device is a control surface, and the work keeps going in the cloud even if you close the lid. The runtime is also regionally routed: client traffic hits a routing service that returns a regional endpoint under *.gateway.prod.island.powerapps.com, according to Microsoft’s Cowork network endpoints page (https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/cowork-network-endpoints). That’s a real regional runtime behind the chat interface, not just a prompt bouncing to a model and back. Microsoft’s pricing reinforces the point, since usage-based billing treats runtime as its own dimension alongside model use, context retrieval, and tool calls (https://www.microsoft.com/en-us/copilot/blog/2026/06/16/copilot-cowork-is-now-generally-available/). That’s what billed ephemeral compute looks like.

What Microsoft doesn’t say is what kind of isolation it uses. I’m no expert on this topic, but according to my Copilot responses, container, microVM, dedicated Azure VM, Azure Container Apps sandbox, any of those would be consistent with how Microsoft isolates other agent runtimes, and mapping one onto Cowork would be speculation. It also doesn’t say whether a fresh isolate spins up for every prompt, every tool call, or once per task. Partner write-ups and independent security research describe a sandbox with restricted network access and a file-sync path between durable storage and the isolate, which lines up with the admin language, but Microsoft hasn’t published that diagram itself.

The closest first-party reference is Code Interpreter in Microsoft 365 Copilot and Copilot Studio, and I want to be careful to treat it as a comparison and nothing more. Its security documentation (https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/code-interpreter-security) is explicit: isolated Azure VMs, a fresh VM when code runs, no inbound or outbound network, the VM destroyed when the session ends, nothing persisted. Cowork’s Excel skill might use similar machinery, or Office and Graph APIs, or both. Microsoft hasn’t said. And don’t confuse any of this with Microsoft Copilot Managed Runtime, which hosts apps you build inside Cowork (https://www.microsoft.com/en-us/copilot/blog/copilot-studio/build-where-you-want-run-with-confidence-now-microsoft-hosts-and-manages-the-code-created-by-copilot/). That’s the app host, not the sandbox chewing through your workbooks.

The lifecycle detail that matters most is that the documented unit of destruction is the task, not the chat message. A Cowork session can run for minutes or hours, be paused softly (finish the current step) or hard (stop now), resume later, and survive a dropped browser tab, with status moving between In progress, Needs input, Done, and Failed (https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/use-cowork). Microsoft doesn’t publish an idle timeout for the isolate and doesn’t say it dies after each tool call. The simplest way I can put it is that the conversation outlives the isolate, and the isolate never outlives the task.

What data sticks around in Copilot Cowork and what disappears

The single most important thing for an architecture review is that Cowork has two stores, and the OneDrive session folder is the only one you should treat as the system of record. Mixing up the two is how these reviews go sideways.

The durable store is the one you can see. Files you attach, and files Cowork pulls in as work context from OneDrive, SharePoint, Teams, or mail, land in the session Input folder. Files Cowork creates land in the session Output folder. Practitioners consistently see a tree along these lines:

OneDrive
 └── Documents
      └── Cowork
           └── Sessions
                └── {session-guid}
                     ├── input
                     └── output

That’s tenant-resident user data, subject to OneDrive permissions, sharing, versioning, and Purview. This matters a lot for the finance mailbox example. Microsoft doesn’t describe mailbox attachments as streamed through memory and discarded. Retrieved content is materialized into the session workspace, with Graph as the access path and the session folder as the working copy. Edits to an existing Word, Excel, or PowerPoint file work differently, since Cowork can update the file in place, with version history, after you approve the edit. A few practical limits from the Cowork FAQ (https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/cowork-faq) are worth knowing: attachments must be under 200 MB, local device files are out of scope, encrypted files aren’t readable even when the user can open them, and Cowork can’t delete OneDrive or SharePoint items.

The ephemeral store is the isolate, and it’s the one you can’t see. Files are used there for the life of the task, and then the environment goes away. Independent research on a now-mitigated Cowork sandbox issue described exactly this shape, with durable storage outside the sandbox and a sync service copying files in and out. I’d treat that as corroboration of the two-store model rather than as documentation. What remains unpublished is whether DataFrame work is purely in memory, whether there’s a scratch disk, how big it is, how it’s encrypted, and how quickly the bits are gone after the task ends.

Here’s how the artifacts break down, based on the use guidance and Microsoft’s support article on what Cowork uses and stores (https://support.microsoft.com/en-us/microsoft-365-copilot/cowork-uses-stores).

Notice what’s missing. There’s no published intermediate table service, no warehouse, no Spark-style job history. If Cowork needs a cleaned dataset for a later step in the same task, it either holds that state in the isolate while the task is alive or writes a file into the session tree.

That leads to the question people really care about once the first workbook comes back, which is whether a follow-up prompt reuses the work. Within a session, Cowork can reuse chat and task history, files already sitting in the Input and Output folders, custom instructions, skills already loaded, and Office files it was allowed to edit in place. What Microsoft doesn’t promise is a warm compute cache. Nowhere does it say the joined DataFrame from turn one is still in memory at turn three. A follow-up can use the session files Cowork already wrote, which is file-level reuse, not preserved execution state. A brand-new session doesn’t inherit the isolate at all. You either point it at the previous session folder, or it goes back to Graph, OneDrive, and SharePoint.

The same story applies to caching, because there’s no public cache specification for Cowork compute. No cache keys, no scope table, no eviction SLA beyond the task-scoped isolate. The practical scopes look like this: the isolate is task scratch, deleted at task end; the session holds prompts, responses, and input and output files; the user level holds custom instructions and skills under OneDrive/Documents/Cowork/skills/; and at the tenant level there’s no published shared dataset cache at all. Work IQ and the semantic index are retrieval and grounding layers for Copilot, not a scratch pad for your joined workbooks. Screenshots are kept for a limited time, interaction logs follow Purview retention, and OneDrive files follow OneDrive retention. That’s the whole deletion story.

The community has already adapted to this. People running serious multi-hour work tell Cowork to maintain a requirements.md file (I refer to mine as Design_Document.md) and keep working files in the output folder so a later session can pick up the thread. That workaround exists precisely because in-sandbox state isn’t a durable store.

My advice is the same: if the cleaned workbook matters, make Cowork write it to Output, and don’t assume the join still exists anywhere after the task completes.

Walking the finance request back through everything above gives you a data flow built only on published behavior. You attach the workbooks and ask Cowork to retrieve the Outlook attachments through Graph. Authorized files are materialized into the session Input folder, with sensitivity labels traveling with the content. Cowork plans and executes in the cloud under your identity, running the cleaning, joins, deduplication, calculations, and enrichment in the isolated environment, while sends, posts, and file edits still pause for your approval. The outputs you should keep, like the cleaned workbook, the join output, and the summary, land in the Output folder. When the task finishes, the isolate is removed, while the OneDrive session files and conversation history remain. A follow-up in the same session can keep using those files, and a new session only sees what still exists in OneDrive or Graph. That’s as far as the public documentation legitimately goes.

What to tell your security and architecture teams about Copilot Cowork runtime

If you need a one-paragraph briefing, this is the version I’d use.

Cowork processes customer files in a Microsoft-managed, temporary, isolated environment inside the Microsoft 365 service boundary. The source and output files that matter are copied into a per-session OneDrive workspace the user owns. The isolate is removed when the task finishes. Conversation history and those OneDrive files persist under existing Microsoft 365 residency, audit, and retention controls. Microsoft has not published the isolation technology, the scratch-disk design, a computation cache, or any guarantee that in-memory working state survives from one prompt to the next.

Data residency is where reviewers will push hardest, and the cleanest way to handle it is to split storage from processing, the same way Microsoft does. For storage, Cowork follows the Copilot residency model (https://learn.microsoft.com/en-us/microsoft-365/enterprise/m365-dr-service-copilot). Interaction content is stored at rest in-geo when the tenant’s default geography is in the listed set of countries, which includes the United States, the United Kingdom, the named EU countries, Canada, Australia, India, Japan, and others. Workspace files and custom skills live in OneDrive or SharePoint Embedded, so they follow SharePoint and OneDrive residency commitments rather than any special Cowork geography.

Processing is where you need to be precise with your language. Admin guidance says file processing happens inside the Microsoft 365 service boundary and that Cowork follows the same data residency model as Copilot. That isn’t the same as promising every CPU cycle runs in your home datacenter. For Copilot generally, Microsoft separates storage at rest from model inference, and inference location depends on model availability and regional commitments. Cowork can also use Anthropic models as a subprocessor for much of its reasoning and tool-using work, which Microsoft discloses (https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/get-started). And while Code Interpreter’s documentation says its execution environments comply with Microsoft 365 data residency commitments, Cowork doesn’t repeat that sentence for its own isolate. So what you can honestly take to a review board is that durable copies and outputs live in tenant storage under OneDrive and SharePoint Embedded residency, that the working isolate is asserted to sit inside the service boundary and is torn down at task end, and that the exact placement of that isolate, along with whether every model stays in-geo, is governed by Copilot residency and the subprocessor terms (https://learn.microsoft.com/en-us/microsoft-365/copilot/responsible-ai/cowork-responsible-ai-faq), not by a published Cowork compute map.

It’s also worth being upfront about what nobody can answer from public documentation yet. The open questions are:

• Whether the isolate is a container, a microVM, or a dedicated VM, and whether a new one is created per prompt, per tool call, or per task
• Scratch filesystem layout, size, encryption, and deletion timing
• Whether intermediate DataFrames persist across turns, and how any caching is keyed, scoped, or evicted
• Whether Cowork’s Excel path is Code Interpreter, Office and Graph APIs, or both, and what an Excel join-and-clean pipeline looks like as a data-flow diagram

If a regulated workload needs that level of assurance, it has to come through your Microsoft account team, engineering channels, or a contractual review. It isn’t in the public architecture set today.

None of this makes Cowork a bad bet. The compliance story Microsoft wants reviewers to rely on, which combines tenant permissions, service-boundary processing, task-scoped isolate deletion, OneDrive-resident artifacts, and Purview, is a real and defensible story. It just isn’t the same thing as a disclosed container platform, and your teams deserve to know the difference. Until Microsoft publishes more of the internals, my practical guidance is simple. Treat the session folder as the system of record, treat the isolate as opaque and short-lived, and design every handoff as a file rather than trusting hidden runtime state.