* Package name    : nono
  Version         : 0.81.0
  Upstream Contact: nolab
* URL             : https://github.com/nolabs-ai/nono
* License         : Apache-2.0
  Programming Lang: Rust
  Description     : runtime security and sandboxing for AI agents

nono provides an unprivileged security runtime for AI agents and
agent-controlled tools. It restricts filesystem, network, credential,
and process access according to explicit policies, reducing the effect
of unsafe agent actions, malicious instructions, compromised tools,
and overly broad user approvals.

On Linux, nono uses the Landlock Linux Security Module for
kernel-enforced filesystem restrictions. Depending on the available
kernel and Landlock ABI, it can also restrict supported network and
inter-process operations. The restrictions are inherited by child
processes and cannot be relaxed by the sandboxed process.

nono also provides facilities beyond basic Landlock sandboxing,
including:

 * per-agent and per-tool security profiles;
 * filesystem access allow-lists;
 * protection of sensitive paths such as SSH, GnuPG, cloud, container,
   and Kubernetes credentials;
 * network destination and HTTP method or path restrictions;
 * proxy-based credential injection that avoids exposing the original
   credential to a sandboxed process;
 * command and tool invocation policies;
 * cryptographically verifiable audit records;
 * verification of agent skills, hooks, and instruction files;
 * snapshots and rollback of agent-generated file changes.

The program is intended for use with interactive coding agents and
other autonomous or semi-autonomous tools. Supported workflows include
agents such as Claude Code, Codex, Copilot, OpenCode, Goose, and custom
agents built with common agent frameworks. It can also sandbox
individual tools invoked by an agent, with separate permissions for
each tool.

This package is relevant because AI agents commonly execute commands
with all the privileges and credentials of the invoking user. Repeated
interactive approval prompts are not a reliable security boundary:
users may approve operations without fully reviewing the command, its
child processes, or its eventual network effects. An agent may also be
influenced by untrusted repository content, generated instructions,
dependencies, tool output, or prompt injection.

nono applies an external, kernel-enforced policy that remains in effect
after a command has been approved. For example, a policy may permit an
agent to modify the current source tree while preventing it from
reading ~/.ssh, ~/.gnupg, ~/.aws, ~/.kube, unrelated repositories, or
private security material. Network and credential policies may further
prevent an approved command from transmitting data to an unapproved
service.

nono does not replace system-wide mandatory access-control systems such
as AppArmor, SELinux, or TOMOYO. Those systems are administered at the
host level and can enforce policy across users, services, and the
complete system. nono instead provides an application-scoped,
unprivileged security boundary for a process and its descendants. It
can be used together with an existing LSM policy, containers, virtual
machines, or separate Unix accounts as part of defence in depth.

Debian already provides general-purpose sandboxing tools, including
landrun, go-landlock, firejail, and bubblewrap. landrun and go-landlock
provide relatively small, general-purpose interfaces to Landlock.
firejail and bubblewrap primarily use namespaces and related Linux
isolation mechanisms. nono differs by focusing specifically on the
security model and workflows of AI agents. In particular, it combines
kernel-enforced sandboxing with per-tool policies, credential
brokering, network and application-layer restrictions, audit records,
trusted agent packages, and recovery facilities.

The upstream project currently publishes prebuilt Debian-format
packages through GitHub Releases. These are upstream binary artifacts
and are not packages built from source by the Debian build
infrastructure. Packaging nono in Debian would provide reproducible
source builds, Debian dependency tracking, architecture builds,
integration with normal APT upgrades, and review under Debian Policy.

I intend to maintain this package with help from the Debian Rust
Packaging Team, subject to the team's acceptance. The upstream source
is a Rust workspace, so packaging will require reviewing its Cargo
dependency closure and identifying dependencies that are not yet
available in Debian. I plan to use the Debian Rust tooling and policy,
including debcargo and dh-cargo where applicable.

I am looking for co-maintainers interested in Linux sandboxing,
Landlock, Rust, and AI-agent security. I will also need a sponsor for
the initial upload because I am not currently a Debian Developer.