Da copilot a collega: cosa significa quando l'AI opera in autonomia

Uno sguardo fondato sulla ricerca al passaggio dai motori di suggerimenti ai compagni di lavoro autonomi. Perché sta accadendo ora, cosa si rompe nella transizione e come fare deployment senza consegnare le chiavi del regno.

L'era del copilot sta raggiungendo un plateau

Il 15 aprile 2026, Sam Altman ha pubblicato su X che OpenAI stava distribuendo "aggiornamenti di Codex questa settimana focalizzati su team e grandi aziende".

Le risposte erano rivelatrici. Per ogni sviluppatore che chiedeva della roadmap, ce n'era un altro che poneva una domanda più difficile: perché Codex ha ancora bisogno che io lo controlli a vista? Sei mesi prima, i ricercatori di BeyondTrust avevano pubblicato un proof-of-concept che mostrava come il nome di un branch Git appositamente costruito potesse ingannare Codex e indurlo a esfiltrare il token GitHub dell'utente. Un copilot che può essere ingannato per far trapelare un token attraverso il nome di un branch non è un collega. È un'arma carica con la sicura.

Quella tensione è alla base di ogni conversazione enterprise sull'AI nel 2026. I copilot hanno raggiunto il loro tetto, e i numeri lo dicono:

L'iniziativa NANDA del MIT ha riportato nel 2025 che il 95% dei progetti pilota di AI generativa non riesce a produrre valore di business misurabile.
Uno studio di RAND, citato ripetutamente nel subreddit r/ArtificialIntelligence all'inizio del 2026, ha rilevato che l'80-90% dei progetti di agenti AI fallisce negli ambienti di produzione.
I tassi di accettazione degli sviluppatori per GitHub Copilot si sono appiattiti intorno al 35-40%, mentre Cursor si attesta al 42-45% e Claude Code ha ottenuto una valutazione del 46% come "più amato" nel sondaggio 2026 sull'AI per il coding. Un'inversione sbalorditiva per uno strumento lanciato solo a maggio 2025.
Si dice che Satya Nadella abbia definito il rollout interno di Copilot di Microsoft "quasi inutilizzabile" a fine 2025, e l'azienda ha annunciato quello che i dirigenti hanno descritto internamente come un "reset ad alta posta in gioco" del prodotto.
Uno studio su arXiv pubblicato a fine 2025 ha rilevato che l'autocompletamento in stile Copilot in realtà aumentava la frustrazione tra gli sviluppatori esperti, perché ne interrompeva il flusso con suggerimenti plausibili ma sottilmente errati.

Il plateau non è un fallimento dei modelli sottostanti. È un fallimento del pattern di interazione. Un copilot opera al livello del singolo tasto premuto o della singola domanda. Un collega opera al livello del workflow. Bits&Chips lo ha inquadrato bene nel suo saggio di aprile 2026 "From copilot to colleague": "Un copilot opera al livello della singola interazione, mentre un agente opera al livello del workflow. Il che conta, perché nella maggior parte delle organizzazioni il collo di bottiglia non è il singolo compito. È il coordinamento tra i compiti."

È questo il passaggio che le aziende stanno cercando di compiere ora. In modo disomogeneo, imperfetto e su scala significativa.

Lo spettro dell'autonomia

"Agente" è diventata una parola da marketing, quindi rendiamola concreta. Esistono quattro livelli distinti di autonomia dell'AI, e gran parte della delusione del 2025 e del 2026 è nata dal confondere l'uno con l'altro.

Livello 1: copilot

Suggerisce. Chiede il permesso. Resta sul tuo schermo. L'autocompletamento di GitHub Copilot è l'archetipo. Il valore si misura in tasti risparmiati.

Livello 2: assistente

Risponde alle domande e compone artefatti su richiesta. ChatGPT, Claude in un browser, il pannello chat di Microsoft 365 Copilot. Il valore si misura nella qualità delle bozze e nella sintesi del contesto.

Livello 3: agente

