Skip to main content
I profili di sicurezza consentono di definire set riutilizzabili di restrizioni di sicurezza — accesso di rete, accesso MCP, accesso git e credenziali GitHub CLI — e di applicarli alle sessioni Devin nell’intera organizzazione. Invece di configurare le restrizioni sessione per sessione, gli admin creano una sola volta profili con nome e li associano al livello più appropriato: come impostazione predefinita valida per tutta l’organizzazione, in una specifica automazione o in una singola sessione. Le organizzazioni Enterprise possono inoltre condividere i profili tra tutte le organizzazioni e applicarli come soglia minima vincolante che nessuno ai livelli inferiori può allentare.

​
Restrizioni in un profilo

Un profilo è un insieme di restrizioni denominato. Ogni restrizione è facoltativa: un profilo limita solo le impostazioni che configura.

​
Policy di rete

Una policy di rete è una allowlist di destinazioni che la macchina della sessione è autorizzata a raggiungere. Tutte le altre connessioni in uscita vengono bloccate. Le voci dell’allowlist possono essere:
  • Hostname, con caratteri jolly * (ad es. *.github.com, registry.npmjs.org). Un * corrisponde a qualsiasi sequenza di caratteri, inclusi i punti.
  • Intervalli CIDR IPv4 / IPv6 (ad es. 10.0.0.0/8).
La restrizione si applica a qualsiasi accesso di rete dalla sessione — comandi della shell, navigazione, installazione di pacchetti e script. Devin riconosce quando è in esecuzione con una policy di rete restrittiva: può vedere l’allowlist corrente e, quando viene bloccato a causa di una destinazione mancante, richiede l’accesso. L’approvazione della richiesta aggiunge la destinazione per quella sessione (nel rispetto di eventuali vincoli obbligatori — vedi applicazione). Le destinazioni necessarie al funzionamento di Devin (come il proxy git usato per raggiungere i repo collegati) sono consentite automaticamente.

​
Accesso MCP

Per impostazione predefinita, le sessioni possono usare qualsiasi server MCP installato nella tua organizzazione. Un profilo può limitarlo con un’allowlist di server MCP: le sessioni regolate dal profilo possono usare solo i server elencati.
L’accesso MCP è gestito indipendentemente dalla policy di rete: non è necessario aggiungere l’indirizzo di un server MCP all’allowlist di rete. I server consentiti dal profilo sono raggiungibili automaticamente, mentre quelli esclusi dal profilo restano inutilizzabili indipendentemente dalla policy di rete.

​
Accesso a Devin MCP

Le sessioni hanno anche accesso agli strumenti di gestione di Devin tramite il Devin MCP integrato: creazione e invio di messaggi alle sessioni figlie, modifica di Knowledge e dei playbook, gestione delle pianificazioni e così via. Un profilo può limitare questo ambito con Devin MCP sola lettura: le sessioni soggette al profilo possono comunque leggere le risorse di Devin (elencare le sessioni, consultare Knowledge, esaminare i playbook), ma non possono eseguire operazioni di scrittura come creare sessioni o modificare Knowledge.

​
Livello di accesso Git

Controlla cosa può fare la sessione con i repository collegati:

​
Token GitHub CLI

Oltre alle operazioni git di base consentite dal livello di accesso git, la macchina di Devin può includere un token GitHub CLI (gh) che consente a Devin di utilizzare direttamente le funzionalità di GitHub tramite l’API GitHub. Un profilo può rimuovere il token GitHub CLI dalla macchina: le sessioni gestite dal profilo continuano a usare i tuoi repository tramite l’integrazione git di Devin, ma non possono effettuare chiamate dirette all’API GitHub. Un profilo può mantenere il token solo se concede anche l’accesso git Completo e, se imposta una policy di rete, consente api.github.com. Entrambe le condizioni vengono verificate quando salvi il profilo.

​
Dove si trovano i profili

I profili sono disponibili in due ambiti:
  • I profili dell’organizzazione vengono creati in Settings → Personalizzazione → Profili di sicurezza e possono essere usati solo all’interno di quell’organizzazione.
  • I profili Enterprise (solo per gli account Enterprise) vengono creati in Enterprise settings → Devin → Profili di sicurezza e possono essere usati da tutte le organizzazioni dell’enterprise. Le organizzazioni possono selezionare un profilo Enterprise per le proprie sessioni, automazioni o l’org default, ma solo gli amministratori Enterprise possono modificare il profilo stesso.
