Sécurité · outil

Checklist de sécurité des agents

Effectuez ces vérifications avant qu’un agent n’accède à des données réelles ou à des identifiants. Chaque point renvoie à la mesure de protection correspondante. Vous pouvez aussi exporter votre progression au format Markdown pour une revue ou une pull request.

0 sur 22 terminés

Les cases cochées sont enregistrées uniquement dans ce navigateur.

Entrées non fiables

Identifiez les contenus non fiables dès leur entrée dans l’agentMarquez les pages web, e-mails, issues, tickets et résultats d’outils que des tiers peuvent modifier. Tout contenu de cette liste peut contenir des instructions.Brisez la triade fatale →Séparez les agents pour qu’aucun ne réunisse les trois éléments du triptyqueSi un agent lit du contenu non fiable, retirez-lui soit l’accès aux données privées, soit son canal sortant. Si un agent doit réunir les trois éléments, utilisez une architecture planification puis exécution ou une conception à deux LLM.Restreignez l’agent après une entrée non fiable →Vérifiez et épinglez les descriptions de chaque outil connectéLes descriptions des outils sont directement intégrées au contexte du modèle. Lisez-les avant de connecter un serveur et calculez leur hash pour détecter toute modification ultérieure.Vérifier les skills, plugins et serveurs MCP →Échappez les sorties du modèle avant de les afficher ou de les exécuterBloquez le chargement automatique des images et liens externes dans le contenu affiché et définissez une CSP stricte. Ne transmettez jamais une sortie brute à un shell, une requête SQL ou eval.Traiter les sorties du modèle comme non fiables →

Outils et identifiants

Configurez chaque connexion à un outil en lecture seule par défautN’accordez les droits d’écriture, de suppression ou d’envoi qu’aux outils qui en ont besoin, et uniquement pour la tâche en cours.Utiliser des identifiants à privilèges minimaux →Limitez chaque token à un seul projet et au minimum de permissionsN’utilisez pas de clés admin ou service_role pour les agents. Des tokens à durée de vie courte et limités à un projet réduisent au minimum l’impact d’une fuite.Utiliser des identifiants à privilèges minimaux →Exigez une validation humaine pour les écritures, suppressions et envoisAffichez tous les arguments de l’outil dans la demande de validation et refusez l’action par défaut si personne ne répond. Dans OpenClaw, définissez tools.exec.ask sur always.Exiger une approbation pour les actions importantes →Épinglez les versions exactes des skills, plugins et serveurs MCPVérifiez le diff avant chaque mise à jour et consultez les résultats des analyses de VirusTotal ou des audits de ClawHub. Dans OpenClaw, définissez security.installPolicy.Vérifier les skills, plugins et serveurs MCP →Autorisez le trafic sortant uniquement vers les hôtes nécessaires à chaque outilBloquez par défaut le trafic sortant des agents et des serveurs MCP. Excluez de toute liste d’autorisation automatique les hôtes mutualisés sur lesquels n’importe qui peut publier du contenu.Limiter l’accès réseau sortant →

Exécution et réseau

Exécutez le code et les outils shell dans un sandboxUtilisez un conteneur ou une VM sans identifiants et montez uniquement l’espace de travail. Dans OpenClaw, activez le sandboxing, définissez tools.exec.security sur deny ou allowlist et laissez le mode elevated désactivé.Isoler l’exécution du code et des outils →Liez gateways et dashboards à loopback uniquementAccédez-y à distance via un tunnel SSH ou Tailscale Serve et utilisez un token d’au moins 24 caractères. Exécutez openclaw security audit --deep pour vérifier la configuration.Ne pas exposer les plans de contrôle à Internet →Limitez les personnes autorisées à contacter l’agentUtilisez l’association pour les DM ou une allowlist, et exigez une mention dans les discussions de groupe. Toute personne pouvant contacter l’agent peut essayer de lui donner des instructions.Contrôler qui peut envoyer des messages à l’agent →Attribuez une session distincte à chaque utilisateur ou expéditeurNe partagez jamais le contexte d’une conversation entre différentes personnes. Dans OpenClaw, définissez session.dmScope sur per-channel-peer.Isoler les sessions et les tenants MCP →

Serveurs et clients MCP