Accetta un obiettivo, pianifica una sequenza di passaggi, esegue attraverso gli strumenti e riferisce. Claude Code che scansiona un repository e apre una PR. La Deep Research di ChatGPT che esegue 20 minuti di ricerche e restituisce un report con citazioni. Anthropic ha documentato un'istanza di Claude che ha completato un compito di ingegneria autonomo di 7 ore per Rakuten. Il valore si misura nei workflow completati per ora umana spesa.

Livello 4: collega

Un agente che opera all'interno del tuo modello di permessi esistente, partecipa ai canali di comunicazione del tuo team, mantiene il contesto attraverso giorni e settimane ed è responsabile davanti allo stesso audit trail di un dipendente umano. Questa è la frontiera.

La community r/ChatGPT di Reddit ha fatto emergere un test pragmatico per distinguere questi livelli, parafrasato: la cosa prende l'iniziativa, o aspetta ogni istruzione? Gestisce le situazioni impreviste, o va in crash e ti costringe a re-istruirla? Ricorda il contesto attraverso un compito multi-step, o devi ripeterti? La maggior parte dei prodotti commercializzati come "agenti AI" nel 2025 falliva ognuna di quelle domande. Quelli che le superavano sono ciò che le persone intendono ora quando dicono "collega".

Computer use vs skill: perché l'idraulica conta

Un'AI di livello collega ha bisogno di agire nel mondo. Ci sono due approcci architetturali a questo, e portano profili di rischio molto diversi.

Computer use

L'AI guida un mouse e una tastiera simulati. Vede letteralmente uno schermo e clicca i pulsanti. Anthropic ha rilasciato Computer Use a fine 2024, e Operator di OpenAI è seguito. L'attrattiva è l'universalità: qualsiasi software con una GUI diventa indirizzabile.

Il costo è il raggio d'azione del danno. Un agente che usa il computer eredita ogni permesso che ha l'utente connesso. A ottobre 2025, il team di sicurezza di BeyondTrust ha dimostrato che l'agente Codex di OpenAI poteva essere ingannato, tramite il nome di un branch Git malevolo contenente comandi di shell, e indotto a leggere ed esfiltrare il GITHUB_TOKEN dell'utente. L'agente faceva esattamente ciò che farebbe uno sviluppatore umano (effettuare il checkout di un branch), ma non aveva alcuna intuizione che il nome del branch stesso fosse un input ostile. In quell'incidente il modello di autorità era tutto-o-niente. Questa è la modalità di fallimento predefinita del computer use.

Skill

L'AI invoca skill discrete. Ogni skill è una funzione esplicita e tipizzata con un contratto stretto: "cerca su Slack i messaggi che corrispondono a q", "crea una issue su Linear con title e body", "leggi questo file GitHub". A differenza del computer use, una skill ha una forma pre-approvata. L'agente può chiamarla solo con parametri che corrispondono al contratto, e la piattaforma può consentire, negare o chiedere conferma su quella chiamata prima che lasci il sandbox.

La differenza, in termini di sicurezza, si riduce al Principio del Minimo Privilegio. È un'idea fondamentale nella sicurezza informatica: un processo dovrebbe avere accesso solo alle risorse di cui ha bisogno per svolgere la sua funzione, e niente di più. Le skill ti permettono di imporre il minimo privilegio per ogni chiamata. Il computer use no.

Un deployment di livello collega usa le skill per le azioni strutturate (scrivere su un CRM, aprire un ticket), e riserva il computer use alla ristretta coda di applicazioni che si rifiutano di esporre un'API. Il rapporto conta. Se ogni azione nel tuo deployment di agenti passa attraverso un mouse simulato, hai una demo di produttività, non un sistema di produzione.

L'architettura di fiducia di cui le aziende hanno davvero bisogno

Il passaggio dal copilot al collega non è un upgrade del modello. È un upgrade dell'infrastruttura. Tre elementi separano un collega distribuibile da una passività.

1. Isolamento dei permessi

