Configuration du sandbox et des outils multi-agents
Présentation
Chaque agent dans une configuration multi-agents peut désormais avoir sa propre :- Configuration de sandbox (
agents.list[].sandboxremplaceagents.defaults.sandbox) - Restrictions d’outils (
tools.allow/tools.deny, plusagents.list[].tools)
- Assistant personnel avec accès complet
- Agents famille/travail avec outils restreints
- Agents exposés au public dans des sandboxes
setupCommand relève de sandbox.docker (global ou par agent) et s’exécute une seule fois
lorsque le conteneur est créé.
L’authentification est par agent : chaque agent lit depuis son propre magasin d’authentification agentDir à l’emplacement :
agentDir entre agents.
Si vous souhaitez partager des identifiants, copiez auth-profiles.json dans le agentDir de l’autre agent.
Pour le comportement du sandbox à l’exécution, voir Sandboxing.
Pour déboguer « pourquoi est-ce bloqué ? », voir Sandbox vs Tool Policy vs Elevated et openclaw sandbox explain.
Exemples de configuration
Exemple 1 : Agent personnel + agent familial restreint
- Agent
main: s’exécute sur l’hôte, accès complet aux outils - Agent
family: s’exécute dans Docker (un conteneur par agent), uniquement l’outilread
Exemple 2 : Agent de travail avec sandbox partagé
Exemple 2b : Profil de codage global + agent uniquement messagerie
- Les agents par défaut obtiennent les outils de codage
- L’agent
supportest uniquement messagerie (+ outil Slack)
Exemple 3 : Modes de sandbox différents par agent
Précédence de configuration
Lorsque des configurations globales (agents.defaults.*) et spécifiques à l’agent (agents.list[].*) existent :
Configuration du sandbox
Les paramètres spécifiques à l’agent remplacent les paramètres globaux :agents.list[].sandbox.{docker,browser,prune}.*remplaceagents.defaults.sandbox.{docker,browser,prune}.*pour cet agent (ignoré lorsque la portée du sandbox se résout en"shared").
Restrictions d’outils
L’ordre de filtrage est le suivant :- Profil d’outils (
tools.profileouagents.list[].tools.profile) - Profil d’outils du fournisseur (
tools.byProvider[provider].profileouagents.list[].tools.byProvider[provider].profile) - Politique d’outils globale (
tools.allow/tools.deny) - Politique d’outils du fournisseur (
tools.byProvider[provider].allow/deny) - Politique d’outils spécifique à l’agent (
agents.list[].tools.allow/deny) - Politique du fournisseur de l’agent (
agents.list[].tools.byProvider[provider].allow/deny) - Politique d’outils du sandbox (
tools.sandbox.toolsouagents.list[].tools.sandbox.tools) - Politique d’outils du sous-agent (
tools.subagents.tools, le cas échéant)
agents.list[].tools.sandbox.tools est défini, il remplace tools.sandbox.tools pour cet agent.
Si agents.list[].tools.profile est défini, il remplace tools.profile pour cet agent.
Les clés d’outils du fournisseur acceptent soit provider (par ex. google-antigravity), soit provider/model (par ex. openai/gpt-5.2).
Groupes d’outils (raccourcis)
Les politiques d’outils (globales, par agent, sandbox) prennent en charge des entréesgroup:* qui s’étendent à plusieurs outils concrets :
group:runtime:exec,bash,processgroup:fs:read,write,edit,apply_patchgroup:sessions:sessions_list,sessions_history,sessions_send,sessions_spawn,session_statusgroup:memory:memory_search,memory_getgroup:ui:browser,canvasgroup:automation:cron,gatewaygroup:messaging:messagegroup:nodes:nodesgroup:openclaw: tous les outils OpenClaw intégrés (exclut les plugins de fournisseur)
Mode Elevated
tools.elevated constitue la base globale (liste d’autorisation basée sur l’expéditeur). agents.list[].tools.elevated peut restreindre davantage l’elevated pour des agents spécifiques (les deux doivent autoriser).
Schémas d’atténuation :
- Refuser
execpour les agents non fiables (agents.list[].tools.deny: ["exec"]) - Éviter d’autoriser des expéditeurs qui routent vers des agents restreints
- Désactiver elevated globalement (
tools.elevated.enabled: false) si vous souhaitez uniquement une exécution sandboxée - Désactiver elevated par agent (
agents.list[].tools.elevated.enabled: false) pour des profils sensibles
Migration depuis un agent unique
Avant (agent unique) :agent.* sont migrées par openclaw doctor ; privilégiez agents.defaults + agents.list à l’avenir.
Exemples de restriction d’outils
Agent en lecture seule
Agent d’exécution sécurisée (aucune modification de fichiers)
Agent uniquement communication
Piège courant : « non-main »
agents.defaults.sandbox.mode: "non-main" est basé sur session.mainKey (par défaut "main"),
et non sur l’identifiant de l’agent. Les sessions de groupe/canal obtiennent toujours leurs propres clés,
elles sont donc traitées comme non-main et seront sandboxées. Si vous voulez qu’un agent ne soit jamais
sandboxé, définissez agents.list[].sandbox.mode: "off".
Tests
Après avoir configuré le sandbox et les outils multi-agents :-
Vérifier la résolution des agents :
-
Vérifier les conteneurs de sandbox :
-
Tester les restrictions d’outils :
- Envoyer un message nécessitant des outils restreints
- Vérifier que l’agent ne peut pas utiliser les outils refusés
-
Journaux du moniteur :
Problemes courants
Agent non sandboxé malgré mode: "all"
- Vérifiez s’il existe un
agents.defaults.sandbox.modeglobal qui l’écrase - La configuration spécifique à l’agent a priorité ; définissez donc
agents.list[].sandbox.mode: "all"
Outils toujours disponibles malgré la liste de refus
- Vérifiez l’ordre de filtrage des outils : global → agent → sandbox → sous-agent
- Chaque niveau ne peut que restreindre davantage, pas rétablir
- Vérifiez via les journaux :
[tools] filtering tools for agent:${agentId}
Conteneur non isolé par agent
- Définissez
scope: "agent"dans la configuration de sandbox spécifique à l’agent - La valeur par défaut est
"session", qui crée un conteneur par session