Autorisations - Devin Docs

Le système d’autorisation détermine quelles actions l’agent peut effectuer sans vous demander votre approbation. Vous pouvez préapprouver les actions sûres, bloquer les actions dangereuses et toujours demander une confirmation pour les opérations sensibles.

Comportement par défaut des autorisations

Devin CLI utilise un système d’autorisations à plusieurs niveaux pour concilier puissance et sécurité. Le comportement par défaut dépend du mode actuel : Chaque cellule indique si cet outil s’exécute automatiquement (Auto, sans confirmation) ou attend votre approbation (Prompt) dans ce mode :

Type d’outil	Exemple	Normal	Accept Edits	Bypass	Autonomous (sandbox)
Lecture seule	Lecture de fichiers, grep, glob	Auto	Auto	Auto	Auto
Fetch	Requêtes HTTP	Prompt	Prompt	Auto	Auto
Commandes Bash	Exécution de commandes shell	Prompt	Prompt	Auto	Auto
Modifications de fichiers via `edit`/`write`	Modifier/écrire des fichiers	Prompt	Auto (dans le workspace)	Auto	Prompt

En mode Normal (par défaut), les opérations en lecture seule sont approuvées automatiquement, tandis que les écritures et les commandes shell nécessitent votre approbation explicite. Chaque fois que vous approuvez une action, vous pouvez choisir de l’autoriser une seule fois, pour la session ou de façon permanente pour le projet. En mode Accept Edits, les modifications de fichiers dans le workspace sont approuvées automatiquement, mais les commandes shell et les écritures en dehors du workspace nécessitent toujours une confirmation. En mode Bypass, tous les appels aux outils sont approuvés automatiquement, sans confirmation. En mode Autonomous, les commandes shell et les requêtes réseau sont approuvées automatiquement, car le sandbox au niveau du système d’exploitation limite ce à quoi elles peuvent accéder. Les modifications directes de fichiers via les outils edit/write nécessitent toujours une confirmation, car ces outils fonctionnent en dehors du sandbox. Autonomous n’est disponible que lorsque le sandbox au niveau du système d’exploitation est actif.

Les modes Bypass et Autonomous ne remplacent pas les autorisations à l’échelle de l’organisation. Les règles de refus et de demande imposées par les admins, configurées via Team Settings, restent actives quel que soit le mode d’autorisation de l’utilisateur. Consultez Precedence pour plus de détails.

Mode Autonomous

Autonomous est le mode d’autorisation associé à l’option --sandbox. En pratique, il correspond approximativement à « Accept Edits in the current workspace », avec en plus la possibilité d’exécuter n’importe quelle commande shell, les deux étant confinés par le sandbox au niveau du système d’exploitation. Lorsque le sandbox est actif :

C’est le seul mode d’autorisation disponible. Les modes Normal, Accept Edits et Bypass sont masqués dans les sessions sandbox. Le mode Plan reste disponible.
Les commandes shell et les opérations de récupération sont automatiquement approuvées au lieu d’afficher une demande de confirmation, car le sandbox contrôle ce qu’elles peuvent lire, écrire et atteindre sur le réseau.
Les modifications directes de fichiers via les outils edit et write continuent de demander une confirmation. Ces outils s’exécutent dans le processus CLI plutôt qu’à l’intérieur du sandbox, et ne peuvent donc pas être confinés par celui-ci. Accorder un périmètre Write(...) dans le prompt étend dynamiquement le sandbox afin que les commandes shell suivantes puissent y écrire.
Les périmètres accordés en cours de session étendent dynamiquement le sandbox pour les commandes suivantes.

devin --sandbox --permission-mode autonomous

Utilisez Bypass lorsque vous voulez une exécution sans restriction, sans isolation au niveau du système d’exploitation ; utilisez --sandbox (qui sélectionne Autonomous) lorsque vous voulez une exécution non supervisée avec des restrictions imposées par le système d’exploitation sur l’accès au système de fichiers et au réseau. Consultez la référence de configuration du sandbox pour en savoir plus sur les racines accessibles en lecture/écriture et le filtrage des domaines, ainsi que Team Settings → Sandbox Enforcement pour les contrôles au niveau Enterprise.

Fonctionnement des autorisations

Lorsque l’agent appelle un outil, le système d’autorisations évalue vos règles par ordre de priorité :

Règles de refus — Vérifiées en premier. En cas de correspondance, l’action est bloquée immédiatement.
Règles de demande — Vérifiées en deuxième. En cas de correspondance, une confirmation vous est toujours demandée (cela prévaut sur toute règle d’autorisation).
Règles d’autorisation — Vérifiées en dernier. En cas de correspondance, l’action s’exécute sans demander de confirmation.
Par défaut — Si aucune règle ne correspond, une approbation vous est demandée.

