I guardrail che la piattaforma impone già da sé
Il primo errore di chi progetta controlli sugli agenti è ricostruire barriere che esistono già. Sul cloud agent di Copilot — quello che gira su GitHub, apre un branch e lascia una pull request in bozza — la piattaforma impone da sé un perimetro che non devi negoziare. Solo chi ha accesso in scrittura al repository può metterlo al lavoro: non è una superficie esposta a chiunque passi da un issue. L’agente ha la possibilità di pushare su un solo branch, non sul branch predefinito, e non esegue comandi git arbitrari. Non può marcare la propria pull request come Ready for review, non può approvarla e non può fare merge: la revisione e l’unione restano di una persona. È inoltre soggetto ai rulesets esattamente come uno sviluppatore umano, quindi le protezioni che hai già scritto per gli umani valgono anche per lui senza duplicazioni.
Il controllo più sottovalutato riguarda la CI. Per impostazione predefinita i workflow non partono sulla pull request dell’agente finché il codice non è stato guardato e una persona con accesso in scrittura non premette Approve and run workflows. E chi ha chiesto all’agente di creare quella pull request non può poi approvarla: la separazione fra chi commissiona e chi valida è cablata nel prodotto. Anche l’uscita verso la rete è chiusa in partenza: l’accesso a Internet dell’agente è limitato da un firewall, con l’impostazione Enable firewall (valori Enabled, Disabled, Let repositories decide) e una Recommended allowlist già attiva per registri di pacchetti e autorità di certificazione. Disattivare il firewall permette all’agente di connettersi a qualsiasi host e aumenta il rischio di esfiltrazione di codice: è una scelta da motivare, non un default da toccare.
Quello che tocca a te aggiungere
Il buco che la piattaforma non chiude è la mutabilità delle regole. Un agente che può modificare i file da cui prende le proprie istruzioni non ha regole: le riscrive. Il presidio è CODEOWNERS sui file che codificano le decisioni — istruzioni personalizzate, configurazione degli agenti e dei server MCP — insieme alla regola Require review from Code Owners. Così una modifica alle regole richiede l’occhio di chi le possiede, mentre una modifica al codice applicativo resta veloce.
Il secondo presidio è la superficie delle credenziali. Al cloud agent arrivano soltanto gli Agents secrets and variables, configurabili a livello di repository o di organizzazione: l’agente non ha accesso ai secret e alle variabili di GitHub Actions, Codespaces o Dependabot. È una separazione preziosa, perché ti permette di dare all’agente un sottoinsieme minimo di credenziali senza toccare quelle della pipeline. I nomi non possono iniziare con il prefisso GITHUB_, e per essere consumati da un server MCP devono iniziare con COPILOT_MCP_. Sui server MCP, poi, l’agente non ha accesso agli strumenti di scrittura per impostazione predefinita, e la raccomandazione è dichiarare nel campo tools solo gli strumenti che servono davvero.
Minimo privilegio sulle superfici locale e programmatica
Le altre tre superfici hanno leve diverse, e confonderle è l’errore che l’esame punisce più duramente. Nella Copilot CLI il privilegio si stringe sui tool e sui percorsi: --available-tools disabilita tutto tranne ciò che elenchi, --excluded-tools toglie solo i tool indicati, --allow-tool e --deny-tool decidono senza chiedere. La regola da ricordare è che le regole di deny vincono sempre su quelle di allow, anche con --allow-all (alias --yolo) attivo. In sessione /reset-allowed-tools revoca i permessi concessi. Il sandbox locale lavora su un altro asse: nega per default, concede in modo esplicito, e /sandbox policy stampa la politica effettiva nella directory corrente.
Nel Copilot SDK il controllo diventa codice: l’hook onPreToolUse intercetta ogni chiamata a un tool e restituisce una decisione fra allow, deny e ask, con una motivazione mostrata all’utente. È qui che si traduce una policy di sicurezza o di Responsible AI in un blocco effettivo.
{
"permissionDecision": "deny",
"permissionDecisionReason": "Le migrazioni del database passano solo dalla pipeline approvata"
}Nei GitHub Agentic Workflows il Markdown viene compilato con gh aw compile in un file .lock.yml irrigidito che gira in Actions: i permessi sono in sola lettura se non li concedi nel blocco permissions del frontmatter, i container sono firewallati e le operazioni di scrittura passano soltanto dai safe-outputs dichiarati.
Togliere le approvazioni che non riducono il rischio
Ogni approvazione costa tempo, quindi va spesa dove cambia l’esito. Le automazioni del cloud agent offrono livelli di confidenza — Full control, Cautious (predefinito), Balanced, Full automation — che ti permettono di far scorrere i cambiamenti chiari e trattenere solo gli ambigui. Il punto che l’esame verifica volentieri è che quel pannello di accettazione non è un controllo di sicurezza: un agente con il permesso di modificare gli issue può aggirarlo via API. Il controllo vero sta nei permessi e nei contesti di esecuzione, non nella schermata di conferma.
Sul piano enterprise ci sono due policy dedicate — bloccare il cloud agent e la code review in tutti i repository posseduti dall’enterprise — che valgono anche per chi accede con un piano personale o da un’altra enterprise, a differenza delle policy Copilot ordinarie. La precedenza fra impostazioni gestite va da MDM-managed a server-managed a file-based fino alle impostazioni utente, con un’eccezione da memorizzare: la chiave sandbox non segue la precedenza, si combina nella direzione più restrittiva. Una baseline di sandbox dell’enterprise non può essere allentata da un’impostazione locale.