Uchi Uchibeke

· Security

Microsoft Copilot Cowork Exfiltrates Files in 5 Lines. Here's the Architectural Lesson Nobody Wants to Learn.

Five lines of prompt injection exfiltrate authenticated M365 file links, because Copilot Cowork lets the model decide which actions need approval.

TL;DR: Microsoft Copilot Cowork can be made to exfiltrate authenticated file download links from your M365 tenant using 5 lines of prompt injection in a skill file. The attack works because sending yourself a Teams message doesn't require approval, and Teams auto-loads external images. The real lesson is architectural. You cannot ask a stochastic system whether an action is sensitive before it acts, and then trust its answer. Pre-action authorization at the tool-call layer is the only model this works for.

The attack that should not be possible

On May 28, PromptArmor published a finding that should make every enterprise CISO reconsider their Microsoft 365 agent strategy. They demonstrated that Copilot Cowork, Microsoft's autonomous agent built on Claude technology, running with full user permissions across SharePoint, OneDrive, Outlook, and Teams, can be manipulated to exfiltrate files with a 5-line prompt injection hidden inside an 81-line skill file.

The attack chain is elegant in its simplicity:

  1. A user uploads a "skill" file from the internet to their Copilot Cowork OneDrive path. Microsoft automatically loads skills from this folder with no validation.
  2. The user asks Cowork to review what they worked on that week. The injection triggers.
  3. Cowork retrieves pre-authenticated download links for every file the user can access.
  4. It embeds those links inside HTML image tags pointing to an attacker-controlled server.
  5. It sends the user a Teams message containing this payload. Sending yourself a Teams message does not require human approval.
  6. The victim opens the message, image loading fires the external requests, and the attacker now has authenticated, no-login-required access to those files.

PromptArmor tested this 5 times against the latest models including Claude Opus 4.7. It worked 5 out of 5, every single time.

Opus 4.7 was the most thorough of the lot. It expanded exfiltration to include every document used in previous Copilot Cowork sessions that week.

Source: PromptArmor, Microsoft Copilot Cowork Exfiltrates Files

The architecture problem

Here's what makes this different from the usual "prompt injection found in production" story.

Microsoft's documentation states that Copilot Cowork "asks for your permission before taking sensitive actions, like sending an email or posting a message in Teams." But when the recipient is the active user, these actions execute immediately. The system delegates the question "is this action sensitive?" to the model itself, at runtime, in a stochastic inference call that can be manipulated.

Think of a nightclub bouncer who asks everyone at the door: "Are you on the list? Be honest." The bouncer has a clipboard, knows the answer matters, and genuinely believes they are enforcing the rules. But they are asking the one entity in the system that is most vulnerable to social engineering.

This is the core failure. Microsoft built an agent with immense delegated authority, read access to essentially every resource a user can reach through Microsoft Graph. Then they built a human-in-the-loop approval system. Then they put the agent in charge of deciding which actions trigger that loop.

The agent decides what's sensitive. The agent decides when to ask. The agent carries the instructions that tell it what sensitive means. And the agent is vulnerable to prompt injection.

This is not a patching problem

Let me be clear: this is not a Microsoft bug that gets fixed in the next patch cycle. PromptArmor also disclosed a separate sandbox egress vulnerability. That one might get patched. But the architectural class of vulnerability is not patchable within the current design.

The approval system is advisory. It sits at the model layer. And the model layer, by definition, produces probabilistic outputs. Every jailbreak benchmark published in the last 18 months tells the same story: adaptive attacks reach near-100% attack success rates against frontier models. The OWASP Agentic Top 10 identifies LLM01 (Prompt Injection) and LLM02 (Insecure Output Handling) as the top two risks for agentic applications, and observes that no model-layer defense has been proven to prevent them deterministically.

