Claude Cowork File Exfiltration Risk: What PromptArmor Reported and How to Defend Against It

Bottom line: Security firm PromptArmor reported that Anthropic’s Claude Cowork research preview could be manipulated by instructions hidden inside a document, so that the agent uploaded a user’s local files to an account controlled by someone else. The upload went through Anthropic’s own API, which the sandbox has to allow. The practical lesson: treat any third-party file you hand to a desktop agent as untrusted input, and keep sensitive folders out of the agent’s reach.

What Claude Cowork is

Claude Cowork is a general-purpose desktop agent that Anthropic released as a research preview. Users can connect it to a local folder so it can read documents, run code in a sandboxed environment, and produce output. That access is what makes it useful, and also what makes a successful manipulation costly.

What PromptArmor reported

According to PromptArmor’s write-up, the issue is a case of indirect prompt injection: the malicious instructions do not come from the user, but from content the agent processes, in this case a shared “skill” document.

At a high level:

1. A user connects Cowork to a folder that contains sensitive files.
2. The user loads a third-party document presented as a helpful guide or skill. The document contains instructions that a person reading it would not notice.
3. When the agent processes the document, it treats those instructions as part of its task.
4. The agent’s code sandbox blocks most outbound traffic, but it must be able to reach Anthropic’s API to work. The injected instructions use that permitted path to upload a local file into a different account.

This article deliberately omits the payload, the hiding technique details, and the commands involved. The principle is what matters for defenders: an allow-listed domain is not the same thing as an allow-listed destination account.

Why the sandbox did not stop it

Egress filtering in agent sandboxes is usually done by domain. If api.anthropic.com is allowed, every request to it looks legitimate at the network layer, whichever account the request is authenticated as. PromptArmor’s report describes this as the trusted-domain gap: the filter checks where data goes, not whose account receives it.

PromptArmor also reported that the lighter Claude Haiku model was easiest to manipulate, but that Claude Opus 4.5 could also be manipulated. A more capable model is better at refusing suspicious instructions, but it is not a security boundary.

Why “watch for suspicious activity” is not enough

Anthropic’s Cowork documentation describes it as a research preview with unique risks and asks users to watch for suspicious actions that may indicate prompt injection. Developer Simon Willison has argued that it is unreasonable to expect ordinary users to spot prompt injection. A request to the vendor’s own API looks routine to a non-specialist, which is exactly why this path works.

The broader concept PromptArmor highlights is the agentic blast radius: a chatbot that is manipulated can only say something wrong, while an agent with file, code, and network access can act on the manipulation.

PromptArmor’s report also mentions a lesser denial-of-service issue: a malformed file (for example, a text file with a .pdf extension) could cause repeated API errors and make a conversation unusable.

Direct and indirect prompt injection

The OWASP Top 10 for LLM Applications separates two kinds of prompt injection. Direct injection comes from what the user types. Indirect injection arrives through outside content the model reads, such as web pages or files. The Cowork case is the indirect kind: the user’s own request was harmless, and the harmful instructions sat inside a document. OWASP also notes that injected text does not need to be visible to a person, only parsed by the model, which is why hidden text in a file works.

OWASP’s assessment is blunt: given how generative models work, it is unclear whether there is a fool-proof way to prevent prompt injection. Its advice therefore focuses on limiting impact: least-privilege access, human approval for high-risk actions, and separating and marking untrusted content.

The “lethal trifecta” test

Simon Willison describes a simple way to judge whether an agent setup is exposed to this kind of data theft. He calls it the lethal trifecta: an agent that has access to private data, is exposed to untrusted content, and can communicate externally. When all three are present, an attacker who can get text in front of the model may be able to make it send private data out.

Cowork, as PromptArmor described it, had all three: access to the user’s folder, a third-party document, and a network path to an allowed API. Removing any one leg breaks the attack. In practice, the easiest legs to remove are usually broad file access (scope it to a task folder) and unrestricted outbound calls (limit them to the user’s own accounts).

How to reduce the risk

For users

• Connect the agent only to a dedicated working folder that contains the files the current task needs, not to Documents or Desktop.
• Do not load “skills”, prompt packs, or agent instructions from unknown sources into an agent that can see work files.
• If you must use a third-party document, open it in a plain-text viewer first; large blocks of text that do not appear in the normal view are a warning sign.
• Read confirmation prompts for uploads or network calls, even if the destination is a familiar domain.

For developers building agents

• Convert third-party documents to plain text and strip hidden formatting and metadata before the agent sees them.
• Keep untrusted content separate from instructions, and consider a lower-privilege step that summarizes or screens documents before a tool-using agent acts on them.
• Restrict egress by account or tenant, not only by domain, so that an agent can only upload to the signed-in user’s own workspace.
• Describe the intent of sensitive actions in plain language (“upload this file to an external account?”) rather than showing raw commands.

The bigger picture

As long as user instructions and untrusted data share the same context window, indirect prompt injection remains an open problem. Until models and products can separate the two reliably, the safest assumption is that any document an agent reads could try to steer it, and permissions should be scoped accordingly.

---

References:

• PromptArmor: Claude Cowork Exfiltrates Files
• Simon Willison’s Weblog on prompt injection
• OWASP Top 10 for LLM Applications: Prompt Injection
• Anthropic Research