>_ DevTrendsde

Sprache

Start

Sprachen

Bereiche

Frontend Backend Mobile DevOps AI / ML GameDev Blockchain Embedded Sicherheit
Rust

So führen Sie einen KI-Agenten lokal aus, ohne Ihre SSH-Schlüssel zu leaken

Wenn Sie ein Tool wie Claude Code, OpenCode oder einen anderen autonomen Agenten direkt in der Konsole ausführen, stellt sich ein leichtes Unbehagen ein. Wir geben einem Drittanbieter-Sprachmodell das Recht, Befehle im Terminal auszuführen, Dateien zu lesen und Quellcode zu ändern. Standardmäßig behält der Prozess dabei die gleichen Rechte wie Ihr lokaler Benutzer. Das Modell könnte versehentlich die .env-Datei lesen, in ~/.ssh/id_rsa herumschnüffeln oder Konfigurationsdateien aus Ihrem Home-Verzeichnis herunterladen.

Normalerweise nutzen Menschen Docker-Container oder virtuelle Maschinen für Sicherheit. Aber das ist für die tägliche Arbeit unpraktisch. Container brauchen ewig zum Starten, verbrauchen Gigabytes RAM und erfordern ständige Ordner-Mount-Konfiguration.

Das nono-Projekt bietet eine andere Lösung. Es wurde vom Team entwickelt, das zuvor Sigstore gestartet hat – einen Standard für digitale Paketsignaturen, der von PyPI, npm und Homebrew verwendet wird.

nono logo

Prozessisolierung in Bruchteilen einer Sekunde

Das Tool erstellt eine Sandbox für jeden KI-Prozess, ohne Container, Hintergrund-Daemons oder virtuelle Festplatten zu verwenden. Sie wickeln den Agenten-Start einfach mit einem CLI-Befehl ab, und der Prozess landet sofort in einer eingeschränkten Umgebung.

Der Projektcode ist in Rust geschrieben. macOS, Linux und Windows über WSL2 werden unterstützt.

So sieht das Starten eines Agenten aus:

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

Danach kann opencode nur Dateien im aktuellen Ordner lesen und bearbeiten. Alle anderen Verzeichnisse auf der Festplatte, private SSH-Schlüssel und globale Systemvariablen werden für den Prozess vollständig unsichtbar.

Arbeiten mit Sicherheitsprofilen

Zugriffseinstellungen werden in einem speziellen Registry unter registry.nono.sh gespeichert. Es gibt fertige Profile für beliebte Tools. Ein Profil beschreibt Dateizugriffsregeln, erlaubte Netzwerk-Hosts und Token-Weiterleitungsoptionen.

Wenn ein fertiges Profil aus dem Registry nicht passt, lässt es sich einfach anpassen:

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

Der Befehl generiert eine JSON-Datei mit deklarativer Konfiguration. Sie können sie bearbeiten, in Ihrem Git des Unternehmens speichern und teamübergreifend nutzen.

Isolierung externer Tools und Token-Proxying

Der interessanteste Teil von nono ist, wie das Projekt mit externen Tools arbeitet. Agenten arbeiten selten in isoliertem Vakuum. Normalerweise rufen sie Hilfsprogramme wie git, gh, kubectl auf oder starten MCP-Server.

Standard-Sandboxes gewähren dem Agenten entweder vollständigen Netzwerk- und Schlüsselzugriff, oder schneiden alles ab. In nono werden Tools in separaten Kind-Sandboxes mit eigenen Richtlinien gestartet.

Der Workflow sieht so aus:

  • Der Agent möchte git ausführen, aber der untergeordnete Prozess erhält nur Zugriff auf das Repository-Verzeichnis und die Git-Dienstdateien.
  • Der Agent möchte mit gh arbeiten, aber das echte GitHub-Token erreicht den Speicher des Agenten überhaupt nicht.
  • Anfragen werden durch einen eingebauten Proxy-Server geleitet, wo Sie Filterung auf HTTP-Methodenebene konfigurieren können.
  • Sie können dem Agenten nur erlauben, die Issue-Liste über GET-Anfragen an die API zu lesen und Repository-Löschungen sowie Pushes auf den Main-Branch zu blockieren.

Die Zugriffsrichtlinie ist in der Konfigurationsdatei festgelegt. Der Agent kann diese Regeln nicht von innen ändern oder Autorisierungsdaten aus dem Speicher extrahieren.

Beispielkonfiguration mit GitHub-API-Zugriffseinschränkung:

{
  "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/**" }
                    ]
                  }
                }
              ]
            }
          }
        }
      }
    }
  }
}

Fertige Bibliotheken für verschiedene Sprachen

Die Entwickler haben das Projekt nicht auf ein CLI-Tool beschränkt. Wenn Sie Ihren eigenen KI-Agenten oder Ihr Service-Framework schreiben, können Sie die Berechtigungseinschränkung direkt in den Anwendungscode einbetten.

Im Repository gibt es fertige FFI-Bindings:

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

Schnellstart

Die Installation des Tools auf macOS über Homebrew dauert einen Befehl:

brew install nono

Für andere Plattformen ist ein Standard-Installationsskript verfügbar:

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

Das Projekt wird unter der Apache-2.0-Lizenz vertrieben. Der Code ist offen, und das Repository hat bereits über 3.000 Sterne auf GitHub.

Lohnt sich die Installation

Wenn Sie Konsolen-KI-Agenten wie Claude Code, OpenCode täglich nutzen oder eigene MCP-basierte Tools entwickeln, werfen Sie einen Blick auf nono. Es ist eine bequeme Möglichkeit, sich keine Sorgen mehr um die Sicherheit von SSH-Schlüsseln und Cloud-Zugriff zu machen, ohne die Terminalgeschwindigkeit zu opfern.

Ähnliche Projekte