Ogni agente opera all'interno del proprio confine di permessi, con credenziali che l'agente stesso non può estrarre dal suo sandbox. L'esperimento virale autoresearch di Andrej Karpathy del marzo 2026, in cui ha lasciato un agente eseguire 700 esperimenti di training senza supervisione nell'arco di due giorni, è istruttivo per ciò che non ha fatto. Il repo di Karpathy stesso istruisce gli utenti a "disabilitare tutti i permessi" in modalità autonoma. Va bene per un laptop di ricerca personale. È un motivo di licenziamento dentro un'azienda regolamentata.

Il contro-esempio è Moltbook, il social network solo-AI che è brevemente diventato virale a fine gennaio 2026 con 1,5 milioni di agenti autonomi. Karpathy lo ha elogiato come "la cosa più incredibile, vicina a un decollo da fantascienza, che abbia visto di recente". Poi i ricercatori di sicurezza di Wiz hanno scoperto una chiave API del database esposta sul front-end, che concedeva pieno accesso in lettura/scrittura all'intero database di produzione, inclusi i token di autenticazione di tutti gli 1,5 milioni di agenti. Karpathy ha cambiato rotta entro 24 ore: "È un disastro completo. Sconsiglio decisamente alle persone di eseguire questa roba sui loro computer." La lezione non è "gli agenti sono pericolosi". La lezione è che gli agenti distribuiti senza isolamento dei permessi per identità collassano in un unico raggio d'azione condiviso del danno.

2. Audit trail

Ogni azione registrata, ogni decisione tracciabile. Il framework dell'IMDA di Singapore, presentato a Davos a gennaio 2026, codifica questo con una matrice di rischio a due assi che mappa lo spazio d'azione di un agente (lettura vs scrittura, reversibile vs irreversibile) rispetto alla sua autonomia (quanto indipendentemente decide). Più alto sale uno qualsiasi dei due assi, più ricco è il requisito di audit. Questo framework è studiato da vicino dai regolatori europei e statunitensi perché è uno dei primi a tradurre la governance da principi astratti in uno strumento operativo di calibrazione.

Simon Willison ha argomentato in parallelo a favore del logging unificato in modo che gli agenti possano monitorare le proprie operazioni e recuperare dagli errori: "Gli agenti con pieno accesso al sistema sono potenti, e pericolosi." Il punto pratico: se il tuo deployment di agenti non ha un log unificato che un responsabile della compliance possa leggere in ordine, sei esattamente a un incidente di distanza dal perdere il privilegio di fare deployment.

3. Accesso delimitato alle skill

Non "accesso all'email". Accesso a cerca nella inbox dove from:@cliente.com AND negli ultimi 7 giorni. Le moderne piattaforme di agenti si stanno muovendo verso ambiti parametrizzati, dove il permesso di un agente di invocare una skill è delimitato da argomenti che un amministratore pre-approva, non dal grezzo ambito OAuth che userebbe l'umano.

Metti insieme questi tre pezzi e rispondono alla domanda che ogni CISO si sta ponendo proprio ora: cosa fa questo agente quando sbaglia, e come lo saprò? Il sondaggio State of AI di McKinsey del 2026 ha rilevato che il 72% dei rispondenti enterprise ha citato la cybersicurezza come una preoccupazione con l'AI generativa, e la sicurezza è stata indicata come la barriera n.1 alla scalabilità dei workflow agentici da circa due terzi dei rispondenti. Isolamento dei permessi, audit trail e accesso delimitato alle skill non sono teatro della compliance. Sono l'infrastruttura abilitante.

Perché conta ora: tre forze che convergono

Il passaggio dal copilot al collega nel 2026 non è guidato da una singola svolta. È il risultato dell'intersezione di tre curve.

Forza 1: l'integrazione ha smesso di essere su misura

Nel 2024, collegare un agente a uno stack SaaS aziendale significava scrivere un connettore personalizzato per ogni strumento. All'inizio del 2026, i contratti di skill tipizzati e i connettori preconfezionati hanno azzerato quel lavoro. Un agente che nel 2024 richiedeva sei settimane di integrazione nel 2026 richiede un pomeriggio. La superficie di una tipica azienda mid-market (Slack, GitHub, Gmail, Linear, Notion, HubSpot, CRM, calendari) è ora coperta da librerie di connettori open-source mature, che arrivano con i permessi tipizzati già integrati.

