Autorizzazioni - Devin Docs

Il sistema di autorizzazioni controlla quali azioni l’agente può eseguire senza chiedere la tua approvazione. Puoi pre-approvare le azioni sicure, bloccare quelle pericolose e richiedere sempre una conferma per le operazioni sensibili.

Comportamento predefinito delle autorizzazioni

Devin CLI utilizza un sistema di autorizzazioni a livelli per bilanciare potenza e sicurezza. Il comportamento predefinito dipende dalla modalità corrente: Ogni cella mostra se quello strumento viene eseguito automaticamente (Auto, senza richiesta) oppure resta in attesa della tua approvazione (Richiesta) in quella modalità:

Tipo di strumento	Esempio	Normal	Accept Edits	Bypass	Autonomous (sandbox)
Sola lettura	Lettura di file, grep, glob	Auto	Auto	Auto	Auto
Fetch	Richieste HTTP	Richiesta	Richiesta	Auto	Auto
Comandi Bash	Esecuzione della shell	Richiesta	Richiesta	Auto	Auto
Modifiche ai file tramite `edit`/`write`	Modifica/scrittura di file	Richiesta	Auto (nel workspace)	Auto	Richiesta

In modalità Normal (quella predefinita), le operazioni in sola lettura vengono approvate automaticamente, mentre le scritture e i comandi della shell richiedono la tua approvazione esplicita. Ogni volta che approvi un’azione, puoi scegliere di consentirla una sola volta, per la sessione oppure in modo permanente per il progetto. In modalità Accept Edits, le modifiche ai file all’interno del workspace vengono approvate automaticamente, ma i comandi della shell e le scritture al di fuori del workspace continuano a richiedere conferma. In modalità Bypass, tutte le chiamate agli strumenti vengono approvate automaticamente senza richiesta di conferma. In modalità Autonomous, i comandi della shell e i recuperi di rete vengono approvati automaticamente perché il sandbox a livello di sistema operativo limita ciò con cui possono interagire. Le modifiche dirette ai file tramite gli strumenti edit/write continuano a richiedere conferma, perché questi strumenti operano al di fuori del sandbox. La modalità Autonomous è disponibile solo quando il sandbox a livello di sistema operativo è attivo.

Le modalità Bypass e Autonomous non fanno override delle autorizzazioni a livello di organizzazione. Le regole di deny e ask imposte dagli admin e configurate tramite Team Settings restano attive indipendentemente dalla modalità di autorizzazione dell’utente. Per i dettagli, vedi Precedenza.

Modalità Autonomous

Autonomous è la modalità di autorizzazione associata al flag --sandbox. In pratica, corrisponde più o meno a “Accetta modifiche nel workspace corrente” con in più la possibilità di eseguire qualsiasi comando della shell, il tutto confinato nel sandbox a livello di sistema operativo. Quando il sandbox è attivo:

È l’unica modalità di autorizzazione disponibile. Nelle sessioni sandbox, Normal, Accept Edits e Bypass sono nascosti. La modalità Plan rimane disponibile.
I comandi della shell e i fetch vengono approvati automaticamente invece di richiedere conferma, perché il sandbox limita ciò che possono leggere, scrivere e raggiungere tramite la rete.
Le modifiche dirette ai file tramite gli strumenti edit e write continuano a richiedere conferma. Questi strumenti vengono eseguiti all’interno del processo CLI anziché nel sandbox, quindi non possono esserne vincolati. Concedere un ambito Write(...) al prompt espande dinamicamente il sandbox, così i comandi della shell successivi possono scrivere in quella posizione.
Gli ambiti concessi nel corso della sessione espandono dinamicamente il sandbox per i comandi successivi.

devin --sandbox --permission-mode autonomous

Usa Bypass quando vuoi un’esecuzione senza restrizioni e senza isolamento a livello di sistema operativo; usa --sandbox (che seleziona Autonomous) quando vuoi un’esecuzione senza supervisione con limiti imposti dal sistema operativo sull’accesso al filesystem e alla rete. Consulta il riferimento della configurazione della sandbox per i dettagli sulle radici leggibili/scrivibili e sul filtraggio dei domini, e Team Settings → Applicazione sandbox per i controlli Enterprise.

Come funzionano le autorizzazioni

Quando l’agente richiama uno strumento, il sistema di autorizzazioni controlla le tue regole in ordine di priorità:

