Permissions

Dropstone utilise la configuration permission pour décider si une action donnée doit s'exécuter automatiquement, vous demander confirmation, ou être bloquée.

L'ancienne configuration booléenne tools est obsolète ; elle a été fusionnée dans permission. L'ancienne configuration tools est toujours prise en charge pour la rétrocompatibilité.

Actions

Chaque règle de permission se résout en l'une des valeurs suivantes :

• "allow" : exécuter sans approbation
• "ask" : demander une approbation
• "deny" : bloquer l'action

Configuration

Vous pouvez définir des permissions globalement (avec *), et remplacer des outils spécifiques.

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "*": "ask",
    "bash": "allow",
    "edit": "deny"
  }
}

Vous pouvez également définir toutes les permissions d'un coup :

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": "allow"
}

Règles granulaires (syntaxe objet)

Pour la plupart des permissions, vous pouvez utiliser un objet pour appliquer différentes actions en fonction de l'entrée de l'outil.

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "bash": {
      "*": "ask",
      "git *": "allow",
      "npm *": "allow",
      "rm *": "deny",
      "grep *": "allow"
    },
    "edit": {
      "*": "deny",
      "packages/web/src/content/docs/*.mdx": "allow"
    }
  }
}

Les règles sont évaluées par correspondance de motifs, la dernière règle correspondante l'emportant. Un modèle courant consiste à placer la règle générique "*" en premier, et les règles plus spécifiques après.

Jokers

Les motifs de permission utilisent une correspondance par jokers simple :

• * correspond à zéro ou plusieurs caractères quelconques
• ? correspond à exactement un caractère
• Tous les autres caractères correspondent littéralement

Expansion du répertoire personnel

Vous pouvez utiliser ~ ou $HOME au début d'un motif pour référencer votre répertoire personnel. Cela est particulièrement utile pour les règles external_directory.

