How to Run an AI Agent Locally Without Leaking Your SSH Keys

When you run a utility like Claude Code, OpenCode, or any other autonomous agent directly in the console, a slight sense of unease creeps in. We're giving a third-party language model the right to execute commands in the terminal, read files, and modify source code. Meanwhile, the process retains the same rights as your local user by default. The model can accidentally read the .env file, poke around in ~/.ssh/id_rsa, or download configs from your home directory.

Usually, people spin up Docker containers or virtual machines for security. But that's inconvenient for daily work. Containers take forever to start, consume gigabytes of RAM, and require constant folder mounting configuration.

The nono project offers a different solution. It's created by the team that previously launched Sigstore — a package digital signing standard used by PyPI, npm, and Homebrew.

Process Isolation in Fractions of a Second

The tool creates a sandbox for any AI process without using containers, background daemons, or virtual disks. You simply wrap your agent launch in one CLI command, and the process immediately ends up in a restricted environment.

The project code is written in Rust. macOS, Linux, and Windows via WSL2 are supported.

Here's what launching an agent looks like:

nono search opencode
nono run --profile nolabs-ai/opencode -- opencode

After this command, opencode can only read and edit files in the current folder. All other directories on disk, private SSH keys, and global system variables become completely invisible to the process.

Working with Security Profiles

Access settings are stored in a special registry at registry.nono.sh. There are ready-made profiles for popular tools. A profile describes file access rules, allowed network hosts, and token forwarding options.

If a ready-made profile from the registry doesn't suit you, it's easy to customize:

nono profile init opencode --extends nolabs-ai/opencode
nono run --profile opencode -- opencode

The command will generate a JSON file with declarative configuration. You can edit it, save it to your company's Git, and use it across the team.

External Utility Isolation and Token Proxying

The most interesting part of nono is how the project works with external tools. Agents rarely work in isolated vacuum. Usually they call utilities like git, gh, kubectl or launch MCP servers.

Standard sandboxes give the agent either full network and key access, or cut everything off. In nono, utilities are launched in separate child sandboxes with their own policies.

The workflow looks like this:

• The agent wants to run git, but the child process only gets access to the repository directory and Git's service files.
• The agent requests to work with gh, but the raw GitHub token doesn't reach the agent's memory at all.
• Requests go through a built-in proxy server where you can configure filtering at the HTTP method level.
• You can allow the agent to only read the issue list via GET requests to the API, blocking repository deletion and pushes to the main branch.

Access policy is fixed in the configuration file. The agent cannot change these rules from within or extract authorization credentials from memory.

Example config with GitHub API access restriction:

{
  "command_policies": {
    "credentials": {
      "github-api": {
        "type": "proxy",
        "upstream": "https://api.github.com",
        "credential_key": "keyring://gh:github.com/example?decode=go-keyring",
        "env_var": "GH_TOKEN",
        "inject_header": "Authorization",
        "credential_format": "Bearer {}"
      }
    },
    "commands": {
      "gh": {
        "from": {
          "session": {
            "sandbox": {
              "fs_read": ["."],
              "credentials": [
                {
                  "name": "github-api",
                  "endpoint_policy": {
                    "default": "deny",
                    "allow": [
                      { "method": "GET", "path": "/repos/nolabs-ai/nono/issues/**" }
                    ]
                  }
                }
              ]
            }
          }
        }
      }
    }
  }
}

Ready-Made Libraries for Different Languages

The developers didn't limit the project to a CLI utility. If you're writing your own AI agent or service framework, you can embed permission restriction right into the application code.

The repository has ready-made FFI bindings:

• Python (nono-py)
• TypeScript (nono-ts)
• Go (nono-go)
• Rust (native library)

Quick Start

Installing the utility on macOS via Homebrew takes one command:

brew install nono

For other platforms, a standard installation script is available:

curl -fsSL https://nono.sh/install.sh | sh

The project is distributed under the Apache-2.0 license. The code is open, and the repository already has over 3,000 stars on GitHub.

Is It Worth Installing

If you use console AI agents like Claude Code, OpenCode daily, or develop your own MCP-based tools, take a look at nono. It's a convenient way to stop worrying about the safety of SSH keys and cloud access, without sacrificing terminal speed.