IronClaw

Qu’est-ce qu’IronClaw ?

IronClaw est un runtime sécurisé open source pour exécuter des agents IA dans des environnements d’exécution de confiance chiffrés (TEE) sur NEAR AI Cloud. Son objectif principal est de vous permettre d’utiliser des workflows d’agents qui « agissent réellement » tout en protégeant vos identifiants contre l’agent et contre les vols de credentials basés sur l’injection de prompts.

Plutôt que de compter sur des instructions à l’IA pour ne pas divulguer de secrets, IronClaw stocke les identifiants dans un coffre chiffré et les injecte dans les requêtes uniquement à une frontière réseau approuvée. Il exécute également les outils d’agents dans des conteneurs Wasm sandboxés avec des permissions de type capability et des endpoints autorisés.

Fonctionnalités clés

• Coffre chiffré pour les identifiants : Les clés API, tokens et mots de passe sont chiffrés au repos et restent invisibles à l’IA ; IronClaw injecte les identifiants uniquement là où vous l’avez autorisé.
• Environnement d’exécution de confiance chiffré (TEE) : Votre instance IronClaw s’exécute dans un TEE sur NEAR AI Cloud, avec chiffrement en mémoire du démarrage à l’arrêt.
• Autorisation réseau (contrôle au niveau des endpoints) : Les outils ne peuvent atteindre que les endpoints pré-approuvés, limitant les « phone-home silencieux » et réduisant les mouvements de données non intentionnels.
• Outils sandboxés avec conteneurs Wasm : Chaque outil s’exécute dans son propre environnement Wasm avec des permissions basées sur les capabilities, des endpoints autorisés et des limites strictes de ressources.
• Détection de fuites pour le trafic sortant : Les requêtes sortantes sont scannées en temps réel ; les données suspectes ressemblant à des secrets en sortie sont bloquées automatiquement.
• Implémentation orientée sécurité mémoire (Rust + vérification) : IronClaw est construit en Rust et inclut des vérifications comme la validation Wasm et le blocage de contenus non sécurisés dans le flux runtime.

Comment utiliser IronClaw

1. Déployez IronClaw sur NEAR AI Cloud via le flux de déploiement cloud en un clic.
2. Configurez vos endpoints autorisés et identifiants pour l’agent via la configuration d’IronClaw — placez les clés API/tokens/mots de passe dans le coffre chiffré et spécifiez les endpoints autorisés.
3. Exécutez votre agent via l’instance IronClaw pour que les outils s’exécutent dans des conteneurs Wasm sandboxés et que les identifiants soient injectés uniquement pour les requêtes approuvées.

Si vous préférez un fonctionnement local, le site indique qu’IronClaw peut être exécuté localement, mais le contenu fourni ne comprend pas d’étapes spécifiques pour une installation locale.

Cas d’usage

• Assistant IA personnel appelant des services externes : Utilisez un style OpenClaw pour navigation/recherche/codage/automatisation tout en gardant les clés API et tokens hors de la vue directe de l’agent.
• Workflows d’agents utilisant plusieurs API tierces : Définissez une liste d’endpoints autorisés pour que chaque outil n’accède qu’aux services spécifiques prévus.
• Projets reposant sur des « skills » ou outils tiers : Réduisez le risque qu’un outil compromis ou malveillant exfiltre des identifiants en isolant les outils et en restreignant l’accès sortant.
• Équipes exécutant des agents sur des environnements sensibles : Détectez les fuites suspectes de secrets dans le trafic sortant et empêchez les données de sortir par des canaux non approuvés.
• Expérimentation avec des capacités d’agents sans élargir l’exposition : Fournissez un « comportement agentique complet » pour les actions, en concentrant les contrôles sur l’injection d’identifiants et les endpoints accessibles.

FAQ

IronClaw remplace-t-il OpenClaw ?
IronClaw est présenté comme une alternative sécurisée et open source à OpenClaw pour exécuter un assistant IA personnel de style OpenClaw avec des mécanismes supplémentaires de protection des identifiants.

Comment IronClaw empêche-t-il le vol d’identifiants par injection de prompt ?
L’agent ne reçoit pas les identifiants bruts. Les identifiants sont stockés dans un coffre chiffré et injectés à la frontière hôte uniquement pour les endpoints de la liste autorisée, limitant ainsi l’accès des tentatives basées sur des prompts.

Quelles frontières de sécurité IronClaw utilise-t-il ?
Le site décrit des TEE chiffrés pour l’instance, des outils sandboxés dans des conteneurs Wasm, et une autorisation d’endpoints pour contrôler les destinations du trafic des outils.

IronClaw scanne-t-il le trafic sortant ?
Oui. Le site indique que le trafic sortant est scanné en temps réel et que tout ce qui ressemble à un secret en sortie est bloqué automatiquement.

Où IronClaw peut-il être déployé ?
La page indique qu’il peut s’exécuter sur NEAR AI Cloud (avec déploiement en un clic) et aussi localement.

Alternatives

• OpenClaw sans isolation supplémentaire : C’est l’alternative la plus proche mentionnée dans la source. Elle peut offrir des capacités d’agent similaires, mais la page met en avant des risques plus élevés d’exposition des identifiants par injection de prompt et compétences malveillantes.
• Autres approches de runtime sécurisé / basées sur TEE pour agents : Au lieu d’injection d’identifiants à la frontière réseau, vous pouvez chercher des runtimes qui exécutent le code d’agent dans des enclaves sécurisées ou une isolation matérielle.
• Configurations d’agents à restrictions réseau (allowlisting proxy/firewall) : Plutôt qu’un modèle coffre-fort chiffré + TEE, certaines configurations se concentrent sur la restriction des destinations sortantes via des contrôles réseau ; cela peut réduire les chemins d’exfiltration mais ne résout pas le problème « l’agent voit les identifiants » souligné par la page.
• Gestion de secrets au niveau applicatif (rédactions/caches de secrets sans TEE) : Ces alternatives visent à protéger les secrets via des caches et politiques d’accès, mais peuvent différer du modèle d’application déclaré par IronClaw autour de l’exécution en enclave, outils sandboxés et détection de fuites sortantes.