As soon as I tried Claude Code it was clear to me that I want it to run in yolo mode, but safely. I can very much recommend the Eclipse Enclave sandbox which is fully open source, see https://github.com/eclipse-enclave/enclave
Humans missed 1 in 3 threats approving AI agent commands across 40k game runs
251–260 of 268 posts
Re: Humans missed 1 in 3 threats approving AI agent commands across 40k game runs
#252Earlier quoted context omitted.
> And what would you recommend for a system automation script 20 years ago, when I was 13 and discovered Linux for the first time? Like I said: > Maybe it had to be that way because we didn’t know any better … But that doesn’t make it good. I’ve gotten kind of pointlessly good at bash tricks—the weird advanced shit that Wooledge warns about. Same for Perl5: 6 years on a multimillion line healthcare monolith wishing f…
> We have vastly better tools now in those niches. But do we? I'll beg to differ. Python explodes in to LoC when you try to attempt to work with the OS. You need to source modules that turn the application in to bloat. 98% of def's you don't require. If you need a multi-purpose tool, or a model than sure. For the simple automation of running a rsync or ZFS snapshot schedule to copy to & from a NAS in a guaranteed tim…
For anything more complex than linear shell scripting, I prefer ruby --disable-gems these days. As you say, Python is horrible for composing and executing shell commands, but Ruby's FileUtils#sh (combined with %W{} array literals, %x{} output capturing and regular #{} string interpolation) provides a pretty low-impedance interface.
Re: Humans missed 1 in 3 threats approving AI agent commands across 40k game runs
#253Earlier quoted context omitted.
> We have vastly better tools now in those niches. But do we? I'll beg to differ. Python explodes in to LoC when you try to attempt to work with the OS. You need to source modules that turn the application in to bloat. 98% of def's you don't require. If you need a multi-purpose tool, or a model than sure. For the simple automation of running a rsync or ZFS snapshot schedule to copy to & from a NAS in a guaranteed tim…
> > We have vastly better tools now in those niches. > But do we? I'll beg to differ. We do. I mentioned Fish and PowerShell for interactive scripting. Those definitely handle your rsync/zsh snapshot case. If you're OK installing software, xonsh and nushell seem interesting; I briefly played with the latter and it seemed really nice. As usual, bash/zsh/dash win on ubiquity, but ubiquity and quality are utterly discon…
I'll agree to disagree; on this. It's moot at this point. I do however respect your view. Zfs, rSync were just basic examples but where you need to schedule OS commands, zfs snapshots, sync or other system utilities Bash will always be my go to wrapper for it's native-ness to the shell. Maybe my head is more warped for the archaic type of language as I do enjoy Perl however using both Bash and Python is no crime. One orchestrates, one executes.
I don't use Linux and I come from the Unix side of things, FreeBSD is my daily driver, server OS of choice and my father was a Telecoms/unix engineer, maybe that's why. Myself I'm not keen on Python and would personally use something more rough, like ruby if bash was to exit though the door.
I've encountered work systems where backups were performed worked, based on a bash script and everything else on the system was bricked. Nothing would work apart from a shell and a bash script.
I don't disagree, the popularity of Python does make ease. The ecosystem is verse and if someone leaves, someone can pickup where they left up pretty quickly. I just had to shred my (Tcl) PXE server project this week that I created for the VisualFX company gig I'm currently working at.
Now that they are wanting it being Python based, it's soul destroying to get it thrown back in the face when it's been powering company infrastructure for a year only for a LLM to regurgitate what you've worked on for a hard year. It worked flawlessly only for it to produce a Python equivalent in seconds. Python interacting with tFTP, PXE, HTTP , self-generation of Kickstart files, dhcp .. it's a mess and that's what I mean in LoC. 400 lines of Tcl and it works a one click button button.
Maybe I am bias against python because all projects are now within the: "It must be python!" attitude but maybe back in the 80's it was "It must be perl!". I don't know, I only picked up the tail-end of the camel being only 37. Python feels like a constant washed used towel passed from engineer to engineer.
My feel is that a company should be using multiple languages but that costs money. My own project runs on NaviServer, Tcl and Crystal and it glues well but Tcl always was a glue language.
Each to their own, Python isn't for me, it has it's own merits and happy to agree with but I'm not going to praise it to as a shell based language. Python can be a ungodly mess, which I find when you start to incorporate it with relic system services. The debt that LLM's are piling on it isn't healthy.
Re: Humans missed 1 in 3 threats approving AI agent commands across 40k game runs
#254Earlier quoted context omitted.
> > We have vastly better tools now in those niches. > But do we? I'll beg to differ. We do. I mentioned Fish and PowerShell for interactive scripting. Those definitely handle your rsync/zsh snapshot case. If you're OK installing software, xonsh and nushell seem interesting; I briefly played with the latter and it seemed really nice. As usual, bash/zsh/dash win on ubiquity, but ubiquity and quality are utterly discon…
I'll agree to disagree; on this. It's moot at this point. I do however respect your view. Zfs, rSync were just basic examples but where you need to schedule OS commands, zfs snapshots, sync or other system utilities Bash will always be my go to wrapper for it's native-ness to the shell. Maybe my head is more warped for the archaic type of language as I do enjoy Perl however using both Bash and Python is no crime. One…
That's all fair.
I don't think we should abolish sh or anything; it's one of the only truly ubiquitous tools. And folks should know it, the same way they should know nano or ed or whatnot in case they ever get on a system without vim. I just wish it weren't the first resort for so many tasks, you know?
Nitty:
> I've encountered work systems where backups were performed work, based on a bash script and everything else on the system was bricked
I've had better luck with Python in those cases. Even when the shell works, some of the programs my shell scripts call out to are often damaged by whatever broke the system. Python's capabilities are more or less present in memory after "import" and rely on fewer external programs in most cases.
We're similarly aged; I think you might be lucky to have had a lot of fun with tools like Perl early in your career. I got dumped into something of a shell/C/Perl salt mine and had to develop deep expertise in things that I saw more mis-use of than benefit from, so when I discovered alternatives they felt a lot more compelling. Different strokes for different folks I guess. At least we can be thankful that Perl and Python got popular for automation before JavaScript did.
Thanks for the thoughtful replies.
Re: Humans missed 1 in 3 threats approving AI agent commands across 40k game runs
#255Earlier quoted context omitted.
What would passwords move past too? A device people lose? Some specifications everyone argues about and implements differently. Just look at SAML and everyone using slightly different terminology. Security is more annoying because the attacks are better than ever.
Certificates seemed promising there for a while. I also don't mind hardware keys/cards, but when you have to first enter your password, then your pin for your hardware key and then touch the hardware key it gets ridiculous again. Not a fan of biometrics, though, as that cannot be changed trivially. Ideally, authentication should happen like entering a building. You do that _once_ at the beginning of a day by swiping…
>but that hasn't prompted us to play security theater around every building entrance
Um, then you're just not going into any secured buildings. There are places where you must always have a badge showing. Or, you must always be with another known member of staff keeping an eye on you. Often these places have locks on every door with access levels.
It really just sounds like you're a bit less experienced with security in this case.
Re: Humans missed 1 in 3 threats approving AI agent commands across 40k game runs
#256Earlier quoted context omitted.
Certificates seemed promising there for a while. I also don't mind hardware keys/cards, but when you have to first enter your password, then your pin for your hardware key and then touch the hardware key it gets ridiculous again. Not a fan of biometrics, though, as that cannot be changed trivially. Ideally, authentication should happen like entering a building. You do that _once_ at the beginning of a day by swiping…
>but that hasn't prompted us to play security theater around every building entrance Um, then you're just not going into any secured buildings. There are places where you must always have a badge showing. Or, you must always be with another known member of staff keeping an eye on you. Often these places have locks on every door with access levels. It really just sounds like you're a bit less experienced with security…
Notice how none of that is a cumbersome user experience. I put a badge on my person and maybe have someone walk beside me and that's it. I notably do not have to unlock the same door over and over again by first entering a password and then entering a pin and then touching my hardware key. Again and again,.. and again.
As for personal experience, the most secure facility I entered so far was a data center. It was not annoying to get in and out of that either, despite a whole lot of security.
Re: Humans missed 1 in 3 threats approving AI agent commands across 40k game runs
#257My team is working on Watcher to deal with exactly this. We know that Claude is occasionally going to do stuff we really don't want, but at a rate that's way too low for manual approvals to make sense, so we hook into Claude Code (or Codex) to approve commands in a way that's a lot closer to `--dangerously-skip-permissions` but without the danger. We use a hierarchy of deterministic rules and heavily-tested LLM monit…
"We don't trust the llm, so we built a tool that uses the llm to check if the llm can be trusted"
Yeah, this is a real problem that we work to resolve. Partly it's a defence-in-depth approach, and having an LLM check the actions of a coding agent does reduce the likelihood of dangerous actions going through even if it's not perfect. There's also a benefit to using a separate instance of the same model, or a different model that doesn't have correlated failure modes with the agent it's monitoring.
In the cases where you can deterministically block actions, with sandboxes and file permissions, that's better than relying on an LLM. But that doesn't work for all actions, as the OP shows.
Re: Humans missed 1 in 3 threats approving AI agent commands across 40k game runs
#258Earlier quoted context omitted.
> I think minority do Let's be real, the minority of people understand bash. It is a terrible language with tons of footguns[0], albeit a very useful language and still worth learning. The number of ~/.claude/settings.json I've seen with "permissions": { "allow": ["Bash(find *)"]} I've seen is crazy[1]. Hell, most people I talk to think `find` is a tool that is used for searching for files. I mean... it does that...…
> It is a terrible language It's not. It only becomes terrible when you misuse for it's original purpose. Microsoft Excel isn't terrible, but the way it gets used makes it terrible.
I love bash. I write a lot of bash too. It is a extremely powerful and useful language. But that also doesn't mean it is a good language.
There are many non-intuitive things, hence that pitfalls page I linked. You can't just deflect and say that the user is "holding it wrong". If it is difficult and unintuitive in how to "hold" it correctly, that's a design problem, not a user problem.
Despite bash being a terrible language, I still use it on a daily basis because it is useful. But don't conflate these things.
Re: Humans missed 1 in 3 threats approving AI agent commands across 40k game runs
#259Earlier quoted context omitted.
> We have vastly better tools now in those niches. But do we? I'll beg to differ. Python explodes in to LoC when you try to attempt to work with the OS. You need to source modules that turn the application in to bloat. 98% of def's you don't require. If you need a multi-purpose tool, or a model than sure. For the simple automation of running a rsync or ZFS snapshot schedule to copy to & from a NAS in a guaranteed tim…
from subprocess import run from sys import argv source = argv[1] destination = argv[2] run([ "rsync", "-zavp", source, destination ]) vs #!/usr/bin/env bash source="$1" destination="$2" rsync \ -zavp \ "$source" \ "$destination" the overhead is not really that bad imo
That's not really what people mean. Your example isn't accurate because you just ran bash two different ways.
Re: Humans missed 1 in 3 threats approving AI agent commands across 40k game runs
#260Earlier quoted context omitted.
I think minority do. Imagine, you have been vibe-coding this project for a while and it works kind of fine but you just have to fix a few more bugs and you get something like `node /tmp/claude-1000/-home-user-source-github-user-hn/27b740b1-9a45-47f3-ab99-61e5e3cf779a/scratchpad/hidden-smoke.mjs; echo "exit=$?"`. (I took it from my own agent right now and I don't have any idea what it's doing. Thankfully, it's sandbox…
> I think minority do Let's be real, the minority of people understand bash. It is a terrible language with tons of footguns[0], albeit a very useful language and still worth learning. The number of ~/.claude/settings.json I've seen with "permissions": { "allow": ["Bash(find *)"]} I've seen is crazy[1]. Hell, most people I talk to think `find` is a tool that is used for searching for files. I mean... it does that...…
`find` isn't a Bash built-in and has basically nothing to do with Bash as a language. Not knowing `find` is a basic Unix literacy issue, not a Bash language footgun.
You're right that Bash is full of footguns, especially around quoting. And you're also right that that issue is even worse— and I think it's somewhat representative. Some of the cited Bash footguns are also about general lack of familiarity with CLI conventions and stringly typed data generally, like the dirname quoting issue.