Regole di deny — Controllate per prime. Se c’è una corrispondenza, l’azione viene bloccata immediatamente.
Regole di ask — Controllate per seconde. Se c’è una corrispondenza, ti viene sempre chiesta conferma (ha la precedenza su qualsiasi regola di autorizzazione).
Regole di autorizzazione — Controllate per ultime. Se c’è una corrispondenza, l’azione procede senza chiedere conferma.
Predefinito — Se nessuna regola corrisponde, ti viene chiesta l’approvazione.

Poiché le regole di deny vengono controllate prima di quelle di ask, e quelle di ask prima di quelle di autorizzazione, una regola di deny ha sempre la precedenza. Se lo stesso ambito corrisponde sia a una regola di deny sia a una regola di ask, prevale la regola di deny.

Configurazione

Aggiungi le autorizzazioni alla sezione permissions del file di configurazione:

Su Windows, il percorso del file di configurazione dell’utente è %APPDATA%\devin\config.json (in genere C:\Users\<you>\AppData\Roaming\devin\config.json) anziché ~/.config/devin/config.json. Per maggiori dettagli, consulta File di configurazione.

Configurazione del progetto
Configurazione utente
Override 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)"
    ]
  }
}

Sintassi delle autorizzazioni

Esistono due tipi di matcher di autorizzazione: basati sull’ambito (controllano quali percorsi/comandi/URL sono accessibili) e basati sugli strumenti (controllano quali strumenti possono essere utilizzati).

Autorizzazioni basate sull’ambito

Read(glob)

Controlla l’accesso in lettura ai file. Il pattern glob corrisponde ai percorsi dei file.

"allow": [
  "Read(src/**)",           // Tutti i file in src/
  "Read(~/.config/**)",     // File di configurazione nella home
  "Read(/tmp/**)"           // Directory temporanea
]

I percorsi di directory corrispondono automaticamente a tutti i file al loro interno.

Write(glob)

Controlla l’accesso in scrittura e modifica dei file.

"allow": [
  "Write(src/**)",          // Può scrivere ovunque in src/
  "Write(tests/**)"         // Può scrivere nei file di test
],
"deny": [
  "Write(*.lock)",          // Non può modificare i file lock
  "Write(.env*)"            // Non può modificare i file env
]

Exec(prefix)

Controlla l’esecuzione dei comandi shell. Corrisponde ai comandi che iniziano con il prefisso specificato.

"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)",               // Blocca rm, rm -rf, ecc.
  "Exec(sudo)"              // Blocca i comandi sudo
]

Exec(git) corrisponde a “git”, “git status”, “git commit -m ‘msg’” ma NON a “gitk” o “github-cli”. Il prefisso deve corrispondere a una parola completa.

Fetch(pattern)

Controlla l’accesso HTTP fetch tramite pattern URL.

"allow": [
  "Fetch(https://api.github.com/*)",    // API di GitHub
  "Fetch(https://*.example.com/*)",     // Tutti i sottodomini di example.com
  "Fetch(domain:npmjs.org)"             // Qualsiasi URL su npmjs.org
]

I pattern URL seguono lo standard WHATWG URL Pattern. La forma abbreviata domain: corrisponde a qualsiasi percorso sul dominio esatto.

Autorizzazioni per strumento

Usa il nome dello strumento per controllare interi strumenti:

{
  "permissions": {
    "deny": [
      "edit",       // Blocca tutte le modifiche ai file
      "exec"        // Blocca l'esecuzione di tutti i comandi
    ],
    "allow": [
      "read",       // Consenti tutte le letture di file
      "grep",       // Consenti tutte le ricerche
      "glob"        // Consenti la ricerca di tutti i file
    ]
  }
}

Nomi degli strumenti disponibili: read, edit, grep, glob, exec

Autorizzazioni per gli strumenti MCP

Controlla l’accesso agli strumenti del server MCP:

{
  "permissions": {
    "allow": [
      "mcp__github__list_issues",     // Strumento specifico su server specifico
      "mcp__github__*",               // Tutti gli strumenti sul server github
      "mcp__*"                        // Tutti gli strumenti MCP
    ],
    "deny": [
      "mcp__github__delete_repo"      // Blocca uno strumento pericoloso specifico
    ]
  }
}

Pattern	Corrispondenze
`mcp__server__tool`	Uno strumento specifico
`mcp__server__*`	Tutti gli strumenti di un server
`mcp__*`	Tutti gli strumenti MCP ovunque

Pattern di percorso

I pattern glob in Read() e Write() supportano:

Pattern	Significato
`*`	Qualsiasi sequenza di caratteri in un singolo segmento del percorso
`**`	Qualsiasi sequenza di caratteri attraverso più segmenti del percorso (ricorsivo)
`~`	Espansione della home directory

