Les agents d’IA entrent dans une phase différente.
Ils ne se limitent plus à produire des réponses. Ils peuvent parcourir des sites web, gérer des fichiers, écrire du code, traiter de l’information et exécuter des workflows multi-étapes.
Cette capacité supplémentaire crée un nouveau problème d’ingénierie.
Lorsque des logiciels peuvent agir en votre nom, comment contrôlez-vous ce qu’ils ont le droit de faire ? Comment vous assurez-vous qu’une tâche interrompue ne disparaît pas ? Et comment protégez-vous l’infrastructure qui gère les données et le calcul en arrière-plan ?
C’est ce qui rend intéressant d’examiner IronClaw 1.0 de @NEAR Protocol .
La frontière importante se situe entre le fait de décider et le fait d’exécuter
IronClaw 1.0 est un banc d’agent remanié depuis #NEARAI . Il repose sur une séparation architecturale simple : le composant qui décide quoi faire est distinct de celui qui exécute l’action.
Entre les deux se trouve une couche de coordination appelée la garde.
Chaque action passe par ce chemin. Les actions sensibles peuvent nécessiter une approbation explicite avant exécution. Cela crée un point de contrôle entre le raisonnement d’un agent et sa capacité à agir sur un système externe.
La garde n’est pas enveloppée autour de l’agent après le lancement. Elle fait partie du chemin d’exécution.
C’est là que, par conception, la sécurité devient concrète. Un ensemble de règles, une fois défini, est censé tenir lorsqu’on ajoute plus tard un nouvel outil.
La capacité ne suffit pas si le travail ne peut pas survivre
Un agent qui accomplit un travail réel a aussi besoin de persistance.
IronClaw enregistre continuellement des instantanés de son état. Si une tâche est interrompue, mise en pause en attendant une autorisation, ou si la session doit redémarrer, le travail peut reprendre à partir de là où il s’était arrêté plutôt que d’être perdu.
Une interruption devient une pause plutôt qu’une raison de recommencer toute la tâche.
Le même principe s’étend sur les canaux. La CLI, le Web, Slack et Telegram peuvent fonctionner comme un seul assistant, avec une mémoire partagée et les mêmes règles de sécurité.
Pour les organisations, #IronClaw prend en charge différents modèles d’isolation. Les déploiements multi-tenant permettent aux équipes de partager des outils et des compétences tout en gardant les espaces de travail individuels privés des administrateurs par défaut, avec un accès traçable lorsque c’est requis. Les déploiements single-tenant peuvent fournir une isolation complète.
Ces détails sont faciles à négliger quand on parle d’agents d’IA. Ils deviennent importants dès lors que l’on s’attend à ce que le logiciel fonctionne autour de données organisationnelles réelles.
Les benchmarks testent si le contrôle s’accompagne d’un coût en performance
Une question raisonnable suit : ajouter un autre point de contrôle rend-il un agent moins capable ?
NEAR AI a testé IronClaw sur trois benchmarks en utilisant le même modèle de base deepseek-v4-flash. Ce choix isole le banc de test.
PinchBench : 93,5 % sur 147 tâches réelles impliquant la planification, le tri d’e-mails, la programmation, la recherche et la gestion de fichiers.
ClawBench : 88,6 % sur plus de 140 sites web de production réels, en testant des tâches lourdes en écriture et multi-étapes.
OfficeQA : 76,4 % sur le raisonnement documentaire d’entreprise sur près de 89 000 pages de bulletins du Trésor américain contenant plus de 26 millions de valeurs numériques.
Ces tests révèlent différents types de travail d’agent : des processus de bureau, des interactions web en direct et des documents denses.
Les chiffres ne prouvent pas qu’IronClaw gagnera tous les workflows. Ils montrent quelque chose de plus étroit et de plus utile : ajouter une couche de contrôle n’a pas empêché d’obtenir des résultats de tête sur des formes d’exécution d’agents très différentes.
Où NEAR AI et le staking s’insèrent
IronClaw ne flotte pas toute seule. Elle s’inscrit dans l’infrastructure plus large de NEAR AI, construite autour d’une IA privée et vérifiable.
NEAR AI Cloud utilise l’informatique confidentielle, y compris des Trusted Execution Environments, pour les charges de travail éligibles. La confidentialité est censée reposer sur l’isolation technique et la vérification, pas seulement sur la confiance envers quiconque opère les machines.
Je trouve, honnêtement, que c’est la partie la plus intéressante de l’architecture. Il ne s’agit plus seulement de contrôler ce que l’agent fait ; il s’agit aussi de la confidentialité et de la vérifiabilité de l’environnement dans lequel l’agent fonctionne même.
Le staking fait partie de cette histoire qui est souvent réduite à un simple rendement. Sur NEAR, il y a deux rôles liés mais distincts.
Au niveau du protocole, le staking prend en charge la Proof of Stake. Les utilisateurs délèguent NEAR à des validateurs qui participent à la validation et au consensus. La mise économique fait partie de la façon dont le réseau reste sécurisé.
NEAR AI utilise aussi le staking pour des services tels que l’inférence confidentielle et l’hébergement d’agents en continu. Dans ce modèle, le NEAR misé est relié à des crédits d’utilisation pour l’infrastructure IA.
Le staking au niveau du protocole aide à sécuriser le réseau. Le staking de NEAR AI fournit l’accès à l’infrastructure IA et à la puissance de calcul.
Vu ensemble, les couches s’empilent proprement. IronClaw contrôle la façon dont un agent agit, NEAR AI lui offre un endroit privé pour s’exécuter, et en dessous des deux, le staking du protocole NEAR est ce qui maintient tout le réseau honnête.
Le staking sur NEAR ne sert pas seulement à obtenir des rendements. Ensemble, ces couches soutiennent l’infrastructure dont des agents comme OpenClaw ont besoin, y compris les déploiements d’OpenClaw sur le cloud NEAR AI.
Pour moi, c’est l’histoire réelle ici : pas un agent plus « intelligent », mais un agent qui, enfin, a des limites qu’il ne peut pas franchir discrètement.
Feriez-vous confiance à un agent d’IA pour un travail réel s’il y avait une garde entre ses décisions et ses actions ?