Rejetez les tokens MCP qui n’ont pas été émis pour votre serveurVérifiez l’audience de chaque access token et demandez aux clients d’envoyer des indicateurs de ressource RFC 8707 afin que chaque token soit lié à un seul serveur.Valider l’audience des tokens MCP →Ne transmettez jamais les tokens des clients aux API en amontObtenez des tokens distincts pour les appels en amont. Si votre serveur fait office de proxy vers des services tiers, recueillez le consentement de chaque client pour éviter le problème du confused deputy.Valider l’audience des tokens MCP →Utilisez des versions corrigées des SDK et outils MCPAu minimum : TypeScript SDK 1.26.0, Python SDK 1.27.2, mcp-remote 0.1.16 et MCP Inspector 0.14.1. Créez un serveur et un transport par session.Isoler les sessions et les tenants MCP →

CI et revue de code

Ne fournissez aucun secret aux agents CI que des tiers peuvent déclencherLes tâches d’agent déclenchées par des pull requests, des issues ou des commentaires provenant de tiers doivent recevoir un token en lecture seule et aucun secret du dépôt.Ne pas exposer de secrets aux exécutions CI non fiables →Considérez le texte des pull requests et des issues comme hostileLes titres, descriptions, commentaires et diffs de tiers peuvent contenir des instructions. Exigez l’approbation d’un mainteneur avant d’exécuter sur ces contenus toute tâche disposant de secrets.Ne pas exposer de secrets aux exécutions CI non fiables →

Exploitation

Consignez chaque appel d’outil, avec ses arguments et son résultatStockez le journal dans un emplacement que l’agent ne peut pas modifier. Vous en aurez besoin pour reconstituer un incident et repérer les appels inhabituels.Prévoyez un moyen rapide d’arrêter les agents et de révoquer leurs tokensSachez comment arrêter chaque agent en cours d’exécution et révoquer ses identifiants en quelques minutes. Entraînez-vous avant d’en avoir besoin.Testez vos agents contre les injections de prompt avant leur mise en productionInsérez des instructions dans les contenus lus par votre agent, tels que des issues, des e-mails et des pages web, puis vérifiez qu’elles ne déclenchent aucune action importante. Recommencez après chaque modification des outils ou des prompts.Vérifiez les signatures des agents avant de faire confiance à leur traficVérifiez les signatures Web Bot Auth à l’aide du répertoire de clés de l’opérateur pour identifier un agent. Définissez séparément les actions qu’il est autorisé à effectuer : une signature identifie l’opérateur, pas l’utilisateur.Vérifier les signatures des agents, puis les autoriser →

Exporter en Markdown

SECURITY-CHECKLIST.md

## Entrées non fiables
- [ ] Identifiez les contenus non fiables dès leur entrée dans l’agent
- [ ] Séparez les agents pour qu’aucun ne réunisse les trois éléments du triptyque
- [ ] Vérifiez et épinglez les descriptions de chaque outil connecté
- [ ] Échappez les sorties du modèle avant de les afficher ou de les exécuter

## Outils et identifiants
- [ ] Configurez chaque connexion à un outil en lecture seule par défaut
- [ ] Limitez chaque token à un seul projet et au minimum de permissions
- [ ] Exigez une validation humaine pour les écritures, suppressions et envois
- [ ] Épinglez les versions exactes des skills, plugins et serveurs MCP
- [ ] Autorisez le trafic sortant uniquement vers les hôtes nécessaires à chaque outil

## Exécution et réseau
- [ ] Exécutez le code et les outils shell dans un sandbox
- [ ] Liez gateways et dashboards à loopback uniquement
- [ ] Limitez les personnes autorisées à contacter l’agent
- [ ] Attribuez une session distincte à chaque utilisateur ou expéditeur

## Serveurs et clients MCP
- [ ] Rejetez les tokens MCP qui n’ont pas été émis pour votre serveur
- [ ] Ne transmettez jamais les tokens des clients aux API en amont
- [ ] Utilisez des versions corrigées des SDK et outils MCP

## CI et revue de code
- [ ] Ne fournissez aucun secret aux agents CI que des tiers peuvent déclencher
- [ ] Considérez le texte des pull requests et des issues comme hostile

## Exploitation
- [ ] Consignez chaque appel d’outil, avec ses arguments et son résultat
- [ ] Prévoyez un moyen rapide d’arrêter les agents et de révoquer leurs tokens
- [ ] Testez vos agents contre les injections de prompt avant leur mise en production
- [ ] Vérifiez les signatures des agents avant de faire confiance à leur trafic