>_ hackerrepos search repos…

← top repos

nolabs-ai/nono

agent runtime security - zero trust, zero setup, zero latency agent sandboxing

▲ 6 hackers recommend 4 strongly Rust ★ 4.8k Apache-2.0 agent-runtime-securityagent-sandboxagent-securityai-agent-sandboxai-agent-securityai-agents

Recommended between 2026-02-03 and 2026-10-22. Last pushed 2026-11-02.

▲ 6 recommend · ▼ 0 criticisms

What hackers say

“we narrow down their access control with nono tool sandboxing via a customized Pi agent running headless.”

— trickleup, 2026-09-04 · strong recommendation · original comment on Hacker News ↗

show original comment

We have taken to letting our agents use specific CLIs directly and we narrow down their access control with nono tool sandboxing via a customized Pi agent running headless. We have one agent that can use the aws CLI and nono feeds in a phantom SigV4 credential and then policy limits to just read-only http methods and certain L7 filtering on paths to limit its abilities - this means we can have it monitor and debug deployment failures without it doing any damage. It was all largely based off this example https://github.com/nolabs-ai/nono/tree/main/tool-sandbox-examples/aws-cli

“We use nono [1] for this internally, essentially blocking any actions we don't want agents to be able to do without human approval.”

— sbysb, 2026-07-30 · strong recommendation · original comment on Hacker News ↗

show original comment

… but not behavior. If you are trying to actually run autonomous agents securely you need something that lives outside the harness that actually blocks actions in a way that can't be prompted around. We use nono [1] for this internally, essentially blocking any actions we don't want agents to be able to do without human approval. Our developers can just run `task claude` or whatever their harness is) and it pre-wraps it with our profile that enforces: - Filesystem: read/write only the worktree plus dev-tooling dirs (Go, Doppler, Graphite caches, git common dir); explicitly no Docker socket and it can't edit its own Claude settings files (so it can't loosen its own permissions). - Network: …

“I like nono:”

— jpeeler, 2026-06-14 · strong recommendation · original comment on Hacker News ↗

show original comment

If you don't want to do that, don't use a VM. I like nono: https://github.com/always-further/nono

“This one was posted here recently; works quite well for me:”

— virtualritz, 2026-02-03 · strong recommendation · original comment on Hacker News ↗

show original comment

This one was posted here recently; works quite well for me: https://github.com/lukehinds/nono

“Think the strongest product nth space is https://github.com/nolabs-ai/nono for what it's worth.”

— gkapur, 2026-10-22 · original comment on Hacker News ↗

show original comment

Think the strongest product nth space is https://github.com/nolabs-ai/nono for what it's worth. Plus it is a priority for that team so if you are having issues the no labs guys will likely fix it :)

“I've also heard good things about nono [1] from colleagues, but I haven't personally tried it out yet.”

— thehours, 2026-08-05 · original comment on Hacker News ↗

show original comment

I've been satisfied with using Pi inside of srt [0]. I launch with `srt pi` and get file system and network isolation. There is a seemingly infinite risk surface area to protect, but I think does a reasonable job of balancing security and convenience. I've also heard good things about nono [1] from colleagues, but I haven't personally tried it out yet. [0] https://github.com/anthropic-experimental/sandbox-runtime [1] https://github.com/nolabs-ai/nono

Badge for your README

hackers recommend badge
[![hackers recommend](https://hackerrepos.org/badge/nolabs-ai/nono.svg)](https://hackerrepos.org/repo/nolabs-ai/nono)