Security musings

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
~7 minutes

Cet article fait partie de la série OWASP Agentic Skills Top 10. Retrouvez l’introduction et le plan complet sur la page de la série.

Un chercheur de Meta AI (Summer Yue) a demandé à un agent OpenClaw de consulter sa boîte mail sans effectuer d’actions. L’agent a supprimé massivement des emails avant d’être manuellement arrêté. Même un agent bien intentionné finit par exécuter avec plus d’autorité que prévu : les skills héritent par défaut de tous les privilèges de l’agent.

AST03 couvre ce risque : des skills qui disposent de permissions bien au-delà de leur fonction déclarée, créant un blast radius disproportionné.


Description du risque

Les skills obtiennent des permissions plus larges que leur fonction ne le nécessite, soit parce qu’aucun système de manifeste de permissions n’existe, soit parce que les utilisateurs acceptent toutes les permissions sans les examiner.

Un skill légitime de formattage de texte qui a aussi accès à ~/.ssh/ et à vos variables d’environnement — voilà AST03.

La différence avec les packages traditionnels

Le least-privilege applicatif existe depuis longtemps dans les runtimes classiques. Les skills y ajoutent une couche d’intent en langage naturel par-dessus les permissions système. Un skill autorisé à exécuter des requêtes SELECT peut être poussé par prompt injection à exécuter DELETE — la vérification se fait au niveau de l’appel d’outil, pas de l’intention.


Preuves terrain

Incident Date Impact
280+ leaky skills Fév 2026 Snyk révèle 280+ skills sur ClawHub qui exposent des clés API et des PII au-delà de leur fonction déclarée
OpenClaw par défaut 2026 Documentation officielle : “tools run on the host for the main session, so the agent has full access.” Shell, fichiers, réseau, cron jobs, le tout sans scope par skill
Incident Meta AI 2026 Agent supprime massivement des emails alors qu’il n’était censé que les consulter. Aucun mécanisme de gouvernance n’existait pour prévenir ou détecter l’action

Scénarios d’attaque

1. Exfiltration par un assistant météo

Un skill “weather assistant” lit ~/.clawdbot/.env (toutes les clés API) alors qu’il n’a besoin que d’un token pour l’API météo. L’accès excessif permet l’exfiltration de credentials sans rapport avec la fonction.

2. Wipe de base de données

Un skill manage_database provisionné avec des credentials admin est trompé via prompt injection pour wiper les données de production. Le skill avait des droits DROP TABLE alors qu’il n’avait besoin que de SELECT.

3. Backdoor via fichiers d’identité

Un skill demande l’accès en écriture à SOUL.md et MEMORY.md. Ces fichiers d’identité de l’agent lui permettent d’installer des backdoors comportementales persistantes.


Mitigations

  1. Exiger que les skills déclarent un manifeste de permissions (fichiers, réseau, shell, outils). Refuser les skills sans manifeste.
  2. Appliquer des credentials scopés par skill, pas les clés API globales de l’agent.
  3. Signaler les skills qui demandent l’accès en écriture aux fichiers d’identité (SOUL.md, MEMORY.md, AGENTS.md) pour une revue renforcée.
  4. Implémenter une application de permissions au runtime, pas seulement déclarative.
  5. Adopter des allowlists réseau scopées par domaine, pas un booléen network: true/false.
  6. Valider les déclarations du manifeste contre le comportement observé en test sandboxé.

Mapping OWASP

  • LLM09 (Excessive Agency)
  • ASVS V4 (Access Control)
  • CWE-250 (Execution with Unnecessary Privileges)

Risques liés


Quelques références pour aller plus loin


À retenir 📌

Par défaut, un skill hérite de tous les privilèges de l'agent. Aucun système de permission par skill n'existe dans la majorité des plateformes.

Un skill légitime sur-privilégié devient une arme via prompt injection : les permissions sont vérifiées au niveau outil, pas au niveau intention.

Le manifeste de permissions avec deny-by-default est la mitigation prioritaire.

AST03