I nomi dei profili devono essere univoci nel rispettivo ambito. Ogni profilo ha anche un livello di applicazione, che determina se i livelli inferiori possono applicare un override.

​
A cosa puoi associare un profilo

Un profilo ha effetto quando viene associato a una risorsa. Le associazioni formano una gerarchia, dal livello più ampio a quello più specifico:
  1. Predefinito Enterprise — si applica alle nuove sessioni in tutte le organizzazioni dell’Enterprise.
  2. Predefinito dell’organizzazione — si applica alle nuove sessioni di quell’organizzazione.
  3. Predefinito delle automazioni — si applica alle sessioni avviate dalle automazioni in quell’organizzazione, sostituendo il predefinito dell’organizzazione per tali sessioni. Si imposta dalla stessa pagina delle impostazioni dei profili di sicurezza.
  4. Automazione — si applica alle sessioni avviate da quella specifica automazione, sostituendo il predefinito delle automazioni. Si imposta dall’Editor dell’automazione.
  5. Sessione — scelto per una singola sessione al momento della creazione (tramite il menu delle opzioni nel riquadro di avvio della sessione), oppure modificato in seguito dalle impostazioni della sessione.
A ogni livello puoi fare una di queste tre scelte:
  • Eredita (impostazione predefinita) — nessuna preferenza; decide il livello superiore.
  • Bloccare un profilo — le sessioni a questo livello usano il profilo selezionato.
  • Nessun profilo — esclusione esplicita, così le sessioni a questo livello vengono eseguite senza restrizioni anche se un livello superiore imposta un profilo predefinito consigliato.
Quando una sessione si avvia, Devin percorre la gerarchia dall’alto verso il basso: prevale l’associazione più specifica, a meno che un profilo obbligatorio a un livello superiore non imponga restrizioni (vedi sotto). Le sessioni generate da altre sessioni (sessioni figlie) seguono la stessa gerarchia della sessione padre, quindi non è possibile aggirare le restrizioni delegando il lavoro.

​
Quando le modifiche entrano in vigore

Una sessione risolve il profilo che la governa quando si avvia: alla prima creazione e ogni volta che esce dallo stato di sleep o si riavvia. Le modifiche al contenuto di un profilo o a qualsiasi associazione (un default, un blocco dell’automazione o una selezione di sessione) non si propagano automaticamente alle sessioni già in esecuzione: una sessione in esecuzione mantiene le restrizioni risolte al suo ultimo risveglio. Le modifiche entrano in vigore immediatamente per le nuove sessioni e, per quelle esistenti, alla successiva ripresa. Ogni profilo ha un livello di applicazione: Un profilo consigliato è un’impostazione predefinita, non un obbligo. Chiunque a un livello inferiore (con l’autorizzazione appropriata) può bloccare un profilo diverso o non usarne affatto uno. Usa i profili consigliati per offrire ai team un punto di partenza sensato, mantenendo la flessibilità.

​
Obbligatorio

Un profilo obbligatorio è una soglia minima da cui i livelli inferiori non possono sottrarsi:
  • La disattivazione non ha effetto. Una selezione “nessun profilo” al di sotto di un profilo obbligatorio viene ignorata.
  • Le selezioni dei livelli inferiori possono solo rendere più restrittivo, mai allentare. Se un livello inferiore blocca un altro profilo, i due vengono intersecati:
    • Le allowlist di rete si restringono alle destinazioni consentite da entrambi i profili.
    • Le allowlist MCP si restringono ai server consentiti da entrambi.
    • L’accesso a Git assume il minimo (la sola lettura prevale sull’accesso completo).
    • L’accesso a Devin MCP è in sola lettura se anche uno solo dei due profili la imposta.
    • Il token della GitHub CLI viene rimosso se anche uno solo dei due profili lo rimuove.
  • Le modifiche a sessione in corso vengono limitate. L’accesso di rete concesso durante una sessione (ad es. approvando la richiesta di Devin per un nuovo dominio) viene intersecato con la policy del profilo obbligatorio, quindi a una sessione non può mai essere concesso un accesso superiore a quello consentito dal profilo obbligatorio.
