
Un runtime sécurisé* pour les agents IA autonomes. Politique à partir de constitutions en anglais simple. (*https://ironcurtain.dev)
Un runtime sécurisé* pour les agents IA autonomes, dont la politique de sécurité est dérivée d'une constitution lisible par l'homme.
*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 explorant comment rendre les agents IA suffisamment sûrs pour être véritablement utiles. Les API, les formats de configuration et l'architecture peuvent changer. Les contributions et les retours sont les bienvenus.
L'agent est invité à cloner un dépôt et à pousser des modifications. git_clone et git_push sont tous deux escaladés par le moteur de politique, mais l'approbateur automatique les approuve automatiquement — l'entrée de confiance de l'utilisateur en mode commande (Ctrl-A) a fourni une intention claire, donc aucune approbation manuelle /approve n'était 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 donnent à l'agent les mêmes privilèges que l'utilisateur, comme l'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 multitour peut amener un agent à supprimer des fichiers, exfiltrer des données ou pousser du code malveillant.
La réponse courante est soit de restreindre les agents à un sandbox étroit (limitant leur utilité), soit de demander à l'utilisateur d'approuver chaque action (limitant leur autonomie). Aucune des deux n'est satisfaisante.
IronCurtain emprunte une voie différente : exprimez votre intention de sécurité en anglais simple, puis laissez le système décider de la mise en œuvre.
Vous écrivez une constitution qui est un court document décrivant ce que votre agent a le droit de faire ou non. 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 sur chaque appel d'outil. Le résultat est un agent qui peut travailler de manière autonome à l'intérieur des 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) — Le propre agent LLM d'IronCurtain écrit des extraits TypeScript qui s'exécutent dans un sandbox V8. IronCurtain contrôle l'agent, le sandbox et le moteur de politique. Chaque appel d'outil sort du sandbox en tant que requête MCP structurée, passe par le moteur de politique (autoriser / refuser / escalader) et n'atteint le vrai serveur MCP qu'ensuite.
Mode Agent Docker — Un agent externe (Claude Code, Goose, etc.) s'exécute à l'intérieur d'un conteneur Docker sans accès réseau. IronCurtain médiatise les effets externes : les appels API LLM passent par un proxy MITM mettant fin au TLS (liste blanche d'hôtes, échange de clés fictives/réelles), les appels d'outils MCP passent par le même moteur de politique, et les installations de paquets (npm/PyPI) passent par un proxy de registre de validation.
Dans les deux modes, l'agent n'est pas digne de confiance. La sécurité ne dépend pas du respect des instructions par le modèle — elle est appliquée à la frontière.
Voir SANDBOXING.md pour l'architecture complète avec diagrammes, analyse de confiance couche par couche, et notes sur la plateforme macOS.
isolated-vm ; 24 et 26 installent des binaires préconstruits, Node 22 compile à partir de la source lors de l'installation et nécessite une chaîne d'outils C/C++). Les lignes impaires (23, 25) fonctionnent mais ne sont pas testées — ironcurtain doctor émet un avertissement.container fonctionne comme backend alternatif (VM par conteneur ; utilisé automatiquement lorsque ses services sont en cours d'exécution — voir containerRuntime dans ironcurtain config)En tant qu'outil CLI global (utilisateurs finaux) :```bash npm install -g @provos/ironcurtain
**À partir de la source (développement):**```bash
git clone https://github.com/provos/ironcurtain.git
cd ironcurtain
npm install
1. Définissez votre clé API :```bash 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 dans `~/.ironcurtain/config.json` via `ironcurtain config`. Les variables d'environnement priment sur les valeurs du fichier de configuration. Pris en charge : `ANTHROPIC_API_KEY`, `GOOGLE_GENERATIVE_AI_API_KEY`, `OPENAI_API_KEY`.
**2. Exécutez l'assistant de premier démarrage** (lancez-le explicitement avant d'utiliser le chemin mux recommandé ; il s'exécute également automatiquement lors du premier `ironcurtain start` non mux) :```bash
ironcurtain setup
Vous guide à travers la configuration du jeton GitHub, du fournisseur de recherche web, de la sélection du modèle et d'autres paramètres. Crée ~/.ironcurtain/config.json avec vos choix.
IronCurtain est livré avec une politique par défaut orientée vers l'expérience développeur — les opérations en lecture seule sont autorisées, les mutations (écritures, pushs, création de PR) nécessitent une approbation humaine. Vous pouvez commencer à l'utiliser immédiatement après la configuration.