You cannot permission-scope your way around this either. Microsoft's official mitigation advice for this attack is to restrict file downloads via SharePoint policy (Set-SPOSite -BlockDownloadPolicy). That's a nuclear option. It disables downloading, printing, and syncing for your entire organization, and it still doesn't prevent the agent from reading the files and exfiltrating their contents through other channels.

You have to fix the authorization model.

What pre-action authorization looks like

The alternative is a control surface that doesn't ask the model for permission. It intercepts every tool call in deterministic application code before the model's intent reaches the wire.

Look at Microsoft's own Agent Governance Toolkit. Its README is explicit: "Prompt-level safety ('please follow the rules') is not a control surface. It is a polite request to a stochastic system." The AGT architecture intercepts tool calls at the framework layer, applies deterministic policy evaluation against a policy-as-code engine, and denies structurally anything the policy forbids. The model doesn't get to vote on whether an action is sensitive. The model doesn't even know the policy exists.

That's pre-action authorization. Every tool call gets evaluated before execution. The agent asks permission. The policy engine decides. The model gets a yes or no it cannot circumvent.

The WEF's new Agent Capability and Authorization Profile (ACAP), developed with Capgemini, formalizes this as a deployment-level governance instrument. It treats delegated authority the same way: every action runs through a deterministic authorization profile, never a model's judgment call. ACAP is the WEF's strongest statement yet that authorization is the control surface, and the prompt is not.

The master key problem

You're building a multi-tenant apartment building. You give every tenant a key that opens every door. Then you install a camera and a polite sign that says "please only enter your own apartment." When someone walks into the wrong unit, you don't call them a hacker. You call the architect.

Copilot Cowork gave the agent a key to every room. Then it asked the model nicely not to abuse that key. When 5 lines of text bypassed the "nice request," Microsoft's advice was to install stronger locks on some rooms while still leaving the agent holding the master key.

The architectural lesson is that you should never have given the agent the master key in the first place. Tool-level permissions, enforced before execution, are the only model that doesn't require a polite stochastic system to make good decisions under adversarial pressure.

What this means for your deployment

If you are running Copilot Cowork in production today:

  • Understand that every skill file is a potential attack surface. Microsoft loads them from OneDrive with no validation.
  • Understand that the "sensitive action" approval loop is advisory, not structural. It can be bypassed by the model it's supposed to protect.
  • Understand that blocking SharePoint downloads is a blunt instrument that degrades functionality across your org.

If you are building agents, the lesson is bigger. Any agent that delegates authority and decides for itself which actions need human approval is vulnerable to this class of attack. It doesn't matter if you use Claude, GPT, or an open-weight model. The vulnerability is architectural, not model-specific. It lives in the authorization design, not the inference pipeline.

The correct pattern is deterministic pre-action policy enforcement. Evaluate every tool call against a rules engine. Log every decision to a tamper-evident audit trail. Never let the model vote on whether its own action is safe.

Questions for anyone running Cowork

This piece is going to ruffle some feathers. Microsoft has bet big on Cowork being the enterprise AI agent. The Frontier program is aggressive. Teams are being told to build skills and automate workflows.

If you run Copilot Cowork in your org: has your security team audited the Skills folder? Have you tested whether your tenant is vulnerable to this exact attack chain? I'd like to hear real-world experiences, including from people who think I'm wrong about the architecture.

If you work at Microsoft and think I missed something about the approval model or a defense I'm not aware of: say so publicly. The industry needs the debate, not a PR statement.

References

  1. PromptArmor, Microsoft Copilot Cowork Exfiltrates Files (May 28, 2026)
  2. JailbreakBench, Chao et al., NeurIPS 2024, adaptive attacks reach near-100% ASR against frontier models
  3. OWASP Top 10 for Agentic Applications 2026, prompt injection remains top risk
  4. Microsoft Agent Governance Toolkit, deterministic pre-action authorization (released May 28, 2026)
  5. Microsoft Copilot Cowork Documentation, Sensitive Action Approvals