Live data from Hacker News

Claude Cowork exfiltrates files

promptarmor.com

181–190 of 419 posts

Re: Claude Cowork exfiltrates files

#181

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.

At least for a malicious user embedding a prompt injection using their API key, I could have sworn that there is a way to scan documents that have a high level of entropy, which should be able to flag it.

Re: Claude Cowork exfiltrates files

#182
post #97

Earlier 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.

I was daydreaming of a special LLM setup wherein each token of the vocabulary appears twice. Half the token IDs are reserved for trusted, indisputable sentences (coloured red in the UI), and the other half of the IDs are untrusted.

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

#184

In 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.

This is why I use signed PDF’s. If a recruiter or manager asks for a docx, I move on.

You’re only going to ever get a read only version.

Re: Claude Cowork exfiltrates files

#185

One 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

#186

Earlier quoted context omitted.

No, because people push their own keys to source repos every day.

Including keys associated with nefarious acts?

Maybe, the point is that people, in general, commit/post all kinds of secrets they shouldn't into GitHub. Secrets they own, shared secrets, secrets they found, secrets they don't known, etc.

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…

That’s not how they work. Everything input into the model is treated the same. There is no separate instruction stream, nor can there be with the way that the models work.

Re: Claude Cowork exfiltrates files

#188

One 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.

It is shown in the chat log.

Re: Claude Cowork exfiltrates files

#189

AI 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…

Command/“prompt” injection is correct terminology and what they’re typically mapped to in the CVE

E.g. CVE-2026-22708

Post reply on HN