Forza 2: il multi-agente diventa reale

Gartner ha nominato i Sistemi Multi-Agente come uno dei principali trend tecnologici strategici per il 2026. Il Distinguished VP Analyst Gene Alvarez ha offerto la metafora che ora viene ripetuta in ogni slide aziendale sull'AI: "Pensate a un team ai box della Formula 1. Ogni membro ha un ruolo specializzato (chi cambia le gomme, chi rifornisce, chi manovra il cric) ma sono coreografati attorno a un unico obiettivo. È questa la forma dei deployment di agenti aziendali nel 2026." I sistemi a singolo agente raggiungono tetti di ragionamento sui compiti a lungo orizzonte. I sistemi multi-agente, con ruoli specializzati e passaggi di consegne espliciti, sono il modo in cui i team aggirano oggi quei tetti.

Forza 3: i budget enterprise si sbloccano

G2 ha riportato nella sua ricerca State of Software 2026 che il 57% delle aziende ha agenti AI in produzione (in aumento da circa il 20% un anno prima).
McKinsey ha rilevato che il 23% delle aziende sta attivamente scalando l'AI agentica, con il 62% in fase di sperimentazione. Resta solo circa il 15% delle grandi organizzazioni ancora a bordo campo.
Il sondaggio 2026 di Deloitte su 3.235 leader aziendali ha individuato i servizi finanziari come il principale early adopter, con un caso di studio documentato di un agente AI che catturava e agiva sugli esiti delle riunioni attraverso una pipeline di trattative che in precedenza richiedeva tre analisti.
L'Enterprise AI Playbook di Stanford, pubblicato all'inizio del 2026, ha catalogato 51 deployment di produzione, con un caso di migrazione ETL nel fintech diventato l'implementazione di riferimento per i team dei settori regolamentati.
Gli investimenti enterprise dichiarati nell'infrastruttura AI hanno superato i 600 miliardi di dollari nel ciclo 2025.
Dario Amodei di Anthropic, parlando alla conferenza Code with Claude, ha indicato una probabilità del 70-80% dell'emergere nel 2026 della prima azienda da un miliardo di dollari gestita da una sola persona, alimentata da forze lavoro di agenti.

I soldi ci sono, il protocollo c'è e l'architettura c'è. Ciò che si sta negoziando ora in ogni sala del consiglio è quanta autonomia, sotto quale governance e per quali workflow.

Le ragioni dello scettico: cosa dicono Reddit, arXiv e i report sugli incidenti

Uno sguardo responsabile a questo cambiamento deve confrontarsi seriamente con chi pensa che l'intera faccenda sia sopravvalutata.

Su Reddit, il consenso tra r/LocalLLaMA, r/ClaudeCode e r/ChatGPT è pragmatico: gli agenti di coding sono arrivati e sono utili. La maggior parte degli altri "agenti" sono workflow di automazione travestiti da chatbot. La frase citata in decine di thread del 2026, "Usa Copilot quando vuoi suggerimenti. Usa Claude Code o Cursor quando vuoi che faccia davvero qualcosa," cattura la divisione produttiva. Quelle stesse community sono spietate sui benchmark. Persino i migliori agenti totalizzano circa il 60% complessivo su Terminal-Bench e scendono al 16% sui compiti difficili. Claude Opus 4.5 guida SWE-bench all'80,9%, il che significa comunque che un compito su cinque fallisce.

Lo scetticismo accademico è più difficile da scrollarsi di dosso. Vishal Sikka (ex CTO di SAP, allievo di John McCarthy) e il suo collaboratore hanno pubblicato Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models, sostenendo matematicamente che gli LLM transformer sono fondamentalmente limitati nella loro capacità di eseguire compiti computazionali e agentici oltre un certo tetto di complessità. La conclusione di Sikka, "Non c'è modo che possano essere affidabili" per operazioni altamente critiche, sta circolando proprio ora in ogni Slack di CISO. Il paper non afferma che gli agenti siano inutili. Afferma che esiste una classe di problemi in cui non puoi togliere l'umano dal ciclo, per quanto buono diventi il modello.

