[Feature]: Lightweight OS-level sandboxing alternative to openshell

[lukehinds]

Package

agent-os-kernel

Problem Statement

toolkit's OpenShell integration demonstrates OS-level isolation with application-level governance. However, OpenShell requires a lot of heavy infrastructure (Docker/OCI runtimes, k3s, gateway), which adds significant operational overhead and isn't always practical - especially for local development, CI pipelines, edge deployments, or developer workstation environments. It also limits itself to just a few target deployments - there is also only linux support (last time I checked)

nono is a popular capability-based sandboxing library and CLI that provides OS-enforced isolation using kernel-native mechanisms (Landlock on Linux, Seatbelt on macOS) -- no containers, no daemons, no infrastructure. It would slot into the same architectural position as OpenShell (providing the "walls") while the governance toolkit provides the "brain." , and could even be built natively within tool kit as nono has its own python SDK.

The toolkit's README acknowledges the gap:

"This toolkit provides application-level (Python middleware) governance, not OS kernel-level isolation."

Today, the only path to OS-level enforcement is containers via OpenShell. That's a heavy dependency for what is fundamentally a process-level concern. With nono you could have much faster and native sandboxing.

What nono provides

• Kernel-enforced sandboxing -- Landlock LSM (Linux 5.13+), Seatbelt/sandbox_init (macOS).
• Capability-based model -- allowlist-only filesystem and network access, composable deny rules, path canonicalization to prevent symlink escapes
• Native library bindings -- Python (PyO3, on PyPI), TypeScript/Node (napi-rs, on npm), Rust, C FFI. Integrates directly into agent code without shelling out.
• Supervisor mode -- transparent capability expansion via seccomp user notification (Linux). Agent requests access, supervisor prompts or applies policy, kernel injects the fd. The agent never needs to know it's sandboxed.
• Atomic snapshots - secure content addressable snapshots of all changes made by an agent.
• Audit - secure content addressable audit record of every action an agent takes

How it would compose with the governance toolkit

The integration pattern mirrors OpenShell but is lighter:

Layer	OpenShell (current)	nono (proposed)
Filesystem isolation	Container filesystem policies	Landlock/Seatbelt allowlists
Network control	Container egress rules	Landlock TCP filtering / proxy with credential injection
Process restrictions	Container seccomp profiles	Landlock + seccomp-notify
Deployment	Requires Docker/OCI runtime	In-process library call or CLI wrapper
Platform	Linux containers only	Linux (Landlock) + macOS (Seatbelt) + Windows via WSL2
SDK integration	Container orchestration API	Python, TypeScript, Rust, C native libraries

A typical integration would look like:

from nono import CapabilitySet, Sandbox

# Build capabilities from governance toolkit's policy decisions
caps = CapabilitySet()
caps.allow_read("/app/workspace")
caps.allow_write("/app/workspace/output")
caps.allow_read("/tmp")

# Apply OS-enforced sandbox -- irrevocable after this point
sandbox = Sandbox(caps)
sandbox.apply()
# Agent runs with kernel-enforced restrictions from here

Example with pydantic-ai https://github.com/always-further/pydantic-ai-fastapi-nono

The governance toolkit's ring model and trust scoring would drive which capabilities are granted. nono enforces them at the kernel level.

Key differences from OpenShell

• macOS and Windows support -- OpenShell is Linux-container only; nono supports macOS via Seatbelt and Windows via WSL2 (Landlock runs natively in the WSL2 kernel), which is particularly relevant for Microsoft's own developer ecosystem
• In-process integration -- native library bindings mean the sandbox is applied from within the agent's own process, not by wrapping it in a container
• Lighter weight -- no image pulls, no overlay filesystems, no container networking. Sandbox applies in microseconds.
• Composable with containers -- nono can also run inside containers for defense-in-depth, and also microvms (firecracker, kata etc) - many folks are running nono on top of kubernetes for orchestration

Proposed Solution

Would you be open to a nono integration doc (similar to the OpenShell one) and potentially a thin adapter in the agent-runtime package that maps ring-level permissions to nono capability sets?

