Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Cowork exfiltrates files

promptarmor.com

Post reply on HN
Print view View original

131–140 of 419 posts

Re: Claude Cowork exfiltrates files

#131

Post by lkjdsklf »

bcrosby95 wrote: post #55
schmichael wrote: post #43

Earlier quoted context omitted.

> We TOLD you this dynamic web stuff was a mistake. Static HTML never had injection attacks. Your comparison is useful but wrong. I was online in 99 and the 00s when SQL injection was common, and we were telling people to stop using string interpolation for SQL! Parameterized SQL was right there! We have all of the tools to prevent these agentic security vulnerabilities, but just like with SQL injection too many peop…

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

yeah I'm not convinced at all this is solvable.

The entire point of many of these features is to get data into the prompt. Prompt injection isn't a security flaw. It's literally what the feature is designed to do.

Re: Claude Cowork exfiltrates files

#132

Post by formerly_proven »

bcrosby95 wrote: post #55
schmichael wrote: post #43

Earlier quoted context omitted.

> We TOLD you this dynamic web stuff was a mistake. Static HTML never had injection attacks. Your comparison is useful but wrong. I was online in 99 and the 00s when SQL injection was common, and we were telling people to stop using string interpolation for SQL! Parameterized SQL was right there! We have all of the tools to prevent these agentic security vulnerabilities, but just like with SQL injection too many peop…

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

For coding agents you simply drop them into a container or VM and give them a separate worktree. You review and commit from the host. Running agents as your main account or as an IDE plugin is completely bonkers and wholly unreasonable. Only give it the capabilities which you want it to use. Obviously, don't give it the likely enormous stack of capabilities tied to the ambient authority of your personal user ID or ~/.ssh

For use cases where you can't have a boundary around the LLM, you just can't use an LLM and achieve decent safety. At least until someone figures out bit coloring, but given the architecture of LLMs I have very little to no faith that this will happen.

Re: Claude Cowork exfiltrates files

#133

Post by spockz »

alienbaby wrote: post #127
dehugger wrote: post #84

Earlier quoted context omitted.

Write your own tools. Dont use something off the shelf. If you want it to read from a database, create a db connector that exposes only the capabilities you want it to have. This is what I do, and I am 100% confident that Claude cannot drop my database or truncate a table, or read from sensitive tables. I know this because the tool it uses to interface with the database doesn't have those capabilities, thus Claude do…

Until Claude decides to build its own tool on the fly to talk to your dB and drop the tables

That is why the credentials used for that connection are tied to permissions you want it to have. This would exclude the drop table permission.

Re: Claude Cowork exfiltrates files

#134

Post by danaris »

losthobbies wrote: post #121
chasd00 wrote: post #100

Earlier quoted context omitted.

> Sanitise input i don't think you understand what you're up against. There's no way to tell the difference between input that is ok and that is not. Even when you think you have it a different form of the same input bypasses everything. "> The prompts were kept semantically parallel to known risk queries but reformatted exclusively through verse." - this a prompt injection attack via a known attack written as a poem…

That’s amazing. If you cannot control what’s being input, then you need to check what the LLM is returning. Either that or put it in a sandbox

Or...

don't give it access to your data/production systems.

"Not using LLMs" is a solved problem.

Re: Claude Cowork exfiltrates files

#135

Post by jychang »

securesaml wrote: post #104
Tiberium wrote: post #30

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)

You're revoking the attacker's key (that they're using to upload the docs to their own account), this is probably the best option available.

Obviously you have better methods to revoke your own keys.

Re: Claude Cowork exfiltrates files

#136

Post by Terr_ »

schmichael wrote: post #43
hakanderyal wrote: post #35

This was apparent from the beginning. And until prompt injection is solved, this will happen, again and again. Also, I'll break my own rule and make a "meta" comment here. Imagine HN in 1999: 'Bobby Tables just dropped the production database. This is what happens when you let user input touch your queries. We TOLD you this dynamic web stuff was a mistake. Static HTML never had injection attacks. Real programmers use…

> We TOLD you this dynamic web stuff was a mistake. Static HTML never had injection attacks. Your comparison is useful but wrong. I was online in 99 and the 00s when SQL injection was common, and we were telling people to stop using string interpolation for SQL! Parameterized SQL was right there! We have all of the tools to prevent these agentic security vulnerabilities, but just like with SQL injection too many peop…

> Parameterized SQL was right there!

That difference just makes the current situation even dumber, in terms of people building in castles on quicksand and hoping they can magically fix the architectural problems later.

> We have all the tools to prevent these agentic security vulnerabilities

We really don't, not in the same way that parameterized queries prevented SQL injection. There is LLM equivalent for that today, and nobody's figured out how to have it.

Instead, the secure alternative is "don't even use an LLM for this part".

Re: Claude Cowork exfiltrates files

#137

Post by niyikiza »

ramoz wrote: post #120
niyikiza wrote: post #118

Another week, another agent "allowlist" bypass. Been prototyping a "prepared statement" pattern for agents: signed capability warrants that deterministically constrain tool calls regardless of what the prompt says. Prompt injection corrupts intent, but the warrant doesn't change. Curious if anyone else is going down this path.

I would like to know more. I’m with a startup in this space. Our focus is “verifiable computing” via cryptographic assurances across governance and provenance. That includes signed credentials for capability and intent warrants.

Interesting. Are you focused on the delegation chain (how capabilities flow between agents) or the execution boundary (verifying at tool call time)? I've been mostly on the delegation side.

Working on this at github.com/tenuo-ai/tenuo. Would love to compare approaches. Email in profile?

Re: Claude Cowork exfiltrates files

#138

Post by formerly_proven »

schmichael wrote: post #73
NitpickLawyer wrote: post #64

Earlier quoted context omitted.

> as powerless as LLM companies want you to believe. This is coming from first principles, it has nothing to do with any company. This is how LLMs currently work. Again, you're trying to think about blacklisting/whitelisting, but that also doesn't work, not just in practice, but in a pure theoretical sense. You can have whatever "perfect" ACL-based solution, but if you want useful work with "outside" data, then this…

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.

Look at the popularity of agentic IDE plugins. Every user of an IDE plugin is doing it wrong. (The permission "systems" built into the agent tools themselves are literal sieves of poorly implemented substring-matching shell commands and no wholistic access mediation)

Re: Claude Cowork exfiltrates files

#139

Post by j45 »

mucle6 wrote: post #78
Tiberium wrote: post #30

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

Haha this feels like you're playing chess with the hackers

Rolling the dice in a new kind of casino.

Re: Claude Cowork exfiltrates files

#140

Post by j45 »

sebmellen wrote: post #31
Tiberium wrote: post #30

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

Pretty brilliant solution, never thought of that before.

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