Esempi:

"allow": [
  "Read(**)",                    // Tutti i file ovunque
  "Read(src/**/*.ts)",           // Tutti i file TypeScript in src/
  "Write(~/projects/myapp/**)"   // Scrittura in un progetto specifico
]

Usa un prefisso di percorso assoluto (ad es. Read(/**)) quando vuoi includere tutti i file del sistema. Un semplice Read(**) senza una / iniziale viene interpretato in relazione alla directory di lavoro corrente, quindi corrisponde solo ai file in quella directory, non ai file accessibili altrove tramite percorsi assoluti.

Opzioni di persistenza

Quando l’agente richiede un’autorizzazione durante una sessione, puoi scegliere come salvare la decisione:

Opzione	Dove viene salvata	Condivisa con il team?
Consenti una volta	Non salvata	No
Consenti per la sessione	Solo in memoria	No
Consenti per il progetto	`.devin/config.json`	Sì
Consenti per il progetto (locale)	`.devin/config.local.json`	No
Consenti globalmente	`~/.config/devin/config.json` (`%APPDATA%\devin\config.json` in Windows)	No

Autorizzazioni a livello di server MCP

Quando viene richiesta un’autorizzazione per uno specifico strumento MCP (ad es. list_issues sul server Figma), il prompt di autorizzazione offre anche opzioni più ampie a livello di server:

Opzione	Effetto
Consenti questo strumento (questa sessione)	Concede l’accesso allo strumento specifico per la sessione corrente
Consenti sempre questo strumento	Salva nella configurazione l’autorizzazione per lo strumento specifico
Consenti tutti gli strumenti su questo server (questa sessione)	Concede l’accesso a tutti gli strumenti del server per la sessione corrente
Consenti sempre gli strumenti su questo server	Salva nella configurazione l’accesso a tutti gli strumenti del server

Questo ti consente di concedere rapidamente l’accesso completo a un server MCP attendibile senza dover approvare ogni singolo strumento.

Precedenza

Quando più fonti di autorizzazione definiscono delle regole, vengono combinate secondo questo ordine di precedenza (dalla più alta alla più bassa):

Settings dell’organizzazione/del team (se Enterprise)
Autorizzazioni concesse a livello di sessione (approvazioni interattive)
Configurazione locale del progetto (.devin/config.local.json)
Configurazione del progetto (.devin/config.json)
Configurazione utente (~/.config/devin/config.json; %APPDATA%\devin\config.json su Windows)

I deny a livello di organizzazione non possono essere sovrascritti dalla configurazione del progetto o dell’utente. Questo garantisce l’applicazione dei criteri Enterprise.

Esempi

Configurazione minima per lo sviluppo

Consenti le comuni operazioni di sola lettura, chiedi conferma per tutto il resto:

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

Attendibilità completa per un progetto

Approva automaticamente la maggior parte delle operazioni nel progetto:

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

Enterprise con restrizioni rigide

Limita l’accesso a specifiche operazioni sicure e richiedi sempre conferma per le operazioni di scrittura:

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

In questo esempio, le scritture in .env* vengono negate direttamente, tutte le altre scritture richiedono sempre conferma all’utente e solo alcuni comandi in sola lettura vengono approvati automaticamente. Poiché deny viene verificato prima di ask, il deny di .env* ha la precedenza sulla regola ask Write(**).

​Comportamento predefinito delle autorizzazioni

​Modalità Autonomous

​Come funzionano le autorizzazioni

​Configurazione

​Sintassi delle autorizzazioni

​Autorizzazioni basate sull’ambito

​Autorizzazioni per strumento

​Autorizzazioni per gli strumenti MCP

​Pattern di percorso

​Opzioni di persistenza

​Autorizzazioni a livello di server MCP

​Precedenza

​Esempi

​Configurazione minima per lo sviluppo

​Attendibilità completa per un progetto

​Enterprise con restrizioni rigide

Comportamento predefinito delle autorizzazioni

Modalità Autonomous

Come funzionano le autorizzazioni

Configurazione

Sintassi delle autorizzazioni

Autorizzazioni basate sull’ambito

Autorizzazioni per strumento

Autorizzazioni per gli strumenti MCP

Pattern di percorso

Opzioni di persistenza

Autorizzazioni a livello di server MCP

Precedenza

Esempi

Configurazione minima per lo sviluppo

Attendibilità completa per un progetto

Enterprise con restrizioni rigide