Rodrigo Jorge · Prepared October 9, 2026, at 6:05 a.m. Brasília time (UTC-3). Publication time to be confirmed.
The outbound domain was allowed. The files ended up in the attacker's account.
In May 2026, Anthropic described a third-party disclosure involving Cowork. A malicious file in a workspace mounted by the user contained hidden instructions and an attacker-controlled API key. According to the report, Claude followed those instructions, read other files in the workspace, and sent them through Anthropic's Files API using that key.
The proxy allowed access to api.anthropic.com, which the product needed. The request went to a legitimate endpoint, but uploaded the files to a different account. The company reports that the sandbox enforced its boundaries while data exfiltration still occurred.
This account comes from the vendor. We do not have an independent reproduction or the full disclosure details here. Even so, the reported path raises a question worth asking when reviewing the architecture: what, exactly, are we authorizing when we allow access to an API?
The address does not identify the recipient
A domain allowlist restricts network destinations. On its own, it does not identify the account that will receive an upload or determine which data may leave.
In the reported case, the attacker-supplied API key changed the recipient without changing the domain. Network access remained authorized; the operation no longer served its intended purpose.
As a CISO, I would not close the review with “the agent is sandboxed.” I would ask to see an allowed request using a different credential and ask where that substitution is rejected. If the answer relies solely on the model recognizing the malicious instruction, there is still no verifiable control in the execution path.
OWASP classifies instructions that arrive through external content and change the model's behavior as indirect prompt injection. A file can be reference material while also trying to issue commands. For this analysis, what matters is the authority the agent can exercise after reading it.
A decision to make before enabling uploads
For an agent that needs to send files, I propose defining authorization more precisely: which operation, using which identity, to which account, and with which data.
That may require the integration code to select the credential and validate the destination, rather than accept an API key found in a document. It may also require restricting the agent's access to the files needed for the task. These are implementation decisions to test, not controls proven by this report.
If the workflow only needs to retrieve information, there is no reason to grant upload access for convenience. If it needs to publish to different accounts, switching accounts should be explicitly authorized as part of the workflow. Human approval may be appropriate for an exceptional transfer; it does not replace identity and destination validation.
View the diagram: domain, account, and data require separate checks. A conceptual diagram of the reported incident and the proposed controls, with no performance metrics.
A useful test is to place a hostile instruction and an alternative credential in a test document, use synthetic files, and check whether the integration rejects the transfer before sending anything. Recording only the model's verbal refusal does not answer what would happen if it tried to execute the request.
The test result determines whether that workflow can be granted upload access. None of the proposed checks, on its own, demonstrates resistance to every form of prompt injection.
References
- Anthropic: How we contain Claude, published May 25, 2026. Source of the account involving Cowork and the Files API.
- OWASP: LLM01:2025 Prompt Injection. Classification and recommendations for privilege controls.