Autorisations

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	Smart	Bypass	Autonomous (sandbox)
Lecture seule	Lecture de fichiers, grep, glob	Auto	Auto	Auto	Auto	Auto
Fetch	Requêtes HTTP	Prompt	Prompt	Auto lorsqu’il est jugé sûr	Auto	Auto
Commandes Bash	Exécution de commandes shell	Prompt	Prompt	Auto lorsqu’il est jugé sûr	Auto	Auto
Modifications de fichiers via `edit`/`write`	Modifier/écrire des fichiers	Prompt	Auto (dans l’espace de travail)	Auto (dans l’espace de travail)	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 l’espace de travail sont approuvées automatiquement, mais les commandes shell et les écritures en dehors de l’espace de travail nécessitent toujours une confirmation. En mode Smart, les modifications dans l’espace de travail sont approuvées automatiquement comme en mode Accept Edits, et toutes les autres actions sont évaluées par un modèle rapide qui ne les exécute automatiquement que lorsqu’elles sont clairement sûres. Toute autre action nécessite une confirmation comme d’habitude. Consultez le mode Smart ci-dessous. 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 Smart, Bypass et Autonomous ne remplacent pas les autorisations au niveau 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 Smart

Smart se situe entre Accept Edits et Bypass. Les modifications de fichiers dans l’espace de travail sont automatiquement approuvées, exactement comme avec Accept Edits. Pour toute autre action — commandes shell, requêtes web, outils MCP, écritures en dehors de l’espace de travail — un modèle rapide détermine si l’action peut être exécutée sans supervision. Si elle est clairement sûre, elle s’exécute sans prompt ; dans le cas contraire, ou si le modèle est incertain ou indisponible, vous recevez le prompt d’approbation normal.

/smart
# ou
/mode smart

Vous pouvez également passer au mode Smart avec Shift+Tab, le sélectionner dans le sélecteur de mode ou démarrer dans ce mode :

devin --permission-mode smart
# ou
DEVIN_PERMISSION_MODE=smart devin

L’évaluation du modèle se limite aux tâches de développement courantes : build, tests, linting, formatage et inspection du projet. Certaines catégories ne sont jamais approuvées automatiquement en mode Smart, quelle que soit l’évaluation du modèle :

Installation de packages (npm install, pip install, cargo install, brew install, …)
Opérations git qui modifient l’état (les sous-commandes en lecture seule, comme git status, restent éligibles)
rm, sudo et autres commandes destructrices ou permettant une élévation de privilèges
kubectl delete et opérations destructrices via des CLI cloud (aws, gcloud, az, terraform, …)
Toute opération qui lit ou écrit des fichiers dotenv, des clés, la configuration Git ou la configuration propre de l’agent

Smart se distingue des modes voisins par les actions qu’il délègue :

	Accepter les modifications	Smart	Bypass
Modifications de fichiers de l’espace de travail	Auto	Auto	Auto
Commandes Shell et requête réseau	Toujours demander	Auto uniquement lorsque le modèle les juge sûres	Toujours auto
Commandes à haut risque (installations, `rm`, `sudo`, opérations `git` modificatrices)	Toujours demander	Toujours demander	Toujours auto

Vos propres règles restent prioritaires. L’évaluation de Smart s’applique uniquement lorsqu’aucune règle ne décide déjà de l’action : une règle deny bloque donc l’action et une règle ask demande toujours une approbation, exactement comme décrit dans Fonctionnement des autorisations. Les règles deny et ask au niveau de l’organisation ne sont pas non plus affectées.

Le mode Smart est déployé progressivement ; il est donc possible qu’il n’apparaisse pas encore dans votre sélecteur de mode ou dans le cycle Shift+Tab.

Mode Autonomous

Autonomous est le mode d’autorisation associé à l’option --sandbox. En pratique, il correspond approximativement à « Accept Edits dans l’espace de travail actuel », 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, Smart et Bypass sont masqués dans les sessions sandbox. Le mode Plan reste disponible.
Les commandes shell et les requêtes réseau 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 Write(...) accordés en cours de session étendent dynamiquement le sandbox pour les commandes suivantes. Les approbations Read(...) accordées en cours de session affectent uniquement les propres outils de l’agent ; les chemins masqués par les règles de refus Read(...) restent masqués pendant toute la session.

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 écriture, les règles de refus 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

Les prompts Command proposent explicitement les deux périmètres : « Oui, toujours autoriser les commandes <cmd> dans <project> » enregistre l’autorisation pour le projet actuel, tandis que « Oui, toujours autoriser les commandes <cmd> dans tous les projets » l’enregistre dans votre configuration utilisateur afin qu’elle s’applique partout. Les prompts de requête Web pour une URL ou un domaine spécifique proposent une option équivalente, « Oui, toujours autoriser toutes les requêtes Web », qui ajoute les requêtes Web à la liste d’autorisation en une seule étape.

Modifier une commande avant de l’approuver

Les invites d’approbation de Command ne se limitent pas à un simple oui ou non. En plus des options d’approbation, une invite de commande propose :

Option	Effet
Modifier la commande	Ouvre la commande proposée pour la modifier directement afin de pouvoir l’ajuster avant son exécution
Décrire la modification à apporter à la commande	Réécrit la commande à partir d’une description en langage naturel de ce que vous souhaitez qu’elle fasse, afin que vous puissiez la vérifier avant de l’exécuter

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.

Prise en main

Intégrations d’éditeur

Extensibilité

Entreprise

Référence

Changelog

Comportement par défaut des autorisations

Mode Smart

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

Modifier une commande avant de l’approuver

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 Smart

​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

​Modifier une commande avant de l’approuver

​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 Smart

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

Modifier une commande avant de l’approuver

Autorisations au niveau du serveur MCP

Ordre de priorité

Exemples

Configuration de développement minimale

Confiance totale pour un projet

Enterprise verrouillée