I workflow Anthropic Cursor mettono sotto pressione le impostazioni predefinite sicure e private
I workflow Anthropic Cursor affrontano ora una richiesta diretta da parte degli sviluppatori: rendere standard le protezioni per sicurezza e privacy prima che gli agenti AI ricevano ampi privilegi di accesso. La richiesta è importante perché questi strumenti non si limitano più a fornire suggerimenti. Possono leggere repository, modificare file, eseguire comandi, contattare servizi esterni e operare attraverso le credenziali di uno sviluppatore.
La copertura di The Register pone Anthropic, OpenAI, Cursor e i loro concorrenti sotto lo stesso riflettore. I loro prodotti differiscono, ma il conflitto di fondo è condiviso. I fornitori vogliono agenti in grado di agire con meno attriti, mentre gli sviluppatori hanno bisogno di limiti prevedibili sulla raccolta dei dati e sull'accesso ai sistemi.
Questa tensione è diventata più difficile da liquidare come un problema di configurazione avanzata. I ricercatori di sicurezza hanno individuato vulnerabilità che attraversano i confini degli spazi di lavoro o manipolano le approvazioni degli agenti. I fornitori hanno inoltre introdotto modalità privacy, sandbox, richieste di autorizzazione e controlli enterprise. La disputa riguarda se gli utenti debbano scoprire e attivare da soli tali protezioni.
Gli sviluppatori vogliono che le impostazioni predefinite assorbano una quota maggiore del rischio
La richiesta centrale è semplice: un agente di programmazione dovrebbe iniziare con autorizzazioni ristrette, conservazione minima dei dati e consenso esplicito per le azioni sensibili.
Questo standard sembra prudente finché non si considera l'ambiente operativo dell'agente. Un normale strumento di completamento automatico propone testo all'interno di un editor. Un agente può ispezionare più file, richiamare programmi da terminale, installare pacchetti, contattare server e modificare un progetto attraverso più passaggi.
Queste capacità rendono utile la programmazione con l'AI. Significano anche che una singola approvazione errata può autorizzare una catena di azioni che pochi utenti potrebbero prevedere in anticipo. Una finestra di autorizzazione può indicare il primo comando senza rivelare ogni conseguenza successiva.
Il rischio diventa più chiaro quando un repository contiene istruzioni ostili. Il prompt injection si verifica quando contenuti non affidabili influenzano un sistema AI inducendolo a seguire le indicazioni di un aggressore. In un workflow di programmazione, tali contenuti possono arrivare attraverso documentazione, descrizioni di issue, file sorgente, metadati dei pacchetti o strumenti connessi.
Uno sviluppatore non deve chiedere malware. L'agente potrebbe incontrare istruzioni mentre completa un'attività legittima e poi trattarle come contesto rilevante del progetto. Se dispone anche di accesso alla shell e alla rete, un documento fuorviante può trasformarsi in un percorso di esecuzione.
Una ricerca divulgata a luglio illustra perché la progettazione delle autorizzazioni è importante. La falla GhostApproval ha interessato diversi importanti assistenti alla programmazione, tra cui Claude Code e Cursor. I ricercatori hanno affermato che il modello poteva indurre gli agenti a raggiungere file esterni al loro spazio di lavoro previsto.
Amazon, Cursor e Google hanno classificato il problema segnalato come critico o ad alta gravità e hanno rilasciato correzioni o iniziato a tracciarle. Altri fornitori coinvolti hanno risposto diversamente, secondo il rapporto. Non vi erano indicazioni pubbliche che aggressori avessero sfruttato la falla in natura.
La divulgazione ha comunque evidenziato una debolezza strutturale. L'approvazione umana non garantisce la sicurezza quando l'interfaccia descrive un oggetto mentre il sistema sottostante ne raggiunge un altro. Un utente può approvare l'operazione visibile senza comprenderne la portata effettiva.
Per questo gli sviluppatori contestano l'idea che le richieste di autorizzazione trasferiscano la responsabilità alla persona che vi fa clic. Il consenso funziona solo quando è specifico, informato e collegato all'azione che avviene realmente.
Lo stesso principio si applica all'uso dei dati. Il codice sorgente può rivelare prodotti non ancora pubblicati, architettura interna, relazioni con i clienti, credenziali e controlli di sicurezza. Inviarlo a un fornitore esterno di modelli non equivale a condividere un normale messaggio di chat.
Alcune organizzazioni possono negoziare accordi enterprise o implementare controlli centralizzati. Gli sviluppatori indipendenti e i piccoli team si affidano in genere alle impostazioni per i consumatori e alla documentazione pubblica. Di conseguenza, hanno una responsabilità maggiore nell'identificare quali regole si applichino a prodotto, account e fornitore del modello.
La richiesta di impostazioni predefinite più sicure non esige che ogni agente rimanga passivo. Esige che un'autorità più ampia richieda una decisione deliberata. Questo inverte l'onere attuale: il prodotto deve meritarsi l'accesso invece di richiedere all'utente di revocarlo.
Le impostazioni sulla privacy di Anthropic Cursor dipendono ancora dal contesto
Le etichette sulla privacy possono celare diverse decisioni distinte riguardo raccolta, conservazione, addestramento dei modelli, indicizzazione e trattamento da parte di terzi.
Cursor offre una Privacy Mode che modifica il modo in cui vengono gestiti i dati dei clienti. La sua attuale panoramica sull'uso dei dati afferma che i dati non vengono usati da Cursor per l'addestramento quando questa modalità è attivata. La pagina rimanda inoltre gli utenti ai fornitori dei modelli per i dettagli sulle loro pratiche di conservazione.
Questa distinzione è importante perché Cursor può instradare le richieste verso modelli forniti da aziende come Anthropic e OpenAI. L'editor, i suoi fornitori di infrastruttura e il fornitore del modello selezionato possono occupare ciascuno una posizione diversa nel percorso dei dati.
Un utente che seleziona un modello Anthropic all'interno di Cursor non utilizza necessariamente lo stesso accordo sui dati di un cliente dell'API commerciale di Anthropic. Tipo di account, percorso del prodotto, impostazione sulla privacy e contratto possono tutti cambiare la risposta.
Cursor afferma inoltre che disattivare la Privacy Mode gli consente di archiviare o utilizzare dati della codebase, prompt, azioni nell'editor, frammenti di codice e attività correlate. Uno sviluppatore deve quindi comprendere sia l'impostazione sia i suoi effetti a valle prima di aprire un repository sensibile.
La formulazione “privacy mode” fornisce un segnale utile, ma non può spiegare l'intera catena di trattamento. Non risponde automaticamente alla domanda se esistano log temporanei, quali subfornitori ricevano dati o come un fornitore esterno del modello gestisca il monitoraggio degli abusi.
Anthropic applica analogamente regole diverse tra prodotti per consumatori e commerciali. La sua documentazione sulla conservazione afferma che i normali contenuti di prompt e output inviati tramite la sua API commerciale non vengono conservati per impostazione predefinita, fatte salve le eccezioni documentate.
Claude Code può qualificarsi per la conservazione zero dei dati quando viene utilizzato attraverso accordi commerciali idonei. Gli account Claude per consumatori seguono controlli sulla privacy e termini di conservazione differenti. Gli ambienti enterprise gestiti possono applicare policy a livello di organizzazione che i singoli utenti non possono ignorare.
Queste distinzioni creano un onere informativo proprio nel momento in cui gli agenti stanno diventando più facili da installare. Uno sviluppatore può iniziare a usare un agente da terminale in pochi minuti. Comprendere ogni confine di privacy applicabile richiede molto più tempo.
Le impostazioni predefinite sulla privacy interagiscono anche con la telemetria opzionale del prodotto. La documentazione di Claude Code di Anthropic identifica alcune metriche come abilitate per impostazione predefinita, offrendo al contempo controlli per il traffico non essenziale. Le analisi di prodotto non equivalgono ai contenuti di un repository, ma gli utenti hanno comunque bisogno di un inventario chiaro dei dati in uscita.
L'interfaccia ideale separerebbe queste categorie. Mostrerebbe se lo strumento invia prompt, file sorgente, percorsi dei file, output dei comandi, log di arresto anomalo, metriche di utilizzo o feedback. Per ogni categoria indicherebbe destinazione e regola di conservazione.
Un singolo interruttore raramente comunica questo livello di dettaglio. Può anche incoraggiare un ragionamento binario, in cui uno strumento viene etichettato come privato o non privato. L'esposizione effettiva dipende dal workflow completo.
L'indicizzazione dei repository offre un altro esempio. Un editor AI necessita di una mappa della codebase per recuperare il contesto rilevante. Questo processo può rimanere locale, trasmettere informazioni derivate, caricare contenuti selezionati o combinare questi metodi.
L'hashing e l'offuscamento dei percorsi possono ridurre l'esposizione, ma il loro valore dipende dall'implementazione e dalle ipotesi di minaccia. Non eliminano la sensibilità del codice selezionato successivamente per una richiesta AI.
Il rapporto tra Anthropic e Cursor rende questi confini particolarmente importanti. Un'azienda può fornire l'interfaccia e l'orchestrazione mentre un'altra fornisce il modello. La responsabilità diventa distribuita, anche se lo sviluppatore sperimenta una sola funzionalità in un'unica finestra.
OpenAI Codex e altri agenti sollevano questioni simili. Il settore ha quindi bisogno di informative comparabili, non di un'altra raccolta di etichette sulla privacy incompatibili. Uno sviluppatore dovrebbe poter confrontare i prodotti senza dover prima tradurre la terminologia di ogni fornitore.
Un'impostazione predefinita realmente privata ridurrebbe al minimo i contenuti archiviati, escluderebbe i dati dei clienti dall'addestramento e spiegherebbe il trattamento inevitabile prima dell'attivazione. Dovrebbe inoltre preservare tali garanzie quando gli utenti cambiano modello all'interno della stessa applicazione.
Le richieste di autorizzazione non possono correggere un modello di esecuzione non sicuro
Un'impostazione predefinita sicura deve limitare ciò che un agente può fare dopo l'approvazione, non limitarsi a chiedere se può iniziare.
Anthropic afferma che Claude Code chiede conferma prima di eseguire comandi e apportare modifiche ai file nel suo modello di autorizzazione standard. La sua descrizione della auto mode presenta un'autonomia più ampia come un'opzione esplicita anziché come stato iniziale.
La auto mode utilizza un classificatore per esaminare le chiamate agli strumenti alla ricerca di azioni potenzialmente dannose. Anthropic afferma che il classificatore cerca comportamenti quali operazioni distruttive sui file, esfiltrazione di dati ed esecuzione di comandi dannosi.
Questa progettazione riconosce un fatto importante. Gli utenti non possono supervisionare ogni azione di basso livello una volta che un agente avvia un'attività lunga. Un secondo controllo tecnico deve continuare a verificare il comportamento dopo la richiesta originale.
Tuttavia, un classificatore resta una salvaguardia probabilistica. Può fraintendere il contesto, non rilevare un'operazione mascherata o bloccare attività legittime. Dovrebbe integrare l'isolamento del sistema operativo e credenziali ristrette, non sostituirli.
Il sandboxing offre un confine più solido limitando i file, i processi e le destinazioni di rete disponibili per un agente. Un sandbox efficace può limitare i danni anche quando il modello segue istruzioni ostili.
La difficoltà consiste nel rendere utile tale confine. Le attività di programmazione richiedono spesso registri di pacchetti, servizi di test, documentazione, controllo di versione e risorse cloud. Ogni eccezione amplia l'ambiente raggiungibile dall'agente.
Un'ampia autorizzazione di rete può rendere meno significativa una restrizione sui file. Un agente potrebbe non leggere direttamente una directory protetta, ma l'output dei comandi o gli strumenti connessi possono esporre informazioni simili. I controlli di sicurezza devono seguire i dati lungo l'intera catena di strumenti.
Le credenziali creano un altro punto debole. Gli sviluppatori spesso conservano token di accesso in variabili d'ambiente, file di configurazione, gestori di password, cronologie dei comandi o strumenti cloud. Un agente che opera con l'identità dell'utente può incontrare tali segreti durante l'esecuzione di normali attività.
Il principio del privilegio minimo significa fornire all'agente solo l'autorità necessaria per una singola attività. In pratica, ciò potrebbe significare una credenziale temporanea limitata a un repository, un branch e una durata breve.
Questo approccio entra in conflitto con la comodità. Le credenziali persistenti riducono i tempi di configurazione, e un accesso ampio evita che le attività si interrompano per richiedere ulteriori autorizzazioni. Le stesse caratteristiche aumentano anche l'impatto di una sessione compromessa.
Gli agenti AI intensificano un vecchio compromesso di sicurezza anziché crearne uno del tutto nuovo. Script di shell, strumenti di build, estensioni del browser e gestori di pacchetti ricevono da tempo autorizzazioni significative. La differenza è che gli agenti scelgono le azioni in modo dinamico a partire dal contesto in linguaggio naturale.
Il software tradizionale esegue normalmente un percorso scritto e revisionato prima del rilascio. Un agente costruisce il proprio percorso durante l'attività. Il suo comportamento può cambiare quando legge un nuovo file o riceve il risultato da uno strumento esterno.
Questa esecuzione adattiva rende le allowlist statiche necessarie, ma insufficienti. Un comando può essere consentito mentre i suoi argomenti restano pericolosi. Un programma affidabile può inoltre diventare dannoso se indirizzato a una directory imprevista o se riceve input controllati da un attaccante.
L'approvazione umana ha un ruolo, soprattutto prima di operazioni irreversibili. Tuttavia, un eccesso di richieste produce affaticamento da approvazione. Gli utenti iniziano ad accettare automaticamente le richieste di routine, trasformando un meccanismo di sicurezza in un ostacolo con un pulsante di conferma.
Impostazioni predefinite migliori classificherebbero le azioni in base alle conseguenze. Leggere un file sorgente pubblico non dovrebbe ricevere lo stesso trattamento dell'esportazione di variabili d'ambiente. Eseguire test unitari dovrebbe essere diverso dal distribuire codice o modificare un database di produzione.
L'agente dovrebbe inoltre spiegare perché un'azione è necessaria e quali dati può toccare. Tale spiegazione deve provenire dal livello di enforcement, non soltanto dal modello che richiede l'autorizzazione.
I log di audit sono altrettanto importanti. I team necessitano di una registrazione duratura di comandi, modifiche ai file, chiamate agli strumenti, richieste di rete, approvazioni e utilizzo delle identità. Senza questa registrazione, indagare su un incidente diventa una ricostruzione basata su una cronologia del terminale incompleta.
Una registrazione ricercabile migliora anche le revisioni di routine. I team di ingegneria possono conservare le decisioni degli agenti insieme al materiale tecnico locale in una base di conoscenza ricercabile. Questo non sostituisce il logging di sicurezza, ma aiuta a collegare le modifiche al contesto del progetto.
L'obiettivo non è circondare ogni suggerimento di avvisi. È rendere il comportamento sicuro il percorso di minore resistenza. Un accesso più ampio dovrebbe restare possibile, ma il suo ambito e le sue conseguenze dovrebbero essere visibili.
I fornitori stanno aggiungendo controlli, ma la responsabilità resta frammentata
Anthropic, Cursor e OpenAI stanno rispondendo alla pressione sulla sicurezza, ma i loro controlli lasciano ancora ai clienti il compito di assemblare una difesa completa.
Cursor ha pubblicato documentazione sulla sicurezza e sulla privacy, corretto vulnerabilità segnalate e aggiunto controlli per le organizzazioni che gestiscono codice sensibile. Nel 2026 ha inoltre stretto una partnership con Chainguard, azienda specializzata nella supply chain del software.
La partnership mira a indirizzare il codice generato verso componenti open source verificati, secondo quanto riportato sull'iniziativa di sicurezza di Cursor. Questo affronta un livello diverso rispetto alla prompt injection o alla conservazione dei dati.
Il rischio della supply chain del software emerge quando un agente raccomanda una dipendenza vulnerabile, abbandonata o dannosa. I nomi dei pacchetti possono essere digitati erroneamente, inventati o progettati deliberatamente per assomigliare a progetti legittimi.
Un agente può installare un simile pacchetto più rapidamente di quanto uno sviluppatore riuscirebbe a trovarlo e valutarlo manualmente. Un catalogo verificato riduce questa esposizione, ma non controlla cosa possa leggere l'agente installato né dove possa connettersi.
Anthropic ha ampliato la documentazione di sicurezza, le opzioni di sandboxing, le impostazioni gestite e le modalità di autorizzazione di Claude Code. Avverte inoltre gli utenti di applicare le normali pratiche di sicurezza agli strumenti AI.
OpenAI e altri fornitori offrono controlli comparabili per ambienti Codex, approvazioni e amministrazione aziendale. Le funzionalità esatte continuano a cambiare, il che rende la documentazione aggiornata più preziosa delle impostazioni predefinite ricordate.
Questi sforzi indeboliscono la critica più semplice, secondo cui i fornitori ignorerebbero la sicurezza. Stanno investendo tempo di engineering in contenimento, classificatori, monitoraggio e risposta alle vulnerabilità. Diversi hanno corretto problemi gravi a seguito di divulgazioni responsabili.
La critica più incisiva riguarda architettura e incentivi. I fornitori competono su quanto lavoro un agente completi senza interruzioni. I team di sicurezza misurano il successo limitando gli accessi non approvati e preservando le evidenze.
Una dimostrazione di prodotto premia la velocità. Raramente mostra la delimitazione delle credenziali, la verifica della conservazione, la ricostruzione degli incidenti o il lavoro amministrativo richiesto prima della distribuzione. Gli acquirenti possono quindi valutare le capacità prima di comprendere l'esposizione.
I clienti enterprise possono colmare alcune lacune tramite controlli sugli endpoint, workspace isolati, policy di rete e gateway per modelli approvati. Possono vietare gli account consumer e imporre configurazioni gestite ai team.
Le organizzazioni più piccole spesso non possono costruire questo livello. Dipendono più pesantemente dalle scelte iniziali del fornitore. Un'impostazione predefinita accettabile in un ambiente enterprise gestito può essere pericolosa su un laptop non gestito.
Il mercato frammentato incoraggia inoltre il passaggio da uno strumento all'altro. Uno sviluppatore può usare Cursor per la modifica, Claude Code per il lavoro da terminale e Codex per un'attività isolata. Ogni strumento può mantenere autorizzazioni, istruzioni, cronologie e regole sulla privacy separate.
La configurazione a livello di progetto aiuta a standardizzare il comportamento all'interno di un repository. Tuttavia, impostazioni personali, policy dell'organizzazione, plugin e servizi connessi possono ancora modificare l'ambiente effettivo.
Questo rende la configurazione stessa parte della superficie di attacco. I ricercatori che studiano gli strumenti di coding agentico hanno documentato un insieme crescente di formati di istruzioni a livello di repository. Questi file possono migliorare la coerenza, ma istruzioni non affidabili possono anche influenzare il comportamento dell'agente.
I team di sicurezza necessitano di un livello di policy indipendente dagli strumenti. Dovrebbe definire a quali repository un agente può accedere, quali destinazioni può contattare e quali azioni richiedono autorizzazione umana.
I fornitori potrebbero opporsi a un livello comune se questo indebolisse la differenziazione del prodotto. I clienti dovrebbero comunque pretendere log portabili, informative esplicite sui flussi di dati e impostazioni applicabili al di fuori di una singola interfaccia.
Il mercato ha precedenti storici. I browser web hanno infine normalizzato richieste di autorizzazione, sandboxing, isolamento dei siti e controlli sulla privacy visibili. I sistemi operativi mobili hanno posto gli accessi sensibili dietro categorie di autorizzazioni standardizzate.
Questi sistemi restano imperfetti. I loro progressi mostrano comunque come siano impostazioni predefinite mature. Le applicazioni richiedono capacità specifiche, i sistemi operativi applicano il confine e gli utenti possono in seguito ispezionare o revocare l'accesso.
Gli agenti di coding necessitano di un modello equivalente per repository, terminali, segreti, reti, distribuzioni e strumenti esterni. Un interruttore specifico del fornitore non può fornire l'intera struttura.
Il momento attuale non rappresenta quindi una scelta tra Anthropic e Cursor, o tra Claude Code e Codex. L'avversario più profondo è l'autonomia incentrata sulla comodità contro limiti applicabili.
La concorrenza può aiutare se i clienti premiano l'azienda con confini più chiari. Può nuocere se benchmark e dimostrazioni valorizzano la velocità di completamento trattando le misure di sicurezza come attrito.
Cosa dovrà dimostrare il coding AI sicuro
Il prossimo banco di prova sarà capire se i fornitori trasformeranno controlli opzionali in impostazioni predefinite misurabili senza rendere inutilizzabili i loro agenti.
Il primo segnale arriverà dalle modifiche alle autorizzazioni nelle release dei prodotti. Gli sviluppatori dovrebbero osservare se gli agenti inizieranno a operare in workspace limitati, con accesso alla rete e percorsi sensibili bloccati fino a esplicita abilitazione.
Un'impostazione predefinita più solida vincolerebbe l'approvazione alla risorsa esatta a cui si accede. Annullerebbe l'approvazione quando un symlink, una modifica della configurazione o un aggiornamento del repository cambia il significato di quella risorsa.
Questo rafforzerebbe l'argomentazione secondo cui i fornitori accettano la responsabilità dell'enforcement. Un'altra ondata di vulnerabilità che aggirano le approvazioni la indebolirebbe, anche se le patch arrivassero rapidamente.
Il secondo segnale sarà costituito da informative sulla privacy comparabili. Gli utenti hanno bisogno di un'unica vista che mostri quali dati lasciano il dispositivo, chi li riceve, perché vengono elaborati e quando vengono eliminati.
Il cambio di modello dovrebbe aggiornare tale vista prima dell'esecuzione di una richiesta. Un'interfaccia non dovrebbe suggerire che una garanzia di privacy si applichi automaticamente a ogni fornitore disponibile nel suo menu.
I clienti dovrebbero inoltre osservare se il comportamento privato resta coerente tra prodotti consumer, team, enterprise e API. Le differenze contrattuali sono inevitabili, ma inversioni sorprendenti tra tipi di account creano rischi evitabili.
Il terzo segnale proverrà dall'adozione enterprise e dalla segnalazione degli incidenti. I team di sicurezza riveleranno se i controlli degli agenti funzionano in condizioni reali, incluse combinazioni di repository, credenziali legacy e sistemi cloud connessi.
Il lavoro sottoposto a peer review sta già andando oltre gli avvertimenti astratti. Lo studio IssueTrojanBench valuta come i principali agenti di coding rispondano a richieste di issue dannose. I risultati di tali benchmark possono verificare se le protezioni resistono a contenuti di progetto avversari.
Le valutazioni utili dovrebbero misurare più del semplice rifiuto, da parte dell'agente, di un prompt palesemente dannoso. Dovrebbero esaminare istruzioni indirette, attacchi in più fasi, spostamento dei dati, ambiguità delle autorizzazioni e recupero dopo l'avvio di un'azione pericolosa.
La trasparenza sugli incidenti conta quanto le prestazioni nei benchmark. I fornitori dovrebbero comunicare quale controllo ha fallito, quali versioni sono state interessate e se i log possono identificare l'esposizione. I clienti non possono migliorare le difese basandosi soltanto su un avviso di patch.
Anche gli sviluppatori hanno responsabilità mentre il mercato matura. I repository sensibili dovrebbero usare account approvati, impostazioni di conservazione documentate, ambienti isolati e credenziali con ambito ristretto.
L'output degli agenti dovrebbe entrare negli stessi controlli di revisione, test e distribuzione applicati alle modifiche scritte da esseri umani. La fluidità non dimostra la correttezza e test superati non provano che una modifica sia sicura.
I team dovrebbero presumere che il contenuto dei repository possa essere ostile. Progetti esterni, testo delle issue, documentazione generata e istruzioni sui pacchetti meritano la stessa cautela riservata ai contenuti web non affidabili.
Questo modello operativo è impegnativo, ma non dovrebbe diventare la risposta permanente. I fornitori sono in una posizione migliore per applicare condizioni iniziali sicure in milioni di sessioni.
La pressione sui flussi di lavoro Anthropic Cursor riflette questo squilibrio. Attualmente gli utenti compiono scelte di prodotto, esaminano diversi documenti sulle policy, configurano le autorizzazioni e monitorano i risultati. I fornitori controllano l'architettura che determina se tali passaggi siano efficaci.
Gli sviluppatori dovrebbero ora porre domande dirette prima di ampliare l'accesso degli agenti. Lo strumento conserva codice o prompt? La policy dell'organizzazione può prevalere sulle impostazioni personali? L'approvazione copre una singola azione o una capacità continuativa? Gli amministratori possono verificare ogni richiesta di rete e chiamata agli strumenti?
Le risposte dovrebbero essere visibili prima dell'installazione, non scoperte dopo un incidente. Se Anthropic, Cursor, OpenAI e i loro pari renderanno chiare queste risposte, l'autonomia potrà crescere senza richiedere fiducia cieca.
In caso contrario, i team di sicurezza risponderanno con gateway più restrittivi, workspace isolati o divieti assoluti. La piattaforma AI di coding vincente non si limiterà a completare il maggior numero di attività. Mostrerà esattamente cosa ha toccato, perché lo ha toccato e quale confine non avrebbe mai potuto oltrepassare.