Happy to collaborate on the design. The library is Apache-2.0 licensed and multiple vendors are working on the project

Alternatives Considered

No response

Priority

Important

Contribution

• I would be willing to submit a PR for this feature

[github-actions]

Welcome to the Agent Governance Toolkit! Thanks for opening your first issue.
A maintainer will review this shortly. Check our Contributing Guide.
For security issues, use private vulnerability reporting.

[github-actions]

🤖 AI Agent: contributor-guide

Hi @nono-enthusiast! 👋

Welcome to the microsoft/agent-governance-toolkit project! 🎉 We're so excited to have you here, and thank you for taking the time to open such a detailed and well-thought-out issue. Your passion for improving the toolkit is clear, and we truly appreciate your willingness to contribute!

---

🧐 Issue Analysis

Your proposal for integrating nono as a lightweight OS-level sandboxing alternative to OpenShell is compelling! You've done an excellent job outlining the problem, the benefits of nono, and how it could complement the governance toolkit. Here's how your suggestion maps to the toolkit's packages:

1. Relevant Package(s):

   • agent-os: This is the most relevant package for your proposal, as it focuses on the core policy engine and agent lifecycle. The nono integration would align with the OS-level isolation and sandboxing responsibilities of this package.
   • agent-runtime: Since you're proposing a thin adapter to map ring-level permissions to nono capability sets, this package is also relevant. It handles the runtime execution environment, making it a natural fit for this integration.

2. Relevant Code:

   • For agent-os, you might want to explore the agent-os directory to understand how the current OpenShell integration is implemented. This will give you insights into how to structure a similar integration for nono.
   • For agent-runtime, check out the agent-runtime directory to see how runtime-level policies are applied and how your proposed adapter could fit in.

---

📚 Helpful Resources

Here are some resources to help you get started with contributing to the project:

• CONTRIBUTING.md: This document outlines the contribution process, including how to set up your development environment, coding standards, and how to submit a pull request.
• QUICKSTART.md: A great place to get up and running with the toolkit quickly.
• Code of Conduct: Please take a moment to review our community guidelines to ensure a welcoming and inclusive environment for everyone.

---

🚀 Next Steps

Here’s how you can move forward with your contribution:

1. Familiarize Yourself with the Codebase:

   • Dive into the agent-os and agent-runtime directories to understand the existing architecture and how policies are currently implemented.
   • Review the OpenShell integration documentation for inspiration on how to structure the nono integration.

2. Draft a Design Proposal:

   • Since this is a significant feature, it might be helpful to create a design document outlining the integration in more detail. This could include:
     • How the governance toolkit's ring model will map to nono's capability sets.
     • Any changes or additions needed in agent-os or agent-runtime.
     • A high-level overview of the proposed API for the nono adapter.

3. Collaborate with the Community:

   • Share your design proposal in this issue or as a separate document for feedback.
   • Engage with maintainers and other contributors to refine the approach.

4. Start Small:

   • Begin by creating a draft pull request with an initial implementation of the nono integration. This doesn't have to be perfect—it's a great way to get early feedback and iterate.

5. Documentation:

   • Once the integration is ready, consider contributing a new integration guide (similar to the OpenShell one) to the docs/integrations directory.

---

Thank you again for your enthusiasm and for bringing this exciting idea to the table! If you have any questions or need guidance as you get started, don't hesitate to ask. We're here to support you every step of the way. 🚀

Looking forward to collaborating with you on this! 😊

[imran-siddique]

Great proposal, @lukehinds. The nono integration pattern makes a lot of sense — kernel-native sandboxing without container overhead fills a real gap. The macOS/WSL2 support is particularly relevant for our developer ecosystem.

We'd welcome a PR for:

1. Integration doc (similar to the OpenShell one at docs/integrations/openshell.md)
2. Thin adapter in agent-runtime mapping ring-level permissions to nono capability sets

Happy to review and iterate on the design. The capability-set model maps cleanly to our policy engine's allow/deny decisions. Label: \�nhancement, \help wanted.