Live data from Hacker News

The ways we contain Claude across products

anthropic.com

91–100 of 128 posts

Re: The ways we contain Claude across products

#92

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 are more worrying than OpenAI because they are so deceptive.

Not so sure about that. At least an Anthropic whistleblower wasn't murdered in his own house.

Re: The ways we contain Claude across products

#95
> Claude Code auto mode delegates command approvals to a model-based classifier; it minimizes friction (roughly 0.4% of benign commands blocked) at the cost of missing a fraction of risky ones (~17% of overeager actions get through), so it's one layer of defense-in-depth inside a sandbox, not a substitute for one.

This is pretty alarming to read. The auto mode docs (https://code.claude.com/docs/en/auto-mode-config) do not have any such caveats, they say that it blocks anything "irreversible, destructive, or aimed outside your environment". I wouldn't even call this misleading, it's simply false to describe a guardrail with a 17% false negative rate that way.

Re: The ways we contain Claude across products

#97
post #67
post #16

Earlier quoted context omitted.

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…

Containment of the execution environment isn't really the issue. It's API tokens that were designed with coarse permission scoping so agents get more power than they need. The risk isn't that your machine gets hacked. It's that your email gets deleted, or forwarded to someone who uses it to break into your other accounts via password recovery.

[flagged]

Re: The ways we contain Claude across products

#98
post #81

Earlier quoted context omitted.

Everything you do a risk/reward equation, you just don't usually see it drawn out quite so starkly. Getting out of bed in the morning carries a risk that you'll trip and crack your head on the floor. Crossing a road carries a risk of being hit by a bus. Eating food carries a risk of choking on it. The same is true in computer security. The only truly secure computer is one you don't turn on, and even that carries som…

But if you eat food, I don't risk choking. They want us to take the risk for their reward.

What do you have in mind?

You're paying for their services to collect reward for yourself, but also deciding your own risk/reward when choosing e.g. how much access to grant Claude for any given task.

I guess there's the case where the more capable Claude is, the more someone else can use it to find vulns in your services while Anthropic collects their subscription money? But that is mitigable risk that you shipped regardless of what Anthropic is doing.

Re: The ways we contain Claude across products

#99

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.

Limited liability makes taking unlimited risks a rational choice. AI ‚only‘ scales this corporate model up and compresses the timeframe to the next disaster.

Re: The ways we contain Claude across products

#100
I'm late to this thread, but the post seems to skip the section about risks/mistakes/incidents with restricting Claude's access with containers ("pattern 1"). Doing this properly is still hard!

For example, Anthropic has shipped several bugs that allow any claude.ai/code session – which are isolated in ephemeral containers – to access and exfiltrate all of the user's other sessions, connected repos, and environment variables. The rogue/hijacked Claude could also spawn new Claude sessions with arbitrary instructions and access, regardless of the original session's constraints.

I originally wrote about this (with permission) in February[1], and most of the issues were quickly fixed. But the underlying token scope issues have regressed several times since then – including post-Mythos – so I wouldn't say that Anthropic has solved this yet.

[1]: https://www.noahlebovic.com/hacking-claude-code-on-the-web-b...

Post reply on HN