Live data from Hacker News

The ways we contain Claude across products

anthropic.com

41–50 of 128 posts

Re: The ways we contain Claude across products

#41
post #16

The framing they use is hilarious and their little graphic is perfect. The risk of harm doesn't go down, but the reward goes up, so the harm just becomes the cost of doing business, justified by the reward. So as the reward gets higher and higher, the amount of harm they're willing to justify goes up. Feels like society in a nutshell.

Yeah I was thinking about Simon Wilson's "lethal trifecta"[0] in the context of OpenClaw style "general purpose" AI agents, where people just gave it access to their full hard drive, gmail account, etc. I was thinking you can't make the chance of catastrophic failure zero (we still hear about "Claude deleted my home folder"), but you can definitely limit the blast radius. You can't get the risk to zero. But the oppor…

> But the opportunity cost of not playing the game is rising

The opportunity cost of not using OpenClaw? I don't think it's that foundational yet that there is an opportunity cost to not using it. Most people have no purpose for a general-purpose AI both in their personal lives and at work, there is no sense trying out OpenClaw when you don't even know what it'll do.

Re: The ways we contain Claude across products

#42
I recently threw together a nutshell helper function that lets me launch a process using bubblewrap to only give it read/write access to the directory I run it from (plus a couple of specific Linux system directories so that stuff like GUI and libportal will work) with everything else being read-only. This is a lot less annoying than a container for stuff where I legitimately want to be able to point agents at random stuff in other places (screenshots, log files, etc.) but also want to just blanket enable things so I don't need to babysit things to approve them manually over and over. It's pretty odd to me that this sort of experience isn't already being invested in by AI tooling platforms; the impetus for doing this was that I was frustrated that Zed, the editor with the entire premise of being used for AI stuff like this, only supports putting permissions for specific paths in the user-wide settings file; project-level settings files exist, but for reasons I can't fathom, they explicitly don't support any of the permissions settings for agents.

Re: The ways we contain Claude across products

#43

I'm intensely skeptical about anything Anthropic says, because they are so incented to make their products seem dangerous (i.e., "capable", "science fiction", "ahead of everyone") ahead of their IPO. And they've done it before. Remember the whole "when threatened, the model would use an engineer's email to blackmail him about his affair" nonsense? That was just fan fiction. They simply created a scenario with some fa…

> They simply created a scenario with some facts and asked their model to continue the story.

Yes. That's the whole point. They are doing research. Anthropic literally starts their description of the blackmail test observations saying that it is a test scenario using a fictional company.

> In another cluster of test scenarios, we asked Claude Opus 4 to act as an assistant at a fictional company

https://www.anthropic.com/claude-4-system-card

Re: The ways we contain Claude across products

#44

The framing they use is hilarious and their little graphic is perfect. The risk of harm doesn't go down, but the reward goes up, so the harm just becomes the cost of doing business, justified by the reward. So as the reward gets higher and higher, the amount of harm they're willing to justify goes up. Feels like society in a nutshell.

If I understand this correctly, Anthropic's argument is now "yes this will blow up some of your infrastructure, but it will be worth it"

The problem is that no one has been able to prove that it is actually worth the cost. That is a very fragile assumption.

Re: The ways we contain Claude across products

#45
post #32

>As agents grow more capable, so does their potential blast radius. The engineering question is how to cap it. People get a bit upset these days when you personify an LLM, but worse than that I think is to pretend that LLMs work on some movie logic where they can sneak out on to the internet like some kind of ooze and begin replication.

Well, the problem is that we train them to solve problems and follow instructions given, and so if you ask them to do something and they work through the logic and figure that the easiest way is to do something else like delete the production database, if they have access to do so they will go through all your creds and find the databse creds and go delete the production database. They are getting better and better a…

>Well, the problem is that we train them to solve problems and follow instructions given, and so if you ask them to do something and they work through the logic and figure that the easiest way is to do something else like delete the production database, if they have access to do so they will go through all your creds and find the databse creds and go delete the production database.