• ~/projects/* -> /Users/username/projects/*
• $HOME/projects/* -> /Users/username/projects/*
• ~ -> /Users/username

Répertoires externes

Utilisez external_directory pour autoriser les appels d'outils qui touchent des chemins en dehors du répertoire de travail où Dropstone a été démarré. Cela s'applique à tout outil qui prend un chemin en entrée (par exemple read, edit, glob, grep, et de nombreuses commandes bash).

L'expansion du répertoire personnel (comme ~/...) n'affecte que la façon dont un motif est écrit. Elle ne fait pas d'un chemin externe une partie de l'espace de travail actuel, donc les chemins en dehors du répertoire de travail doivent toujours être autorisés via external_directory.

Par exemple, cela autorise l'accès à tout ce qui se trouve sous ~/projects/personal/ :

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "external_directory": {
      "~/projects/personal/**": "allow"
    }
  }
}

Tout répertoire autorisé ici hérite des mêmes valeurs par défaut que l'espace de travail actuel. Puisque read est par défaut allow, les lectures sont également autorisées pour les entrées sous external_directory sauf si elles sont remplacées. Ajoutez des règles explicites lorsqu'un outil doit être restreint dans ces chemins, comme bloquer les modifications tout en autorisant les lectures :

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "external_directory": {
      "~/projects/personal/**": "allow"
    },
    "edit": {
      "~/projects/personal/**": "deny"
    }
  }
}

Gardez la liste concentrée sur les chemins de confiance, et superposez des règles d'autorisation ou de refus supplémentaires selon les besoins pour d'autres outils (par exemple bash).

Permissions disponibles

Les permissions Dropstone sont indexées par nom d'outil, plus quelques garde-fous de sécurité :

• read : lecture d'un fichier (correspond au chemin du fichier)
• edit : toutes les modifications de fichiers (couvre edit, write, patch)
• glob : recherche de fichiers par motif (correspond au motif glob)
• grep : recherche de contenu (correspond au motif regex)
• bash : exécution de commandes shell (correspond aux commandes analysées comme git status --porcelain)
• task : lancement de sous-agents (correspond au type de sous-agent)
• skill : chargement d'une compétence (correspond au nom de la compétence)
• lsp : exécution de requêtes LSP (actuellement non granulaire)
• question : poser des questions à l'utilisateur pendant l'exécution
• webfetch : récupération d'une URL (correspond à l'URL)
• websearch : recherche web (correspond à la requête)
• external_directory : déclenché lorsqu'un outil touche des chemins en dehors du répertoire de travail du projet
• doom_loop : déclenché lorsque le même appel d'outil se répète 3 fois avec une entrée identique

Valeurs par défaut

Si vous ne spécifiez rien, l'agent build par défaut demande confirmation avant tout. L'approbation est la valeur par défaut, pas une exception :

{
  "permission": {
    "*": "ask",
    "read": {
      "*": "ask",
      "*.env": "ask",
      "*.env.*": "ask",
      "*.env.example": "ask"
    },
    "external_directory": { "*": "ask" },
    "question": "deny",
    "plan_enter": "deny",
    "plan_exit": "deny",
    "mode_switch": "deny"
  }
}

Les répertoires que vous avez déjà approuvés sont ajoutés à external_directory comme "allow" pour le reste de la session.

Votre configuration est fusionnée par-dessus ces valeurs par défaut, et vos règles l'emportent. Elle ne les remplace pas : définir edit sur "allow" laisse read sur "ask", donc nommez chaque permission que vous avez l'intention de modifier.

L'agent accept all part de "*": "allow" à la place, avec external_directory entièrement autorisé. Les lectures de .env et .env.* demandent toujours confirmation, en raisonnant que l'approbation automatique d'une exécution n'est pas la même chose que consentir à remettre des secrets.

Mode sans tête et mode serveur

En mode interactif, "ask" est inoffensif : vous êtes invité à approuver. Sous dropstone serve, dans CI, ou partout ailleurs sans personne au clavier, il n'y a personne à qui demander, donc l'appel reste à "status": "running" et la requête reste bloquée au lieu d'échouer. Il n'y a pas de délai d'attente ni d'erreur à attraper.

Parce que l'agent build demande confirmation avant tout, c'est le résultat par défaut plutôt qu'un cas limite. Une configuration partielle ne vous sauve pas non plus : autoriser edit laisse read sur "ask", et l'exécution reste bloquée la première fois que l'agent ouvre un fichier.

Deux façons de résoudre ce problème. Soit exécutez l'agent accept all, qui part de "*": "allow" :

curl -X POST ".../session/$SID/message" -d '{ "agent": "accept all", ... }'

Ou restez sur build et indiquez la liste blanche complète, en refusant par défaut afin qu'un outil ajouté dans une version ultérieure ne puisse pas silencieusement bloquer vos exécutions :

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "*": "deny",
    "read": "allow",
    "edit": "allow",
    "glob": "allow",
    "grep": "allow",
    "bash": "allow"
  }
}

Réduisez cela à ce dont le travail a réellement besoin. Un agent qui ne fait que lire et rapporter n'a aucune raison de détenir edit ou bash.

Notez que accept all demande toujours confirmation avant de lire .env et .env.*. Si une exécution sans surveillance doit en lire un, autorisez-le explicitement et soyez délibéré à ce sujet.

Ce que fait "Ask"

Lorsque Dropstone demande une approbation, l'interface propose trois résultats :

• once : approuver uniquement cette requête
• always : approuver les requêtes futures correspondant aux motifs suggérés (pour le reste de la session Dropstone actuelle)
• reject : refuser la requête

L'ensemble des motifs que always approuverait est fourni par l'outil (par exemple, les approbations bash ajoutent généralement un préfixe de commande sûr à la liste blanche comme git status*).

Agents

Vous pouvez remplacer les permissions par agent. Les permissions d'agent sont fusionnées avec la configuration globale, et les règles d'agent ont priorité. En savoir plus sur les permissions d'agent.

{
  "$schema": "https://dropstone.io/schema/config.json",
  "permission": {
    "bash": {
      "*": "ask",
      "git *": "allow",
      "git commit *": "deny",
      "git push *": "deny",
      "grep *": "allow"
    }
  },
  "agent": {
    "build": {
      "permission": {
        "bash": {
          "*": "ask",
          "git *": "allow",
          "git commit *": "ask",
          "git push *": "deny",
          "grep *": "allow"
        }
      }
    }
  }
}

Vous pouvez également configurer les permissions d'agent en Markdown :

---
description: Revue de code sans modifications
mode: subagent
permission:
  edit: deny
  bash: ask
  webfetch: deny
---

Analysez uniquement le code et suggérez des modifications.