Ad esempio, un account Enterprise può associare un profilo obbligatorio con una policy di rete che consente *.internal.example.com come impostazione predefinita Enterprise. Le organizzazioni possono quindi sovrapporre i propri profili per limitare ulteriormente team o flussi di lavoro specifici, ma nessuna organizzazione, automazione o sessione può ampliare l’accesso oltre la policy Enterprise.

​
Autorizzazioni e governance

La gestione dei profili è regolata da un’autorizzazione dedicata, Gestire i profili di sicurezza, separata dalla gestione generale delle impostazioni. Esiste a due livelli, ciascuno assegnato in modo indipendente: Entrambi i livelli dell’autorizzazione possono essere concessi ai ruoli personalizzati, così puoi delegare la gestione delle policy di sicurezza (per esempio, a un team di sicurezza) senza concedere privilegi di amministratore completi. I membri senza questa autorizzazione non possono visualizzare l’elenco dei profili, selezionarli o modificarli: le loro sessioni seguono semplicemente il valore predefinito determinato dal sistema, ma chiunque può vedere se la propria sessione è regolata da un profilo e quale accesso di rete ha.

​
Configurazione dei profili di sicurezza

  1. Crea un profilo. Vai a Settings → Customization → Security profiles (oppure Enterprise settings → Devin → Security profiles per un profilo valido a livello Enterprise), crea un profilo e configurane le impostazioni di sicurezza e il livello di applicazione.
  2. Imposta un predefinito. Associa il profilo come predefinito per la tua organizzazione (o come predefinito Enterprise) in modo che le nuove sessioni lo adottino automaticamente.
  3. Bloccalo dove necessario. Applica un override del predefinito ad automazioni specifiche — per esempio, un profilo più restrittivo per un’automazione che interagisce con sistemi sensibili — oppure a singole sessioni al momento della creazione.
  4. Rafforza gradualmente. Inizia con un profilo consigliato per osservarne l’impatto, poi rendilo obbligatorio quando le allowlist coprono le esigenze legittime dei tuoi team.

​
Automazioni e profili

Le automazioni possono avere una propria policy di rete e selezione MCP. Si tratta di livelli esclusivamente restrittivi rispetto al profilo di riferimento: le sessioni avviate dall’automazione possono accedere solo alle destinazioni di rete e ai server MCP consentiti da entrambi, automazione e profilo. Un’automazione non può quindi mai ampliare l’accesso del profilo. Il livello dell’automazione viene risolto in tempo reale a ogni avvio e risveglio della sessione, pertanto le modifiche alla policy di rete di un’automazione hanno effetto senza dover ricreare le relative sessioni.

​
Outposts e profili

Le sessioni eseguite su Devin Outposts determinano il profilo applicabile tramite la stessa catena di associazione delle sessioni cloud e le restrizioni applicate da Devin dal proprio cloud — l’allowlist MCP, Devin MCP in sola lettura, il livello di accesso Git e la rimozione del token della GitHub CLI — si applicano alle sessioni outpost esattamente come alle sessioni cloud. La policy di rete è diversa. Devin applica l’allowlist di rete di una sessione a livello di macchina sulle VM gestite da Devin, ma un outpost worker viene eseguito sull’infrastruttura da voi gestita, quindi Devin non installa regole firewall sulle vostre macchine. La policy di rete effettiva di ogni sessione in coda viene invece pubblicata nel vostro orchestrator tramite l’API Outposts come spec.network_policy (se la policy è abilitata, nonché gli hostname e i CIDR consentiti). La sua applicazione — ad esempio tramite un proxy di uscita per sessione, una NetworkPolicy Kubernetes o regole firewall della VM — è responsabilità dell’operatore dell’outpost. Devin continua a vedere l’allowlist e a richiedere l’accesso alle destinazioni mancanti come di consueto, ma l’approvazione di una richiesta aggiorna solo la policy della sessione in Devin; non modifica di per sé la vostra rete. spec.network_policy viene acquisito quando la sessione viene accodata a un outpost e aggiornato quando viene nuovamente accodata (ad esempio dopo che la sessione entra in sospensione e si riattiva), quindi rileggetelo dall’API anziché presumere che sia statico.
Se fate affidamento sulla policy di rete di un profilo obbligatorio come limite rigido, assicuratevi che la vostra infrastruttura outpost applichi spec.network_policy per ogni sessione che esegue. In caso contrario, le sessioni sugli outpost avranno lo stesso accesso di rete delle vostre macchine.