Comme les refus sont vérifiés avant les demandes, et les demandes avant les autorisations, une règle de refus l’emporte toujours. Si le même périmètre correspond à la fois à une règle de refus et à une règle de demande, c’est la règle de refus qui s’applique.

Configuration

Ajoutez des autorisations dans la section permissions de votre fichier de configuration :

Sous Windows, le chemin du fichier de configuration utilisateur est %APPDATA%\devin\config.json (généralement C:\Users\<you>\AppData\Roaming\devin\config.json) et non ~/.config/devin/config.json. Consultez Fichier de configuration pour plus de détails.

Configuration du projet
Configuration utilisateur
Dérogation locale

// .devin/config.json
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(npm run)"
    ],
    "deny": [
      "Exec(rm)"
    ]
  }
}

// ~/.config/devin/config.json
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git)"
    ]
  }
}

// .devin/config.local.json
{
  "permissions": {
    "allow": [
      "Exec(docker compose)"
    ]
  }
}

Syntaxe des autorisations

Il existe deux types de critères de correspondance pour les autorisations : basés sur le périmètre (qui contrôlent les chemins/commandes/URL accessibles) et basés sur les outils (qui contrôlent les outils pouvant être utilisés).

Autorisations basées sur le périmètre

Read(glob)

Contrôle l’accès en lecture aux fichiers. Le motif glob correspond aux chemins de fichiers.

"allow": [
  "Read(src/**)",           // Tous les fichiers dans src/
  "Read(~/.config/**)",     // Fichiers de configuration du répertoire personnel
  "Read(/tmp/**)"           // Répertoire temporaire
]

Les chemins de répertoire correspondent automatiquement à tous les fichiers qu’ils contiennent.

Write(glob)

Contrôle l’accès en écriture et en modification des fichiers.

"allow": [
  "Write(src/**)",          // Peut écrire n'importe où dans src/
  "Write(tests/**)"         // Peut écrire dans les fichiers de test
],
"deny": [
  "Write(*.lock)",          // Ne peut pas modifier les fichiers .lock
  "Write(.env*)"            // Ne peut pas modifier les fichiers .env
]

Exec(prefix)

Contrôle l’exécution des commandes shell. S’applique aux commandes qui commencent par le préfixe donné.

"allow": [
  "Exec(git)",              // git, git status, git commit...
  "Exec(npm run)",          // npm run test, npm run build...
  "Exec(python)"            // python, python script.py...
],
"deny": [
  "Exec(rm)",               // Bloque rm, rm -rf, etc.
  "Exec(sudo)"              // Bloque les commandes sudo
]

Exec(git) correspond à “git”, “git status”, “git commit -m ‘msg’” mais PAS à “gitk” ni à “github-cli”. Le préfixe doit correspondre à un mot complet.

Fetch(pattern)

Contrôle l’accès aux requêtes HTTP fetch à l’aide de motifs d’URL.

"allow": [
  "Fetch(https://api.github.com/*)",    // API GitHub
  "Fetch(https://*.example.com/*)",     // Tous les sous-domaines de example.com
  "Fetch(domain:npmjs.org)"             // N'importe quelle URL sur npmjs.org
]

Les motifs d’URL suivent la norme WHATWG URL Pattern. Le raccourci domain: correspond à n’importe quel chemin sur le domaine exact.

Autorisations par outil

Faites correspondre le nom de l’outil pour contrôler des outils entiers :

{
  "permissions": {
    "deny": [
      "edit",       // Bloquer toutes les modifications de fichiers
      "exec"        // Bloquer toute exécution de commandes
    ],
    "allow": [
      "read",       // Autoriser toutes les lectures de fichiers
      "grep",       // Autoriser toutes les recherches
      "glob"        // Autoriser toutes les recherches de fichiers
    ]
  }
}

Noms des outils disponibles : read, edit, grep, glob, exec

Autorisations des outils du serveur MCP

Contrôlez l’accès aux outils du serveur MCP :

{
  "permissions": {
    "allow": [
      "mcp__github__list_issues",     // Outil spécifique sur un serveur spécifique
      "mcp__github__*",               // Tous les outils sur le serveur github
      "mcp__*"                        // Tous les outils MCP
    ],
    "deny": [
      "mcp__github__delete_repo"      // Bloquer un outil dangereux spécifique
    ]
  }
}

Motif	Correspond à
`mcp__server__tool`	Un outil spécifique
`mcp__server__*`	Tous les outils d’un serveur
`mcp__*`	Tous les outils MCP

Motifs de chemin

Les motifs glob dans Read() et Write() prennent en charge :

Motif	Signification
`*`	N’importe quels caractères dans un seul segment de chemin
`**`	N’importe quels caractères sur plusieurs segments de chemin (récursif)
`~`	Expansion du répertoire personnel

Exemples :