Incidenti reali sostengono lo scetticismo. Un responsabile della customer experience nel retail, citato nel sondaggio 2026 di Yellow.ai: "Abbiamo dovuto ritirare il nostro supporto AI dopo solo due settimane, perché ha iniziato a citare politiche di reso errate e a inventare offerte di sconto in circa l'1,35% dei ticket. Il costo di onorare quegli errori era di gran lunga superiore a ciò che speravamo di risparmiare." Su larga scala, persino un tasso di errore inferiore al 2% diventa rapidamente costoso.

La sintesi: l'AI di livello collega è reale nel coding, nella ricerca, nelle operazioni strutturate e nei workflow di supporto ristretti. Non è ancora reale nelle interazioni aperte a contatto col cliente senza un revisore umano. Le aziende che ottengono valore nel 2026 sono quelle oneste su quale categoria appartenga un workflow.

Implicazione pratica: cinque domande prima del deployment

Se il tuo team sta valutando un compagno di team AI (costruito internamente o di terze parti), queste sono le domande che separano un deployment di produzione da una quasi-catastrofe.

Qual è il raggio d'azione del danno della peggiore singola azione che questo agente può compiere? Mappalo letteralmente. Se il caso peggiore è "invia un'email abbozzata alla persona sbagliata", l'asticella della governance è bassa. Se è "modifica i dati di produzione" o "invia istruzioni per un bonifico", l'asticella è di un ordine di grandezza più alta. Mappalo prima del deployment, non dopo il primo incidente.
Come ottiene l'agente le sue credenziali, e può mai leggere il token grezzo? Ci sono tre risposte, e solo una è sicura. Se l'agente ha una copia del token OAuth dell'utente nel suo ambiente, hai di fatto dato il tuo portafoglio all'LLM. Se l'agente ha una "propria" identità tramite un OAuth da service-account separato, devi tracciarlo e revocarlo come un vero principal. La terza risposta, che è ciò che vuoi davvero: il token non raggiunge mai l'agente. Vive sulla piattaforma, cifrato, e viene iniettato a livello di network-proxy esattamente al momento giusto, solo per le chiamate che hanno superato un controllo di policy, solo finché la chiamata non restituisce un risultato.
Ogni azione è registrata da qualche parte dove un responsabile della compliance possa leggerla in ordine? Unificato, interrogabile, a prova di manomissione. Se la tua risposta è "abbiamo alcuni log da qualche parte in CloudWatch", non sei pronto.
Puoi delimitare l'accesso alle skill ai parametri specifici di cui questo workflow ha bisogno? Per ogni chiamata, non per integrazione. Lettura vs scrittura. Per ID di risorsa. Per finestra temporale. I permessi dell'agente dovrebbero essere un rettangolo disegnato strettamente attorno al lavoro, non l'intero magazzino.
Qual è la strategia di rollback se qualcosa va storto? Come inverti un'azione? Quanto velocemente? Chi viene allertato? Le azioni irreversibili (trasferimenti di denaro, email a contatto col cliente, deploy in produzione) hanno bisogno di un passaggio di conferma o di una finestra di ritardo. Quelle reversibili possono girare in autonomia.

Lavora sulle cinque. Se riesci a rispondere a tutte, sei già oltre l'era del copilot e dentro la parte che cambia davvero il modo in cui il tuo team rilascia. Se riesci a rispondere a due o tre, è lì che concentrarsi dopo, non un motivo per aspettare. Il compagno di team di livello collega a cui la tua roadmap sta puntando sta girando in produzione da qualche parte oggi. Il divario tra te e lui è un divario di infrastruttura, non un divario di AI di frontiera. E i divari di infrastruttura si colmano in fretta.

Non devi aspettare il prossimo rilascio di un modello. Devi scegliere una piattaforma che risponda già a queste cinque domande per te, e iniziare a dare al tuo agente lavoro vero.

Domande frequenti

Qual è la vera differenza tra un copilot e un collega AI?