I lost the root password to a small debian box I was messing around with and on a whim gave an agent the OS version and SSH user details. I had a look and there were open privilege escalation attacks for it. I just said go nuts and sort yourself out. It refused out of hand.

Thats not to say they will all do that but legally speaking I expect most of them to end up there.

In terms of production database deletion thats user error. If you expose production resources in literally any capacity to what is effectively a random command generator that reflects on the operator. I am neither impressed nor unimpressed that they figure out how to delete a production db, junior engineers (and even seniors) have been deleting production resources in front of customers for ages.

>It's not exactly like they're ooze that will escape and begin replication; but just that the more you give them access to to, the higher the likelihood at some point they will logically conclude that they need to do something that you would find undesirable, but either haven't explicitly told them not to do, or their context just got too complicated and that instruction ended up being considered lower weight than the others so they do what the other instructions say instead.

Dont do it. If you dont want the resource accessed dont expose it. The people getting done are operating dirty. Leaving production secrets where they can be accessed. This isnt impressive AI, its just enumeration that attacker would have found with the same access.

>I have seen them conclude that in order to do what they need to do, they would need API keys to access a service. But they don't have those API keys. But you do because you can access it in the browser. So they write a Python script that will scrape the cookies out of the browser so they can use that to access the service; a problem that was only stopped because Crowdstrike didn't like a novel Python script that was trying to scrape cookies out of a browser, not because of any sandboxing actually in place on the agent.

Again this just sounds like a dirty work environment. I have a laptop that I have kept intentionally separate, frequently wiped and usually powered off for dirty work. If I was going to run a non hobby agent on my daily driver it would be in a container or VM.

Re: The ways we contain Claude across products

#46

I have been thinking about this a lot. I just bought a rather expensive rig for local inference for a home agent (powered by four RTX PRO 6000 Blackwell Max-Qs). As I contemplate handing it more and more of the keys to my life, I grow increasingly concerned about what is, to me, the primary risk of this. Not data destruction (automated backups are trivial), but data exfiltration. Specifically, via prompt injection. M…

>rig for local inference for a home agent (powered by four RTX PRO 6000 Blackwell Max-Qs)

can you elaborate at all on what sort of rig you went with, beyond the big $$ GPUs?

Re: The ways we contain Claude across products

#47
post #2

One attack they missed in the egress proxy is exfiltration via domain fronting. Putting together a full PoC would require a fastly account so I couldn't be bothered to report it. Although, testing again, it might be fixed now.

Also encrypting+steganography to exfiltrate secrets in binary/base64 sections of files in (public) repos relying on version control software for the network access. And side channels based on timing/ordering allowed network accesses, e.g. https://allowed.site/0 and https://allowed.site/1 . There's essentially no prevention against exfiltration prompt injections without a full classified data processing system that pr…

I've been working on addressing the exfiltration leg as well as the other legs of the lethal trifecta in my OrcaBot [0][1] platform and I thought I had it mostly covered with the help of a network snitch and egress allowlist until I read these comments.

Domain fronting and Steganography in commits to public repos are not solved and probably in all honesty not completely solvable. I wonder if this well end up like in banking where no bank can completely eliminate fraud. I've got some ideas to do bank like fraud detection within OrcaBot now so might be able to limit the impact a little. Thank you!

[0] https://orcabot.com/blog#breaking-the-lethal-trifecta

[1] https://github.com/Hyper-Int/OrcaBot

Re: The ways we contain Claude across products

#48
post #14

Earlier quoted context omitted.

Sure. You start a PC repair business. At first, losing a stick of RAM or frying someone's motherboard is super costly when you are doing 10 a week. But once you're doing 1000, that's pretty damn good and easily covered. When you have more tools, velocity, and whatnot, the proportions change.

Wouldn't you lose multiple sticks or fry multiple motherboards as you scale and do 1000? If you're frying 1 at 10, that means you're frying 100 at 1000. Your costs etc will scale as well unless you actually lower the risk/reward ratio, no?

I think the point is that at small scale a single accident poses a risk of ruin to your small operations.
Post reply on HN