"allow": [
  "Read(**)",                    // Tous les fichiers partout
  "Read(src/**/*.ts)",           // Tous les fichiers TypeScript dans src/
  "Write(~/projects/myapp/**)"   // Écriture dans un projet spécifique
]

Utilisez un préfixe de chemin absolu (par ex., Read(/**)) lorsque vous souhaitez inclure tous les fichiers du système. Un simple Read(**) sans / au début est interprété par rapport à votre répertoire de travail actuel ; il ne correspond donc qu’aux fichiers situés dans ce répertoire — et non à ceux auxquels on accède ailleurs via des chemins absolus.

Options de persistance

Lorsque l’agent demande une autorisation pendant une session, vous pouvez choisir comment enregistrer votre décision :

Option	Emplacement d’enregistrement	Partagé avec la Team ?
Autoriser une fois	Non enregistré	Non
Autoriser pour la session	En mémoire uniquement	Non
Autoriser pour le projet	`.devin/config.json`	Oui
Autoriser pour le projet (local)	`.devin/config.local.json`	Non
Autoriser globalement	`~/.config/devin/config.json` (`%APPDATA%\devin\config.json` sous Windows)	Non

Autorisations au niveau du serveur MCP

Lorsqu’une demande d’autorisation s’affiche pour un outil MCP spécifique (p. ex., list_issues sur le serveur Figma), l’invite d’autorisation propose également des options plus larges à l’échelle du serveur :

Option	Effet
Autoriser cet outil (cette session)	Accorde l’accès à l’outil spécifique pour la session en cours
Toujours autoriser cet outil	Enregistre l’autorisation pour cet outil dans la configuration
Autoriser tous les outils sur ce serveur (cette session)	Accorde l’accès à tous les outils du serveur pour la session
Toujours autoriser les outils sur ce serveur	Enregistre l’accès à tous les outils du serveur dans la configuration

Cela vous permet d’accorder rapidement un accès général à un serveur MCP de confiance sans devoir approuver chaque outil individuellement.

Ordre de priorité

Lorsque plusieurs sources d’autorisation définissent des règles, elles sont fusionnées selon l’ordre de priorité suivant (de la plus élevée à la plus faible) :

Settings de l’organisation/de la Team (si Enterprise)
Autorisations au niveau de la session (approbations interactives)
Configuration locale du projet (.devin/config.local.json)
Configuration du projet (.devin/config.json)
Configuration utilisateur (~/.config/devin/config.json ; %APPDATA%\devin\config.json sous Windows)

Les refus définis au niveau de l’organisation ne peuvent pas être remplacés par la configuration du projet ou de l’utilisateur. Cela garantit l’application des politiques Enterprise.

Exemples

Configuration de développement minimale

Autorisez les opérations courantes en lecture seule et demandez une confirmation pour tout le reste :

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(git log)"
    ]
  }
}

Confiance totale pour un projet

Approuvez automatiquement la plupart des opérations dans le projet :

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Write(src/**)",
      "Write(tests/**)",
      "Exec(npm)",
      "Exec(git)",
      "Exec(node)"
    ],
    "deny": [
      "Exec(rm -rf)",
      "Exec(sudo)",
      "Write(.env*)"
    ]
  }
}

Enterprise verrouillée

Limiter aux seules opérations sûres spécifiques, et toujours demander une confirmation avant toute écriture :

{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(npm run lint)"
    ],
    "deny": [
      "Exec(rm)",
      "Exec(sudo)",
      "Write(.env*)"
    ],
    "ask": [
      "Write(**)",
      "exec"
    ]
  }
}

Dans cet exemple, les écritures dans .env* sont purement et simplement refusées, toutes les autres écritures demandent systématiquement confirmation à l’utilisateur, et seules quelques commandes en lecture seule sont approuvées automatiquement. Comme deny est vérifié avant ask, le refus de .env* prévaut sur la règle Write(**) ask.

​Comportement par défaut des autorisations

​Mode Autonomous

​Fonctionnement des autorisations

​Configuration

​Syntaxe des autorisations

​Autorisations basées sur le périmètre

​Autorisations par outil

​Autorisations des outils du serveur MCP

​Motifs de chemin

​Options de persistance

​Autorisations au niveau du serveur MCP

​Ordre de priorité

​Exemples

​Configuration de développement minimale

​Confiance totale pour un projet

​Enterprise verrouillée

Comportement par défaut des autorisations

Mode Autonomous

Fonctionnement des autorisations

Configuration

Syntaxe des autorisations

Autorisations basées sur le périmètre

Autorisations par outil

Autorisations des outils du serveur MCP

Motifs de chemin

Options de persistance

Autorisations au niveau du serveur MCP

Ordre de priorité

Exemples

Configuration de développement minimale

Confiance totale pour un projet

Enterprise verrouillée