Live data from Hacker News

Claude Cowork exfiltrates files

promptarmor.com

231–240 of 419 posts

Re: Claude Cowork exfiltrates files

#231

Earlier quoted context omitted.

Fair, I forget how broadly users are willing to give agents permissions. It seems like common sense to me that users disallow writes outside of sandboxes by agents but obviously I am not the norm.

“Disallow writes” isn’t a thing unless you whitelist (not blacklist) what your agent can read (GET requests can be used to write by encoding arbitrary data in URL paths and querystrings). The problem is, once you “injection-proof” your agent, you’ve also made it “useful proof”.

> The problem is, once you “injection-proof” your agent, you’ve also made it “useful proof”.

I find people suggesting this over and over in the thread, and I remain unconvinced. I use LLMs and agents, albeit not as widely as many, and carefully manage their privileges. The most adversarial attack would only waste my time and tokens, not anything I couldn't undo.

I didn't realize I was in such a minority position on this honestly! I'm a bit aghast at the security properties people are readily accepting!

You can generate code, commit to git, run tools and tests, search the web, read from databases, write to dev databases and services, etc etc etc all with the greatest threat being DOS... and even that is limited by the resources you make available to the agent to perform it!

Re: Claude Cowork exfiltrates files

#232

AI companies just 'acknowledging' risks and suggesting users take unreasonable precautions is such crap

Telling uses to “watch out for prompt injections” is insane. Less than 1% of the population knows what that even means.

Not to mention these agents are commonly used to summarize things people haven’t read.

This is more than unreasonable, it’s negligent

Re: Claude Cowork exfiltrates files

#233

Earlier quoted context omitted.

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.

Read-only... Until I ctrl-p in Firefox.

You can’t open it in a browser.

It requires a proper PDF viewer.

Re: Claude Cowork exfiltrates files

#234

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

Until someone comes up with a solution to that, such systems cannot be used for customer-facing systems which can do anything advantageous for the customer.

Re: Claude Cowork exfiltrates files

#235

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…

> because a .md file feel less suspicious than a .docx

For a programmer?

I bet 99.9% people won't consider opening a .docx or .pdf 'unsafe.' Actually, an average white-collar workers will find .md much more suspicious because they don't know what it is while they work with .docx files every day.

Re: Claude Cowork exfiltrates files

#236
post #194

Earlier quoted context omitted.

The poster you originally replied to is suggesting this for revoking the attackers keys. Not for revocation of their own keys…

there's still some risk of publishing an attacker's key. For example, what if the attacker's key had access to sensitive user data?

[flagged]

Re: Claude Cowork exfiltrates files

#237

Earlier quoted context omitted.

“Disallow writes” isn’t a thing unless you whitelist (not blacklist) what your agent can read (GET requests can be used to write by encoding arbitrary data in URL paths and querystrings). The problem is, once you “injection-proof” your agent, you’ve also made it “useful proof”.

> The problem is, once you “injection-proof” your agent, you’ve also made it “useful proof”. I find people suggesting this over and over in the thread, and I remain unconvinced. I use LLMs and agents, albeit not as widely as many, and carefully manage their privileges. The most adversarial attack would only waste my time and tokens, not anything I couldn't undo. I didn't realize I was in such a minority position on t…

I'm puzzled by your statement. The activities you're describing have lots of exfiltration routes.

Re: Claude Cowork exfiltrates files

#238

A bit unrelated, but if you ever find a malicious use of Anthropic APIs like that, you can just upload the key to a GitHub Gist or a public repo - Anthropic is a GitHub scanning partner, so the key will be revoked almost instantly (you can delete the gist afterwards). It works for a lot of other providers too, including OpenAI (which also has file APIs, by the way). https://support.claude.com/en/articles/9767949-api-…

I wouldn’t recommend this. What if GitHub’s token scanning service went down. Ideally GitHub should expose an universal token revocation endpoint. Alternatively do this in a private repo and enable token revocation (if it exists)

> What if GitHub’s token scanning service went down.

If it's a secret gist, you only exposed the attacker's key to github, but not to the wider public?

Re: Claude Cowork exfiltrates files

#239

Earlier quoted context omitted.

That's true tho... possible, but impractical.

Only possible if you are unconstrained by time and storage.

Not only you, but GitHub too, since you need to upload.

Storage is actually not much of a problem (on your end): you can just generate them on the fly.

Re: Claude Cowork exfiltrates files

#240
post #159
post #140

Earlier quoted context omitted.

Except is there a guarantee of the lag time from posting the GIST to the keys being revoked?

Is this a serious question? Whom do you imagine would offer such a guarantee? Moreover, finding a more effective way to revoke a non-controlled key seems a tall order.

If there’s a delay between jets being posted and disabled they would still be usable no?
Post reply on HN