Un copilot suggerisce, chiede il permesso e vive dentro un singolo strumento. Un collega accetta obiettivi, pianifica attraverso i sistemi, esegue con permessi delimitati ed è responsabile davanti allo stesso audit trail di un umano. Bits&Chips l'ha detto con chiarezza: i copilot operano al livello dell'interazione, i colleghi operano al livello del workflow.

Come dovrebbero gestire gli agenti le credenziali degli utenti?

Nessuna delle due opzioni ovvie è giusta. Copiare il token OAuth dell'utente nell'ambiente dell'agente mette una credenziale viva dentro il contesto dell'LLM. Coniare un'identità separata per ogni agente trasforma ogni agente in un principal che devi tracciare, revocare e sottoporre ad audit come un umano. Il pattern che funziona nella pratica è l'accesso intermediato: il token vive sulla piattaforma, cifrato; il network proxy in uscita del sandbox richiama la piattaforma al momento della richiesta; la piattaforma decifra il token e restituisce solo gli header di autenticazione risolti per le chiamate che hanno superato un controllo di policy; l'agente stesso non legge, registra né chiede mai conferma sul token grezzo.

Computer use o skill, quale dovremmo scegliere?

Skill come opzione predefinita, per qualsiasi cosa abbia un'API. Computer use solo quando il sistema target non ha un'interfaccia programmabile. L'incidente Codex di BeyondTrust è il monito: il computer use eredita i permessi completi dell'utente, e un input malevolo in qualsiasi punto del campo visivo dell'agente può diventare un exploit.

Quanto autonomamente dovremmo davvero far girare gli agenti?

Usa l'inquadramento a due assi dell'IMDA di Singapore: spazio d'azione × autonomia. Uno spazio d'azione ristretto (sola lettura, reversibile) tollera un'alta autonomia. Uno spazio d'azione ampio (scritture, irreversibile, a contatto col cliente) richiede conferma umana, o una finestra a ritardo temporale per intervenire. La configurazione peggiore è alta autonomia su azioni ad alta posta in gioco senza audit trail.

Come misuriamo il ROI?

Smetti di misurare i tasti risparmiati. Misura i workflow completati per ora umana spesa, il tempo di risoluzione degli incidenti operativi e il tasso di escape (compiti che l'agente ha restituito a un umano). I risultati 2026 di Deloitte suggeriscono che i principali early adopter tracciano tre metriche: tasso di completamento dei workflow, tasso di errore e tasso di intervento umano, ottimizzando il rapporto tra di esse.

Cosa facciamo riguardo al tasso di fallimento del 95% dei progetti pilota?

Leggi attentamente l'analisi di NANDA del MIT. I pilota falliti giravano per lo più su "Dumb RAG" (riversare tutto nel contesto), "Brittle Connectors" (integrazioni API rotte) e nessuna architettura event-driven. I pilota che hanno avuto successo avevano uno strato operativo attorno all'LLM: memoria, I/O e permessi. Il kernel dell'LLM non è il collo di bottiglia. L'infrastruttura circostante lo è.

Dove si colloca VM0

Abbiamo costruito Zero attorno a una scommessa architetturale: l'agente non dovrebbe mai detenere la credenziale. Non nel suo ambiente, non nel suo prompt, non nella sua memoria. Il token resta sulla piattaforma. Ogni chiamata in uscita che l'agente effettua è intermediata da un network proxy che decide, per ogni chiamata, se iniettare un header di autenticazione o bloccare la richiesta.

È una scelta insolita. I pattern comuni nel 2026 sono o dare all'agente una propria identità OAuth (ora hai un secondo principal da sottoporre ad audit e revocare) o consegnargli una copia del token dell'utente in una variabile d'ambiente (ora l'LLM può leggere il tuo portafoglio). Noi non facciamo né l'uno né l'altro. Ecco come funziona davvero.

Il token non raggiunge mai l'agente. Quando colleghi un connettore a Zero (GitHub, Slack, Gmail, Linear, Notion, HubSpot e così via), il token OAuth viene archiviato cifrato sulla piattaforma. I refresh token restano nel database e non lo lasciano mai. Dentro il sandbox, non c'è alcuna variabile d'ambiente GITHUB_TOKEN da leggere, nessun file di segreti da aprire, nessuno strumento che restituisca il token.

