OpenClaw représente un changement majeur dans la façon dont les gens utilisent l’IA. Au lieu d’un chatbot hébergé dans le nuage, OpenClaw fonctionne localement, sur votre ordinateur portable ou votre poste de travail, avec la possibilité d’écrire du code, de gérer des fichiers, d’invoquer des outils et d’agir de manière autonome en votre nom.
C’est justement ce pouvoir qui fait monter les enchères.
OpenClaw fait l’objet d’un développement actif et rapide, avec l’ajout rapide de nouvelles fonctionnalités. Cette rapidité est une force, mais elle signifie également que des domaines fondamentaux tels que l’authentification, l’autorisation et l’auditabilité sont encore en évolution. Au fur et à mesure que les agents OpenClaw deviennent plus autonomes et plus largement utilisés, ces lacunes passent du stade de compromis à celui de risques réels pour la sécurité.
Cet article examine le modèle d’authentification actuel d’OpenClaw, ses améliorations récentes (y compris le mode proxy de confiance), ce qui manque encore et pourquoi l’intégration avec un ZTNA d’entreprise tel qu’Aryaka AI>Secure est la solution la plus propre et la plus évolutive.
Authentification native d’OpenClaw : Accès par jeton
Aujourd’hui, OpenClaw s’appuie principalement sur un modèle de jeton à secret partagé.
Lors de l’installation, OpenClaw génère un jeton de passerelle – unelongue chaîne secrète aléatoire – stocké localement (par exemple, dans le répertoire personnel de l’utilisateur dans les fichiers de configuration d’OpenClaw). Ce jeton sert de justificatif d’identité pour accéder à l’agent OpenClaw via son interface HTTP locale.
Lorsqu’un utilisateur ouvre l’interface de contrôle basée sur le navigateur d’OpenClaw, il est invité à fournir ce jeton. Une fois ce jeton fourni, le navigateur peut communiquer avec l’agent sans qu’il soit nécessaire de répéter les demandes d’authentification.
Les versions récentes ont ajouté une approbation manuelle dans le terminal lorsqu’une nouvelle session de navigateur tente de se connecter. Il s’agit d’une amélioration significative de la sécurité, mais qui ne modifie pas le modèle de confiance fondamental :
Toute personne qui possède le jeton a un accès complet à l’agent.
Il n’y a toujours pas d’identité de l’utilisateur, d’AMF, de séparation des rôles ou d’évaluation contextuelle.
Persistance du navigateur : La commodité au service du risque
Pour des raisons de convivialité, l’interface utilisateur du navigateur conserve généralement le jeton localement (par exemple, dans le stockage du navigateur). Cela permet d’éviter les demandes répétées, mais introduit des risques prévisibles :
- Le jeton devient une pièce d’identité à longue durée de vie.
- Des logiciels malveillants ou des extensions de navigateur malveillantes peuvent l’extraire.
- Il n’y a pas d’expiration de session ni de validation contextuelle
Du point de vue de la sécurité, le jeton se comporte davantage comme une clé d’API que comme un identifiant d’utilisateur.
Risques dans les scénarios à utilisateur unique et à utilisateurs multiples
Même dans les configurations à utilisateur unique, l’exfiltration de jetons par le biais d’un logiciel malveillant ou d’un navigateur compromis conduit à une prise de contrôle totale de l’agent.
Dans les environnements partagés ou en équipe, la situation s’aggrave :
- Pas d’identité d’utilisateur
- Pas de rôles ni d’autorisations
- Impossible d’attribuer des actions à des individus
- Pas de révocation à grain fin
- Pas de piste d’audit de niveau entreprise
Cela est fondamentalement incompatible avec une utilisation en entreprise, réglementée ou de production.
Mode proxy de confiance : La bonne direction architecturale
Pour remédier à ces limitations, OpenClaw a introduit le mode proxy de confiance, ce qui constitue une étape architecturale importante et positive.
En mode proxy de confiance :
- OpenClaw n’accepte que les demandes provenant d’un mandataire désigné en amont.
- Le jeton de passerelle reste confiné à ce proxy
- Les utilisateurs finaux n’interagissent jamais directement avec l’agent
Cette conception reconnaît explicitement un principe fondamental : l ‘identité et le contrôle d’accès doivent se situer en dehors de l’agent.
Intégration de ZTNA : Injection d’identité en toute sécurité
C’est ici que ZTNA s’intègre proprement et intentionnellement à la conception du proxy de confiance d’OpenClaw.
Une plateforme ZTNA telle qu’Aryaka AI>Secure se place devant OpenClaw et effectue l’authentification, l’autorisation et la comptabilité (AAA) avant que le trafic n’atteigne l’agent.
Après avoir authentifié les utilisateurs via les IdP de l’entreprise (Okta, Azure AD, Google Workspace), appliqué le MFA et validé la posture de l’appareil, ZTNA transmet les demandes à OpenClaw en injectant un contexte d’identité vérifié, généralement à l’aide d’en-têtes tels que :
- X-Forwarded-User
- X-Forwarded-Groups
Le mode proxy de confiance d’OpenClaw est conçu pour ne faire confiance qu’à ces en-têtes provenant du proxy configuré.
Exigence critique de sécurité : Pas de transfert aveugle d’en-tête
Un point doit être explicité :
ZTNA ne doit jamais transmettre aveuglément les en-têtes d’identité de la connexion du client à l’agent.
Si des en-têtes tels que X-Forwarded-User sont copiés directement à partir de la requête du client, un attaquant pourrait trivialement usurper les en-têtes d’identité et contourner les contrôles de sécurité au niveau de la couche agent d’OpenClaw.
Une intégration ZTNA correcte suit des règles strictes :
- Tous les en-têtes d’identité fournis par le client sont supprimés .
- Les en-têtes d’identité sont reconstruits par ZTNA après authentification par JWT.
- Les en-têtes font l’objet d’une confiance cryptographique ou logique parce que :
- Ils proviennent uniquement du proxy ZTNA
- OpenClaw ne les accepte qu’en mode proxy de confiance.
- Aucune donnée contrôlée par le client n’est réutilisée comme contexte d’identité.
C’est cette séparation qui fait que le modèle OpenClaw + ZTNA est sécurisé par conception plutôt que par convention.
Autorisation et auditabilité sans modification de l’agent
Même si OpenClaw ne dispose pas encore d’utilisateurs ou de rôles natifs :
- ZTNA contrôle qui peut accéder à l’agent
- Les politiques peuvent être appliquées par utilisateur, groupe, appareil et contexte réseau.
- Chaque demande est enregistrée avec une identité humaine vérifiée.
- Les entreprises obtiennent une piste d’audit propre pour la conformité et la criminalistique
OpenClaw reste concentré sur le comportement des agents.
Conclusion : ZTNA est toujours d’actualité, même si OpenClaw évolue
OpenClaw évolue rapidement et dans la bonne direction. Le mode proxy de confiance est un signal architectural fort qui montre que le projet comprend l’importance de la confiance externalisée.
Même si OpenClaw implémente ultérieurement l’authentification native des utilisateurs ou des rôles, ZTNA reste précieux – et souvent essentiel – pour les entreprises.
Pourquoi ?
Les entreprises ont besoin d’un contrôle de sécurité uniforme pour toutes les applications :
- SaaS
- Applications web internes
- API
- Outils du développeur
- Et maintenant, les agents de l’IA
ZTNA fournit : Une politique centralisée
- Une posture cohérente en matière d’AMF et d’appareils
- Journaux d’audit unifiés
- Une seule couche d’application pour des systèmes hétérogènes
OpenClaw n’a pas besoin de devenir une plateforme IAM complète pour être sûre.
Lorsque le mode proxy de confiance d’OpenClaw est associé à une couche ZTNA correctement mise en œuvre, les entreprises bénéficient du meilleur des deux mondes :
- Des agents d’intelligence artificielle puissants qui évoluent rapidement
- Sécurité « Zero Trust » de niveau entreprise