These prompt injection techniques are increasingly implausible* to me yet theoretically sound. Anyone know what can avoid this being posted when you build a tool like this? AFAIK there is no simonw blessed way to avoid it. * I upload a random doc I got online, don’t read it, and it includes an API key in it for the attacker.
Claude Cowork exfiltrates files
181–190 of 419 posts
Re: Claude Cowork exfiltrates files
#182Earlier quoted context omitted.
> We have all of the tools to prevent these agentic security vulnerabilities, Do we really? My understanding is you can "parameterize" your agentic tools but ultimately it's all in the prompt as a giant blob and there is nothing guaranteeing the LLM won't interpret that as part of the instructions or whatever. The problem isn't the agents, its the underlying technology. But I've no clue if anyone is working on that p…
We don't. The interface to the LLM is tokens, there's nothing telling the LLM that some tokens are "trusted" and should be followed, and some are "untrusted" and can only be quoted/mentioned/whatever but not obeyed.
Effectively system instructions and server-side prompts are red, whereas user input is normal text.
It would have to be trained from scratch on a meticulous corpus which never crosses the line. I wonder if the resulting model would be easier to guide and less susceptible to prompt injection.
Re: Claude Cowork exfiltrates files
#183Re: Claude Cowork exfiltrates files
#184In this demonstration they use a .docx with prompt injection hidden in an unreadable font size, but in the real world that would probably be unnecessary. You could upload a plain Markdown file somewhere and tell people it has a skill that will teach Claude how to negotiate their mortgage rate and plenty of people would download and use it without ever opening and reading the file. If anything you might be more succes…
Mind you, that opinion isn't universal. For programmer and programmer-adjacent technically minded individuals, sure, but there are still places where a pdf for a resume over docx is considered "weird". For those in that bubble, which ostensibly this product targets, md files are what hackers who are going to steal my data use.
You’re only going to ever get a read only version.
Re: Claude Cowork exfiltrates files
#185One issue here seems to come from the fact that Claude "skills" are so implicit + aren't registered into some higher level tool layer. Unlike /slash commands, skills attempt to be magical. A skill is just "Here's how you can extract files: {instructions}". Claude then has to decide when you're trying to invoke a skill. So perhaps any time you say "decompress" or "extract" in the context of files, it will use the inst…
Re: Claude Cowork exfiltrates files
#186Earlier quoted context omitted.
No, because people push their own keys to source repos every day.
Including keys associated with nefarious acts?
GitHub and their partners just see a secret and trigger the oops-a-wild-secret-has-appeared action.
Re: Claude Cowork exfiltrates files
#187> "This attack is not dependent on the injection source - other injection sources include, but are not limited to: web data from Claude for Chrome, connected MCP servers, etc." Oh, no, another "when in doubt, execute the file as a program" class of bugs. Windows XP was famous for that. And gradually Microsoft stopped auto-running anything that came along that could possibly be auto-run. These prompt-driven systems ne…
Re: Claude Cowork exfiltrates files
#188One issue here seems to come from the fact that Claude "skills" are so implicit + aren't registered into some higher level tool layer. Unlike /slash commands, skills attempt to be magical. A skill is just "Here's how you can extract files: {instructions}". Claude then has to decide when you're trying to invoke a skill. So perhaps any time you say "decompress" or "extract" in the context of files, it will use the inst…
If they made it clear when skills were being used / monitored that, it'd seem to mitigate a lot of the problem.
Re: Claude Cowork exfiltrates files
#189AI companies just 'acknowledging' risks and suggesting users take unreasonable precautions is such crap
> users take unreasonable precautions It doesn't help that so far the communicators have used the wrong analogy. Most people writing on this topic use "injection" a la SQL injection to describe these things. I think a more apt comparison would be phishing attacks. Imagine spawning a grandma to fix your files, and then read the e-mails and sort them by category. You might end up with a few payments to a nigerian princ…
E.g. CVE-2026-22708