Un network proxy intermedia ogni chiamata. Ogni richiesta HTTP che lascia il sandbox passa attraverso un addon basato su mitmproxy. Il proxy identifica il connettore dall'hostname della richiesta, cerca la policy del firewall per quell'agente e verifica se la coppia metodo-e-percorso è consentita. Se lo è, il proxy richiama il webhook della piattaforma. La piattaforma decifra il token, lo aggiorna se è scaduto, risolve eventuali template di header (${{ secrets.GITHUB_TOKEN }} diventa il valore reale) e restituisce al proxy solo gli header di autenticazione risolti. Il proxy inietta quegli header nella richiesta in uscita. Quando la chiamata si completa, gli header spariscono dalla memoria del proxy. L'agente non li ha mai visti.

I permessi sono per agente, per connettore e tipizzati a livello di endpoint. Ogni agente porta un oggetto policy che mappa ciascun connettore a un insieme di gruppi di permessi nominati. github:repo-read non è un ambito vago. È un fascio di regole specifiche metodo-e-percorso, per esempio GET /repos/{owner}/{repo}/pulls. Concedere l'accesso a GitHub non concede GitHub. Concede una forma di intenzione dentro GitHub.

Tre stati di policy, non due. Ogni permesso si risolve in allow, deny o ask. L'ultimo chiede conferma a un umano prima che l'azione parta. Qualsiasi cosa che il firewall non corrisponda esplicitamente ricade in un unknownPolicy per connettore, che ha come valore predefinito deny. Il minimo privilegio è il default, non l'opzione da attivare.

Un sandbox per esecuzione. Ogni esecuzione di un agente gira dentro la propria microVM Firecracker con un namespace di rete isolato. Quando l'esecuzione termina, il namespace viene smantellato. Due esecuzioni dello stesso agente sono due sandbox separati con due audit trail separati.

Audit trail per ogni richiesta. Lo stesso proxy che decide allow/deny scrive anche un log JSONL per ogni esecuzione con i metadati del firewall allegati a ogni richiesta: il connettore, il gruppo di permessi che ha corrisposto, la regola specifica che ha corrisposto, la decisione, il timestamp. Quei log vengono inviati alla piattaforma. Se un CISO ha bisogno di sapere cosa ha fatto l'agente il 14 aprile tra le 15 e le 17 CST, è una sola query.

Una CLI che spiega i propri rifiuti. Quando un permesso blocca una chiamata, l'agente (o l'umano seduto accanto) può eseguire zero doctor permission-deny <connector> --method <M> --path <P> e ottenere in risposta l'esatto gruppo di permessi che ha bloccato la richiesta, più un link di risoluzione. zero doctor permission-change permette agli amministratori di attivare/disattivare un permesso direttamente, o permette a un membro di inviare una richiesta scritta (limitata a 500 caratteri, così la motivazione si legge davvero) che viene instradata a un amministratore. I permessi ad alto rischio come slack:chat:write o gmail.send attivano un avviso aggiuntivo che indica un'alternativa più sicura con ambito bot.

Due ruoli, un unico flusso di approvazione. Owner e amministratori cambiano i permessi direttamente. I membri inviano una richiesta con una motivazione, che viene instradata a un amministratore. Non c'è un terzo livello "semi-admin". Il flusso è abbastanza snello da far sì che le persone lo usino davvero, che è tutto il punto.

Riserviamo il computer use al ristretto insieme di sistemi legacy che si rifiutano di esporre un'API. Tutto il resto passa attraverso le skill. Ogni azione è verificata da una policy. Ogni credenziale resta sulla piattaforma. Ogni decisione è registrata.

Se sei oltre "l'ennesimo autocompletamento AI" e vuoi provare un compagno di team AI a cui il tuo team di sicurezza darà il via libera, scopri come Zero gestisce i workflow pianificati, fa il triage degli incidenti di produzione, o esegue un briefing mattutino di prodotto.

L'era del copilot non sta finendo. Sta venendo assorbita in qualcosa di più grande. I team che vinceranno il prossimo ciclo sono quelli che comprendono la differenza.