Contrôler les permissions des outils
Autorisez ou refusez les appels d’outils et utilisez des hooks pour intervenir dans la boucle intégrée.
Les permissions déterminent quels appels d’outils sont autorisés. Les hooks exécutent votre code à des moments précis de la boucle intégrée. Ces deux réglages appartiennent à createHarness(). Pour préparer une sandbox avant un échange, utilisez plutôt les hooks d’environnement.
N’autoriser que ce dont la tâche a besoin
Section intitulée « N’autoriser que ce dont la tâche a besoin »Le modèle peut lire tous les fichiers sauf les fichiers .env, modifier sous src/ et test/, et lancer npm test. Tout autre appel renvoie Denied: <raison> au modèle comme résultat d’outil en échec, et la boucle continue. Passez harness à createAgent({ harness, model }).
Écrire les règles
Section intitulée « Écrire les règles »Chaque règle a un effect ("allow" ou "deny") et une ou plusieurs conditions. Une règle s’applique quand toutes ses conditions correspondent.
Référence API : HarnessPermissionRule.
La première règle qui s’applique décide. Sans correspondance, default s’applique ; il vaut "allow" s’il est omis. Une règle d’autorisation avec paths exige que tous les chemins de l’appel correspondent ; une règle de refus n’en exige qu’un.
paths et commands ne ciblent que les outils qui les déclarent. Les outils intégrés de fichiers, d’édition et de recherche déclarent leurs chemins ; shell et git déclarent leur commande. Pour vos propres outils, déclarez resources(input) (voir Outils).
Intercepter les appels avec des hooks
Section intitulée « Intercepter les appels avec des hooks »Utilisez des hooks pour ajouter des consignes au démarrage, refuser les appels à write_file après l’étape 20 et demander un compte rendu des tests avant que l’agent termine. Passez la liste exportée à createHarness({ hooks }).
Passez la liste à createHarness({ hooks }). Un hook qui ne renvoie rien laisse la boucle inchangée.
Référence API : HarnessHookPhase, HarnessHookEvents, HarnessHookDecisions et HarnessHookContext.
Ordre des contrôles et des hooks
Section intitulée « Ordre des contrôles et des hooks »Les hooks d’une même phase s’exécutent dans l’ordre de déclaration. Pour stop, le premier hook qui renvoie { continue } l’emporte, et l’étape supplémentaire compte dans limits.maxSteps.
Appliquer les règles aux sous-agents
Section intitulée « Appliquer les règles aux sous-agents »Un appel d’un sous-agent ne s’exécute que si ses permissions et celles de tous ses ancêtres l’autorisent, y compris après une réécriture par un hook. Les hooks restent attachés au harness qui les déclare : les hooks du parent ne voient pas les appels de l’enfant.
- Les règles ne voient que ce qu’un outil déclare dans
resources(input). Un outil sans cette déclaration ne peut être ciblé que par son nom. commands: ["npm test*"]autorise aussinpm test; rm -rf src. Listez les lignes de commande exactes.- Les chemins absolus et ceux qui sortent du dépôt ne correspondent à aucun motif
paths: les règles de refus sur les chemins ne les interceptent pas. Les outils intégrés refusent ces chemins ; vérifiez-les dans vos propres outils. - Les règles et les hooks contrôlent quels appels démarrent, pas ce que fait un outil autorisé :
npm testexécute tout ce que lance le script de test. L’isolation vient de la sandbox ; voir Sécurité.
API : defineHarnessPermissions · HarnessPermissionRule · defineHarnessHook · HarnessHookPhase · createHarness.