Comment exécuter un agent IA en local sans exposer vos clés SSH

Lorsque vous exécutez un utilitaire comme Claude Code, OpenCode ou tout autre agent autonome directement dans la console, une légère sensation d'inconfort s'installe. Nous donnons à un modèle de langage tiers le droit d'exécuter des commandes dans le terminal, de lire des fichiers et de modifier du code source. Pendant ce temps, le processus conserve les mêmes droits que votre utilisateur local par défaut. Le modèle peut accidentellement lire le fichier .env, fouiller dans ~/.ssh/id_rsa, ou télécharger des configs depuis votre répertoire personnel.

D'habitude, les gens déploient des conteneurs Docker ou des machines virtuelles pour la sécurité. Mais c'est peu pratique pour le travail quotidien. Les conteneurs mettent longtemps à démarrer, consomment des gigaoctets de RAM et nécessitent une configuration constante de montage de dossiers.

Le projet nono offre une solution différente. Il est créé par l'équipe qui a précédemment lancé Sigstore — une norme de signature numérique de paquets utilisée par PyPI, npm et Homebrew.

Isolation de processus en fractions de seconde

L'outil crée un bac à sable pour tout processus IA sans utiliser de conteneurs, de démons en arrière-plan ni de disques virtuels. Vous enveloppez simplement le lancement de votre agent dans une commande CLI, et le processus se retrouve immédiatement dans un environnement restreint.

Le code du projet est écrit en Rust. macOS, Linux et Windows via WSL2 sont pris en charge.

Voici à quoi ressemble le lancement d'un agent :

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

Après cette commande, opencode peut uniquement lire et éditer des fichiers dans le dossier courant. Tous les autres répertoires sur le disque, les clés SSH privées et les variables système globales deviennent complètement invisibles pour le processus.

Travailler avec les profils de sécurité

Les paramètres d'accès sont stockés dans un registre spécial à registry.nono.sh. Il existe des profils prêts à l'emploi pour les outils populaires. Un profil décrit les règles d'accès aux fichiers, les hôtes réseau autorisés et les options de transfert de jetons.

Si un profil prêt à l'emploi du registre ne vous convient pas, il est facile de le personnaliser :

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

La commande générera un fichier JSON avec une configuration déclarative. Vous pouvez l'éditer, le sauvegarder dans le Git de votre entreprise et l'utiliser au sein de l'équipe.

Isolation des utilitaires externes et proxy de jetons

La partie la plus intéressante de nono est la façon dont le projet fonctionne avec les outils externes. Les agents travaillent rarement dans un vide isolé. Habituellement, ils appellent des utilitaires comme git, gh, kubectl ou lancent des serveurs MCP.

Les sandboxes standard donnent à l'agent soit un accès complet au réseau et aux clés, soit coupent tout. Dans nono, les utilitaires sont lancés dans des sous-sandboxes séparées avec leurs propres politiques.

Le flux de travail ressemble à ceci :

• L'agent veut exécuter git, mais le processus enfant n'obtient que l'accès au répertoire du dépôt et aux fichiers de service de Git.
• L'agent demande à travailler avec gh, mais le jeton GitHub brut n'atteint pas du tout la mémoire de l'agent.
• Les requêtes passent par un serveur proxy intégré où vous pouvez configurer le filtrage au niveau de la méthode HTTP.
• Vous pouvez autoriser l'agent à uniquement lire la liste des issues via des requêtes GET vers l'API, en bloquant la suppression de dépôts et les pushs vers la branche principale.

La politique d'accès est figée dans le fichier de configuration. L'agent ne peut pas modifier ces règles de l'intérieur ni extraire les identifiants d'autorisation de la mémoire.

Exemple de config avec restriction d'accès à l'API GitHub :

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

Bibliothèques prêtes à l'emploi pour différents langages

Les développeurs n'ont pas limité le projet à un utilitaire CLI. Si vous écrivez votre propre agent IA ou votre framework de service, vous pouvez intégrer la restriction de permissions directement dans le code de l'application.

Le dépôt contient des liaisons FFI prêtes à l'emploi :

• Python (nono-py)
• TypeScript (nono-ts)
• Go (nono-go)
• Rust (bibliothèque native)

Démarrage rapide

Installer l'utilitaire sur macOS via Homebrew prend une commande :

brew install nono

Pour les autres plateformes, un script d'installation standard est disponible :

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

Le projet est distribué sous licence Apache-2.0. Le code est ouvert et le dépôt compte déjà plus de 3 000 étoiles sur GitHub.

Cela vaut-il la peine d'installer

Si vous utilisez quotidiennement des agents IA en console comme Claude Code, OpenCode, ou si vous développez vos propres outils basés sur MCP, jetez un œil à nono. C'est un moyen pratique de ne plus s'inquiéter de la sécurité des clés SSH et de l'accès cloud, sans sacrifier la vitesse du terminal.