AI agents: The new security frontier
AI coding agents have become indispensable for developers seeking to accelerate their workflows. These agents can open terminals, read configuration files, execute commands, and interact with cloud services. However, their power comes with a significant security risk: they run with the permissions of the person who launched them. Every file that user can read, the agent can read. Every credential in the environment variable or keychain is accessible to the agent. This broad, session-long permission model creates a dangerous attack surface. A prompt injection attack, a mistyped command, or a hallucinated path can cause the agent to leak credentials, modify production systems, or exfiltrate sensitive data. The traditional approach of placing agents inside containers or microVMs reduces the blast radius but does not solve the core problem: the agent still holds every key it was handed for the entire session.
Meet Nono: Kernel-level enforcement
Nono is an open-source runtime designed to address this exact problem. It confines AI agents at the operating system kernel, far below the application layer and below any guardrails that share the same process. Nono checks every action an agent takes against policies written in code. When an agent requests to use a tool, open a file, or reach a network endpoint, the kernel returns the verdict. Enforcement sits in the operating system itself, making it impossible for the agent to bypass the sandbox from within its own execution context.
Nono leverages kernel security features that already exist in modern operating systems: Landlock on Linux and Seatbelt on macOS. These features allow processes to drop privileges and have those privileges removed permanently for the lifetime of the process. Once the sandbox is applied, the limits are immutable. The agent cannot escalate its own permissions, nor can it read files or access resources outside the defined policy scope. On Windows, Nono currently supports the Windows Subsystem for Linux (WSL2), which runs a real Linux kernel, so Landlock enforcement applies exactly as it does on native Linux. Native Windows enforcement is under active research by the Nono team.
The problem with traditional sandboxing
Traditional sandboxing approaches, such as containers or microVMs, isolate the agent from the host system but still grant the agent broad, session-long permissions within its isolated environment. For example, if an agent is given a cloud API key to perform a specific task, that key remains available to the agent for the entire session—even after the task is complete. This creates a window of opportunity for malicious inputs or accidental misuse. Nono eliminates this by introducing a novel concept: Agent Tool Sandboxing.
Agent Tool Sandboxing: Phantom credentials and per-call scoping
Agent Tool Sandboxing is one of Nono's defining features. It hands each tool call its own scoped authority, completely independent of the permissions granted to the agent as a whole. Instead of giving the agent actual credentials, Nono provides a phantom credential—a stand-in that has no real value. The tool's file access covers only what the specific task needs. Its network reach ends at the endpoints it must hit. All authority expires automatically when the call finishes.
But how does a tool holding a phantom stand-in actually authenticate against a live service? Luke Hinds, co-founder of nolabs and creator of Nono, explains: “Nono routes the request through a trusted proxy outside the sandbox, which retrieves the real credential from secure storage – such as the operating system’s keychain, 1Password, Bitwarden, or Kubernetes Secrets – and injects it only into the request sent to the approved external API.” This means the agent never holds the real secret at any point. The real credential is retrieved by the proxy just in time and used only for that single API call. The proxy enforces the policy that the request is going to the correct endpoint and that the tool’s scope is legitimate.
This architecture provides a dramatic reduction in risk. Even if an attacker injects a prompt that tricks the agent into making a malicious API call, the sandbox will block the request because the tool's network scope is limited. Even if the agent attempts to read a sensitive file outside its allowed path, the kernel enforces the file system policy. The agent can only operate within the tight boundaries set by the tool's policy, and those boundaries are ephemeral.
Background on the creators
Nono was built by nolabs, a company founded by Luke Hinds and Stephen Parkinson. Luke Hinds is well known in the open-source security community for creating Sigstore at Red Hat. Sigstore is a signing project that has become a de facto standard for verifying where software packages come from. It enables developers to sign and verify artifacts without managing complex key infrastructure. Hinds’ experience at Red Hat and his deep understanding of software supply chain security directly influenced the design of Nono’s kernel-level enforcement and credential management. Stephen Parkinson brings additional expertise in system engineering and security architecture. Together, they recognized that the AI agent boom was creating a new class of security vulnerabilities that existing tools were not addressing.
The community response to Nono has been significant. The project has drawn more than 3,100 stars on GitHub and has seen contributions from over 80 people. Its user base includes large enterprises and teams in heavily regulated industries such as finance, healthcare, and government. James Carnegie, a staff security engineer at Datadog, is a prominent user. He states: “Datadog engineers want their agents to move fast, and we want our credentials and production systems kept safe while they do. Nono is the only sandbox that gives us both fine-grained, per-command policies and sophisticated credential management that fits existing, complex real-world toolchains.”
Comparison with other approaches
Existing solutions for AI agent security often rely on proxy servers, prompt guardrails, or container isolation. Proxy servers can inspect outgoing API calls but do not prevent the agent from reading local secrets. Prompt guardrails, typically implemented as Python decorators or middleware, run in the same process as the agent and can be tampered with if the agent is compromised. Container isolation limits file system access to the container's mount points, but inside the container the agent still has full access to all environment variables and files. MicroVMs provide stronger isolation, but they slow down agent startup and add complexity. Nono’s approach—enforcing policies at the kernel level—is more lightweight and direct. It does not require the overhead of virtualization, and it can be applied to any agent running on a Linux or macOS host. The per-tool sandboxing is something no other current tool offers at this granularity.
Potential use cases and future directions
Nono is particularly useful for enterprises that allow developers to use AI coding assistants like GitHub Copilot, Claude, or custom agents that access internal repositories, databases, and cloud services. By integrating Nono, a security team can set policies that define exactly which files, network endpoints, and credentials each agent tool can touch. For example, a code review agent might be allowed to read source code but not environment variables. A deployment agent might be allowed to call a specific CI/CD API but not access the production database. The policies are written in code and can be version-controlled, reviewed, and audited just like any other infrastructure configuration.
The Nono team is actively exploring native Windows enforcement and expanding credential backends. They are also working on integration with popular agent frameworks such as LangChain, CrewAI, and AutoGPT. As AI agents become more autonomous and capable, the need for fine-grained, kernel-enforced sandboxing will only grow. Nono represents a significant step toward making AI agents both powerful and safe.
Source:Help Net Security News