91–100 of 132 posts
Earlier quoted context omitted.
But you're not actually hijacking the agent if you start a new process.
The agent wrote the code that triggered a vuln and allowed you to start the process
I would not really call this a prompt injection attack, since it doesn't really hijack the agent to become malicious (something the article does discuss later on). It's more a trojan that's aimed at tricking Claude specifically.
Yeah I jumped on this quite excitedly but it's not prompt injection at all. To be fair to the authors they don't actually say it is. But then they contrast it with the "0.00% prompt injection attack success rate". The upshot is kinda the same - this is still evidence that we should be sandboxing our agents. But it doesn't actually challenge Anthropic's "our models are too clever to prompt-inject" vibe.
The tweet literally says: "turns out you can get indirect prompt injection to ~0 on unseen attacks... auto mode is default in claude code as of next week"
Making the assertion, quite clearly in my opinion, that the reason auto mode is default is because he feels the lack of successful prompt injection attacks makes auto mode safe. This blog post proves that you can break auto mode's safety, even if it's not technically through a textbook indirect prompt injection attack.
Earlier quoted context omitted.
I made changes to my dependency lists in the same code where Claude ran npm update. The lockfile diff was a few hundred lines after I undid what Claude did. And yes, eventually I did check the lockfile changes and spotted the problem. I just usually don't check the lockfile that throughly.
> I made changes to my dependency lists in the same code where Claude ran npm update. ...but was it in the same commit? Two "update lockfile" commits, one yours and one Claude's should have made this obvious, no? Here's another useful rule of thumb: never mix your changes with the agent's changes. Agent always starts with a clean repository (no pending, uncommited human changes). You always start with with a clean re…
> never mix your changes with the agent's changes
yeah, but if you don't want to lose your existing context sometimes you have to. When I do, I tell claude to check the diff on the files I changed, which is quite annoying to be honest. But still easier than telling claude to do _very specific line-change_ on file X.
Earlier quoted context omitted.
The point is that auto mode gives people a false sense of security that leads them to believe they don't need to run Claude in a proper sandbox. This same attack running in a sandbox (even in YOLO mode) would be comparatively harmless.
Can you suggest a proper sandbox on mac? One that allows both me and the agent to interact with the processes? Where it can drive browser, for both oauth setup and runtime visual inspection? I've tried building docker setups, but can't figure out the browser driving part.
Earlier quoted context omitted.
Auto mode is for people who just keep hitting "YES" on everything, it's a bit better than that. But it's real easy to give auto mode instructions (like "always ask before deploy") and then bypass that just normally.
I'm not sure I agree. It's easy to "give" instructions, but Claude routinely "forgets" to follow certain instructions, such as "always using the Edit Tool". Just this week it started to use bash with string concatenation to work around some commands that were blocked in settings.json
It plays itself.
I would not really call this a prompt injection attack, since it doesn't really hijack the agent to become malicious (something the article does discuss later on). It's more a trojan that's aimed at tricking Claude specifically.
>But it runs that decoder inside the attacker-controlled directory (unzipped archive) >There a malicious struct.py shadows Python’s standard implementation I ran into this myself, where some file I had given a random name turned out to shadow some Python standard library module, giving me the weirdest startup crash ever. That definitely doesn't seem to me like how that should be designed, magically silently importing…
Modern Python supports various options, notably `-I` (isolated) and `-P` (`PYTHONSAFEPATH`, implied by `-I`) to help with this. But neither prevent shadowing. For a robust solution, you should typically structure your code into packages and use absolute imports. Here's a decent primer on the topic:
https://www.py4u.org/blog/python-problem-with-local-modules-...
edit: `-I` is mentioned in TFA.
Earlier quoted context omitted.
Yeah I jumped on this quite excitedly but it's not prompt injection at all. To be fair to the authors they don't actually say it is. But then they contrast it with the "0.00% prompt injection attack success rate". The upshot is kinda the same - this is still evidence that we should be sandboxing our agents. But it doesn't actually challenge Anthropic's "our models are too clever to prompt-inject" vibe.
But Anthropic themselves are the ones who made the equivalence of "0.00% prompt injection attack success rate == auto-mode is safe" The tweet literally says: "turns out you can get indirect prompt injection to ~0 on unseen attacks... auto mode is default in claude code as of next week " Making the assertion, quite clearly in my opinion, that the reason auto mode is default is because he feels the lack of successful p…
I would reject "Auto Mode is safe" as a message but FWIW I am totally on board with "on aggregate, making Auto Mode the default improves the safety of Claude Code compared to the prior status quo". Coz I would say in the vast majority of cases the access classifier is doing a better job than the thing it replaced.
Anyway yeah. Like I said, conclusion is the same: we should be decoupling this from the harness. We ought to be sandboxing agents the same way we sandbox applications. I wish Claude Code would make this path smoother :(
Earlier quoted context omitted.
> I made changes to my dependency lists in the same code where Claude ran npm update. ...but was it in the same commit? Two "update lockfile" commits, one yours and one Claude's should have made this obvious, no? Here's another useful rule of thumb: never mix your changes with the agent's changes. Agent always starts with a clean repository (no pending, uncommited human changes). You always start with with a clean re…
I don't let claude make commits for me, every commit is my own. I check the diffs before commiting. > never mix your changes with the agent's changes yeah, but if you don't want to lose your existing context sometimes you have to. When I do, I tell claude to check the diff on the files I changed, which is quite annoying to be honest. But still easier than telling claude to do _very specific line-change_ on file X.
Sorry, I'm not sure I follow. What do you mean by "lose your existing context"? Can't you just... commit in turns? It's not like you're editing files while your agent's also editing in parallel, right?
Again, the trick is to treat the commits as throwaway checkpoints/packets of work. They don't need to be pretty, nor need to make sense. The point where you clean that mess up is when you're done and you're doing an interactive rebase at the end. At least that's how I work.
The problem with sandboxing is that the regular dev env (massive IDE:s, cloned megarepos, installed dependencies and so on) just won't sandbox very easily. I can't set up a "second machine" or an "isolated environment" to run claude cli in. At least not in the sense of a VM, physical hardware, container etc. Not sure what the best practices are for whitelisting tools/directories and so on, but so far the only useful…
It's not that hard, actually. You don't need VMs. You usually don't need absolute protection, just reasonable protection against the agent doing something stupid. Here's what I usually use:
A docker environment. $HOME inside docker is private to the agent and persistent (i.e. it doesn't have access to your home directory). `/tmp` is always fresh. Only the current directory (i.e. your project directory) where you start the container sandbox is exposed. Everything else is ephemeral. You can't launch the agent by accident outside of the sandbox (because the `.claude` doesn't exist in your home). The agent can only screw up the directory in which you've launched it, and nothing else. Here's my version of it: https://github.com/koute/vibebox