Shadow AI : les collaborateurs ont déjà installé OpenClaw, que fait la DSI ?

Le débat « faut-il autoriser OpenClaw ? » est dépassé. Les mesures des fournisseurs de sécurité montrent que l'agent tourne déjà dans une part significative des entreprises, souvent avec des accès privilégiés que personne n'a approuvés. Ce Shadow AI échappe à l'EDR classique.

Combien de collaborateurs utilisent déjà OpenClaw sans autorisation ?

Les mesures publiées par plusieurs éditeurs de sécurité convergent :

• Token Security (via Forbes, R. Schmelzer, 30 janv. 2026) : « within a week of analysis, 22% of its customers had employees actively using Clawdbot variants », soit 22 % des clients concernés en une semaine. Token a aussi relevé qu'1 client sur 5 avait déployé OpenClaw sans approbation IT.
• Noma Security (CISO Diana Kelley) : « 53% of our enterprise customers gave clawdbot privileged access over the weekend (and no one asked permission) », soit 53 % avec des accès privilégiés accordés sans permission.

C'est un cas d'école de Shadow IT amplifié par l'IA : l'équipe sécurité n'a rien déployé, mais hérite d'agents pleinement crédentialés capables d'agir sur les systèmes d'entreprise.

Pourquoi l'EDR classique ne détecte-t-il pas OpenClaw ?

Repello AI le résume : l'EDR standard « sees a signed Python process making HTTPS calls », il voit un processus signé qui fait des appels HTTPS légitimes. Quatre classes de menaces propres aux agents lui échappent : (1) la supply chain des skills (ClawHub), (2) la memory injection via le contexte récupéré, (3) les surfaces de credentials multi-provider, (4) la trust boundary des serveurs MCP connectés. Surveillez la couche prompt / tool call plutôt que la couche processus.

Comment détecter les installations sauvages ?

• Scan réseau des ports d'écoute typiques (18789 pour la gateway OpenClaw ; 8000/8080 selon la configuration) sur les hôtes internes, avec recherche des titres de Control UI « Clawdbot / Moltbot / OpenClaw Control ».
• Recherche filesystem des répertoires ~/.openclaw, ~/.clawdbot, ~/.moltbot, ~/.hermes.
• Inventaire des connexions OAuth / API keys vers des services d'entreprise : traitez tout agent comme un « courtier d'accès always-on ».
• Détection comportementale plutôt que signatures statiques.

La DSI doit-elle bannir ou encadrer ?

Meta, Google, Microsoft et Amazon ont banni OpenClaw sur leur matériel corporate. Repello AI documente la limite : « bans don't hold », les ingénieurs installent l'agent sur des appareils personnels et le connectent aux systèmes d'entreprise via MCP. La posture qui tient dans le temps passe par un cycle discovery → classification → runtime control :

1. Découvrir l'existant (voir ci-dessus).
2. Classifier par sensibilité (heat map rouge/jaune/vert selon les données accessibles et les skills vétées).
3. Contrôler au runtime : sandbox du runtime, isolation de la mémoire, validation des manifestes de skills, monitoring couche prompt, log de chaque tool call.

Surtout, proposez une alternative gouvernée pour canaliser le besoin réel : OpenClaw durci via NemoClaw, la plateforme Archestra (RBAC/SSO), ou Hermès Agent encadré (voir déploiements durcis et comparatif).

FAQ

Interdire OpenClaw par GPO/MDM suffit-il ? Non : les collaborateurs contournent via appareils perso et connexions MCP. L'interdiction doit s'accompagner d'une alternative officielle et de contrôles runtime.

Comment savoir ce à quoi un agent découvert a accès ? Auditez les grants OAuth, les clés API et les scopes. Si vous ne pouvez pas énumérer ses accès, votre modèle de déploiement est à revoir (recommandation Microsoft).

Faut-il tout reconstruire après découverte d'une instance exposée ? Traitez-la comme une compromission potentielle : révoquez les credentials, analysez les accès downstream, reconstruisez si l'instance touchait des systèmes sensibles.

---

Sources

• forbes.com (R. Schmelzer)
• Noma Security (D. Kelley)
• onyx.app/insights
• microsoft.com/en-us/security/blog
• repello.ai/blog