IronCurtain

Un runtime sécurisé* pour agents IA autonomes, où la politique de sécurité est dérivée d'une constitution lisible par un humain.

*Quand quelqu'un écrit « sécurisé », vous devriez immédiatement être sceptique. Qu'entendons-nous par sécurisé ?

[!WARNING] Prototype de recherche. IronCurtain est un projet de recherche à un stade précoce qui explore comment rendre les agents IA suffisamment sûrs pour être réellement utiles. Les API, les formats de configuration et l'architecture peuvent changer. Les contributions et les retours sont les bienvenus.

Démo

Il est demandé à l'agent de cloner un dépôt et de pousser des modifications. git_clone et git_push sont tous deux escaladés par le moteur de politique, mais l'auto-approbateur les approuve automatiquement — l'entrée de confiance de l'utilisateur depuis le mode commande (Ctrl-A) fournissait une intention claire, donc aucune commande manuelle /approve n'a été nécessaire.

Le problème

Les agents IA autonomes peuvent gérer des fichiers, exécuter des commandes git, envoyer des messages et interagir avec des API en votre nom. Mais les frameworks d'agents actuels accordent à l'agent les mêmes privilèges que l'utilisateur, comme un accès complet au système de fichiers, aux identifiants et au réseau. Les chercheurs en sécurité appellent cela l'autorité ambiante, et cela signifie qu'une seule injection de prompt ou une dérive multi-tours peut amener un agent à supprimer des fichiers, exfiltrer des données ou pousser du code malveillant.

La réponse courante consiste soit à restreindre les agents à un bac à sable étroit (limitant leur utilité), soit à demander à l'utilisateur d'approuver chaque action (limitant leur autonomie). Ni l'une ni l'autre n'est satisfaisante.

L'approche

IronCurtain emprunte une voie différente : exprimez votre intention de sécurité en anglais simple, puis laissez le système déterminer l'application.

Vous écrivez une constitution, un court document décrivant ce que votre agent est et n'est pas autorisé à faire. IronCurtain compile cela en une politique de sécurité déterministe à l'aide d'un pipeline LLM, valide les règles compilées par rapport à des scénarios de test générés, puis applique la politique à l'exécution à chaque appel d'outil. Le résultat est un agent qui peut travailler de manière autonome dans les limites que vous définissez en langage naturel.

Les idées clés :

• L'agent n'est pas digne de confiance. IronCurtain suppose que le LLM peut être compromis par une injection de prompt ou une dérive. La sécurité ne dépend pas du fait que le modèle « se comporte bien ».
• De l'anglais en entrée, de l'application en sortie. Vous écrivez une intention (« aucune opération git destructive sans approbation ») ; le système la compile en règles déterministes qui sont appliquées sans autre intervention du LLM à l'exécution.
• Interposition sémantique. Au lieu de donner à l'agent un accès brut au système, toutes les interactions passent par des serveurs MCP (système de fichiers, git, etc.). Chaque appel d'outil passe par un moteur de politique qui peut autoriser, refuser ou escalader vers l'utilisateur pour approbation.
• Défense en profondeur. Le code de l'agent s'exécute dans un isolat V8 sans accès direct à l'hôte. La seule issue passe par des appels d'outils MCP sémantiquement significatifs, et chacun est vérifié par rapport à la politique.

Architecture

IronCurtain prend en charge deux modes de session avec des modèles de confiance différents :

• Agent intégré (mode Code) — L'agent LLM propre à IronCurtain écrit des extraits TypeScript qui s'exécutent dans un bac à sable V8. IronCurtain contrôle l'agent, le bac à sable et le moteur de politique. Chaque appel d'outil sort du bac à sable sous forme de requête MCP structurée, passe par le moteur de politique (autoriser / refuser / escalader), et n'atteint qu'ensuite le véritable serveur MCP.

• Mode agent Docker — Un agent externe (Claude Code, Goose, Codex) s'exécute dans un conteneur sans accès direct au réseau public. IronCurtain sert de médiateur pour les effets externes : les appels d'API LLM passent par un proxy MITM terminant le TLS (liste d'autorisation d'hôtes, échange de clé factice vers réelle), les appels d'outils MCP passent par le même moteur de politique, et les installations de paquets prises en charge passent par des proxys de paquets validants.

Le Docker imbriqué en option donne aux sessions de développement un démon privé et éphémère sans exposer le socket Docker de l'hôte. Les profils implémentés couvrent Apple Container et Docker Desktop sur macOS, ainsi que WSL2 avec Docker Desktop sur amd64. Ses modes offline, images et packages séparent l'utilisation locale d'images, les extractions d'images publiques médiées et les builds de paquets pris en charge. Le moteur Linux natif n'est pas admis pour l'imbrication ; consultez la référence de configuration pour les prérequis et les limitations.

Dans les deux modes, l'agent n'est pas digne de confiance. La sécurité ne dépend pas du fait que le modèle suive les instructions — elle est appliquée à la frontière.

Voir SANDBOXING.md pour l'architecture complète avec des diagrammes, une analyse de confiance couche par couche et des notes sur la plateforme macOS.

Démarrage rapide

Prérequis

• Node.js 24 ou 26 — les lignes majeures à numéro pair qu'IronCurtain teste. Les deux installent des binaires isolated-vm précompilés. Node 25 n'est pas pris en charge et n'est pas testé.
• Docker — non requis mais fortement recommandé pour le mode agent Docker, qui offre l'isolation la plus forte. Sur macOS 26+ (Apple silicon), Apple container fonctionne comme backend alternatif (VM par conteneur ; utilisé automatiquement lorsque ses services sont en cours d'exécution — voir containerRuntime dans ironcurtain config)
• Une clé API pour au moins un fournisseur LLM (Anthropic, Google ou OpenAI)

Installation

Comme outil CLI global (utilisateurs finaux) :

npm install -g @provos/ironcurtain

Depuis la source (développement) :

git clone https://github.com/provos/ironcurtain.git
cd ironcurtain
npm install

Configuration initiale unique

1. Définissez votre clé API :

export ANTHROPIC_API_KEY=sk-ant-...

Vous pouvez également placer les clés dans un fichier .env à la racine du projet (chargé automatiquement via dotenv), ou les ajouter à ~/.ironcurtain/config.json via ironcurtain config. Les variables d'environnement ont la priorité sur les valeurs du fichier de configuration. Pris en charge : ANTHROPIC_API_KEY, GOOGLE_GENERATIVE_AI_API_KEY, OPENAI_API_KEY.

2. Lancez l'assistant de premier démarrage (exécutez-le explicitement avant d'utiliser le chemin mux recommandé ; il s'exécute également automatiquement lors du premier ironcurtain start non-mux) :

ironcurtain setup