DEV.co
MCP Servers · nolabs-ai

nono

nono is a Rust-based sandbox runtime that executes AI agents (like Claude Code, Copilot) with zero setup and zero latency, using least-privilege policies. It isolates not just agents but also the tools they invoke (git, curl, kubectl), with granular credential and network controls enforced via composable JSON profiles.

Source: GitHub — github.com/nolabs-ai/nono
2.9k
GitHub stars
203
Forks
Rust
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositorynolabs-ai/nono
Ownernolabs-ai
Primary languageRust
LicenseApache-2.0 — OSI-approved
Stars2.9k
Forks203
Open issues143
Latest releasev0.67.1 (2026-07-06)
Last updated2026-07-07
Sourcehttps://github.com/nolabs-ai/nono

What nono is

nono provides FFI bindings (Rust, Python, TypeScript, Go) for in-process agent sandboxing on macOS, Linux, and Windows (WSL2), with a policy engine supporting filesystem grants, network allowlists, L7 filtering, credential proxying, and chained tool policies. Profiles are composed from a public registry and inherit configuration from base profiles.

Quickstart

Get the nono source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/nolabs-ai/nono.gitcd nono# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Running untrusted or third-party AI agents in production

Teams at large tech companies use nono to operationalize AI agents with strict isolation, separate tool policies, and credential proxying, preventing agent code or delegated tools from accessing unintended secrets or resources.

AI agent development and iteration

Developers can rapidly scaffold, tweak, and test agent profiles locally with `nono profile init`, then share and publish profiles to registry.nono.sh without container or VM overhead.

Supply-chain and code-execution security for LLM workflows

Built by the Sigstore team; nono enforces least-privilege policies on code execution, tool invocation, and credentials, reducing attack surface when agents call build scripts, package managers, or cloud CLIs.

Implementation considerations

  • Profiles are the policy contract; review and version-control them alongside agent code, as policies directly determine filesystem, network, and credential grants.
  • FFI bindings (Python, TypeScript, Go) allow embedding nono in applications, but each language binding is a separate repo; verify maturity and breaking-change frequency for your target language.
  • Credential injection via proxy requires keyring or environment setup; plan credential rotation and audit logging if credentials are mediated through nono's endpoint policies.
  • Tool sandboxing relies on command_policies JSON; complex multi-tool chains may require deep policy composition; test end-to-end before production deployment.
  • No disk space used per the README, but memory footprint of per-tool child sandboxes under load is not documented; benchmark against your agent's tool invocation frequency.

When to avoid it — and what to weigh

  • You need mature, stable 1.0 APIs in production today — README explicitly states APIs are stabilizing ahead of 1.0 release and may still change. Early adopters should expect migration effort and join Discord for support.
  • Your organization only uses Windows native (non-WSL2) — nono officially supports macOS, Linux, and Windows via WSL2; native Windows support is not documented, making full-organization adoption on Windows-only infrastructure unclear.
  • You require a commercial SLA or vendor support contract — Project is open-source Apache-2.0 with no documented commercial support tier. Hiring link suggests growing team, but warranty, SLA, or commercial support models are not stated.
  • Your agents run offline or in air-gapped environments — nono registry defaults to pulling profiles from registry.nono.sh and may require network connectivity for profile discovery and installation. Air-gapped deployments would need custom scaffolding and profile caching.

License & commercial use

Apache License 2.0 (Apache-2.0): permissive OSI-approved license. Allows commercial use, modification, and distribution with proper attribution and license inclusion. No patent grant limitations specific to AI or security tools.

Commercial use is permitted under Apache-2.0. However, no explicit commercial support, SLA, warranty, or indemnification is stated in the data provided. Organizations deploying nono in mission-critical workflows should clarify support model with the nolabs.ai team and review whether warranty or liability limitations apply in your jurisdiction.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationStrong
License clarityClear
Deployment complexityLow
DEV.co fitStrong
Assessment confidenceHigh
Security considerations

Least-privilege sandbox enforced by default. Key architectural strengths: child sandboxes isolate tools from agent; credential proxying prevents credential sprawl; L7 filtering on network access; supply-chain lineage via Sigstore pedigree. Considerations: API pre-1.0 means policy semantics may shift; auditing and rollback features mentioned but not detailed; no published security audit or pen-test results in data; report privately via security policy (GitHub security tab).

Alternatives to consider

Containers (Docker/Podman) + OCI runtime policies

Mature, widely adopted, but introduce startup latency and disk overhead; nono's zero-latency, zero-setup claim is a differentiator if latency is critical.

systemd-sandbox or pledge/unveil (OS-native jails)

Lower-level, OS-specific sandboxing; suitable for single-agent systems but require manual policy authoring; nono's composable profile registry and tool chaining add convenience.

Anthropic/OpenAI tool-use guardrails (LLM-native)

Enforce constraints at the model layer, not runtime; complementary to nono but do not prevent agent code from executing malicious logic or calling tools outside the model.

Software development agency

Build on nono with DEV.co software developers

Get started with a CLI install or embed nono via FFI. Build and share agent profiles on the public registry. Join the Discord community for support and best practices.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

nono FAQ

Can I use nono without the public registry?
Yes: profiles are JSON and can be scaffolded locally with `nono profile init` and version-controlled. Registry is optional; locally-defined and inherited profiles are composable.
Does nono support MCP servers and clients?
MCP is listed in topics, and docs are referenced, but README does not explain MCP sandboxing. See docs.nono.sh for details.
What is the performance impact of nested tool sandboxes?
Not documented in provided data. README states zero latency and no disk usage, but memory and CPU overhead per child sandbox should be benchmarked for your workload.
Is there a commercial support option?
Not stated in the data. Team is hiring; contact nolabs.ai or check Discord for support models beyond community channels.

Work with a software development agency

DEV.co helps companies turn open-source tools like nono into production software. Our software development services cover the full lifecycle — architecture, web development, integration, and maintenance — delivered by software developers and web developers who ship. Engage our software development agency to implement or customize it for your mcp servers stack.

Secure your AI agent workflows with nono

Get started with a CLI install or embed nono via FFI. Build and share agent profiles on the public registry. Join the Discord community for support and best practices.