provos/ironcurtainUn runtime sécurisé* pour les agents IA autonomes. Politique à partir de constitutions en anglais simple. (*https://ironcurtain.dev)
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.
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.
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.
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 :
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.
isolated-vm précompilés. Node 25 n'est pas pris en charge et n'est pas testé.container fonctionne comme backend alternatif (VM par conteneur ; utilisé automatiquement lorsque ses services sont en cours d'exécution — voir containerRuntime dans ironcurtain config)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
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