← Tutte le news
ARTICOLO
3 ottobre 2026 11 min di lettura

Un indice cloud dell’agente di coding significa che il codice è rimasto sul laptop?

No. Un indice cloud, una Repo Wiki o uno snapshot del workspace, di default o silenzioso, è un controllo di residenza e custodia: girare sul laptop del tecnico non prova che il codice sia rimasto lì.

L’MSP sente dal cliente una frase familiare: l’assistente gira sul computer del tecnico, quindi il repository non esce. La risposta, nelle prime due frasi, è no. Un indice cloud, una Repo Wiki o uno snapshot del workspace, di default o silenzioso, è un controllo di residenza e custodia, non un interruttore di comodità.

La classe di fallimento si nomina e si lascia a quell’altezza. L’intero workspace può lasciare il dispositivo. Storia e configurazioni possono uscire insieme ai file aperti. Questo testo non spiega come si costruisce quel percorso. Dice che cosa non dimostra «gira in locale», a che cosa può servire la copertura ZCode del settembre 2026, quali cataloghi di controllo citare, e che cosa scrivere in una policy di MSP.

Un limite va detto subito. Le frasi sulla cancellazione, e le frasi secondo cui il materiale non è stato usato per il training, sono affermazioni dell’azienda. Non sono fatti verificati da Altovar. Un conteggio di stelle, una riga di marketing o un albero pubblico ripulito non trasformano quelle affermazioni in prove.

Edificio grigio in cemento di un data center, con camini di sfiato e recinzione di sicurezza, sotto un cielo azzurro.
Foto: Kecko from Eastern Switzerland (CC BY 2.0), Wikimedia Commons.

Il buyer fonde tre frasi in un’unica rassicurazione. Indice del codebase, Repo Wiki e sync del workspace non sono la stessa etichetta di prodotto, e un MSP non deve trattarle come lo stesso pulsante. Condividono un significato di custodia quando una di esse mette una copia, o un derivato di una copia, fuori dall’endpoint. L’interfaccia può continuare a dire che l’agente è locale. L’indice può stare altrove. Leggere l’aggettivo sulla schermata iniziale non è il controllo.

«Il modello è locale» e «l’indice è locale» sono frasi diverse. Una finestra sul laptop può chiamare un indicizzatore cloud, un generatore di wiki o un lavoro di snapshot senza spostare il riquadro della chat. Il tecnico vede un processo sulla macchina di cui si fida già. Il cliente sente «on-prem» perché la tastiera è in ufficio. Nessuna delle due osservazioni dice dove sono finiti l’albero, la storia o i file di configurazione dopo l’indice. Un’inferenza davvero locale non parla di un percorso laterale che impacchetta il workspace verso uno store del fornitore.

La giornata dell’MSP rende l’errore più netto. Un laptop di tecnico tiene spesso più di un albero cliente: un ticket al mattino, una modifica al pomeriggio, cloni lasciati nella home perché lo spazio disco era economico. Un profilo di agente condiviso è un percorso pooled. È una configurazione, una cache di login, spesso un’unica impostazione di indice applicata a quegli alberi. Un login pulito del tecnico sul proprio identity provider non crea custodia per cliente. Dimostra che il tecnico si è autenticato. Non dimostra che il sorgente di ciascun cliente sia rimasto dentro un confine che quel cliente riconoscerebbe come proprio.

I secret viaggiano con l’albero. Chiavi rimaste nei file di ambiente, token di integrazione continua, configurazione del client SSH e la storia che registra come quei file sono cambiati sono lo stesso raggio d’impatto che la guida ordinaria sui secret tratta già come un fallimento di gestione. Non sono una stranezza che compare solo quando c’è un modello. Se uno snapshot prende il workspace, prende anche ciò che nel workspace è stato lasciato in chiaro. Rotazione, minimo privilegio e il rifiuto di lasciare che un tool diventi un’uscita silenziosa sono controlli vecchi. Una funzione di AI non li rinomina.

Un drop open source del client di oggi prova una cosa più stretta. Si può leggere l’albero pubblico ora e vedere che cosa quell’albero dice di fare. Quella lettura non prova la retention di ieri, la cancellazione di ieri, né se le copie di ieri siano state usate per il training. Una storia assente non è un certificato che la storia assente fosse innocua. I file correnti sono evidenza sui file correnti. La policy deve dirlo prima che un buyer tratti un clone come una chiusura forense.

L’episodio ZCode è evidenza della classe di rischio, non una riproduzione. I fatti qui sotto restano dentro le pagine lette il 3 ottobre 2026 e dentro la nota di tavolo che ha fissato questo angolo il 23 settembre 2026. Non c’è un metodo, non c’è un campione, non c’è un invito a cercare oggetti memorizzati.

The Register, pubblicato il 22 settembre 2026 alle 16:59 UTC (18:59 Europe/Rome), ha riportato le scuse di Z.ai e il fatto che ZCode impacchettava e caricava i workspace degli utenti, storie di progetto comprese, verso Alibaba Cloud. Il materiale di decifrazione è descritto come tenuto sul server. Il ricercatore Ferstar, secondo quel resoconto, ha legato il comportamento a Repository Index dopo le pagine cloud di Repo Wiki; lo stesso resoconto dice che non c’era un interruttore nel prodotto e che la privacy policy non lo dichiarava. L’azienda ha detto che i dati non sono stati usati per addestrare modelli. L’azienda ha affermato che valutazioni di CAICT e NSFOCUS mostravano cancellati i caricamenti precedenti. Repo Wiki è stata rimossa. Il progetto è stato reso open source. Ferstar, sempre secondo il resoconto, ha detto che l’albero pubblicato non mostrava più Repo Wiki e ha criticato una storia pre-patch cancellata. La pagina è il pezzo del Register del 22 settembre.

InfoWorld, lo stesso giorno, ha descritto un flusso attivo di default che mandava repository locali ad Alibaba Cloud senza consenso. Riportava la descrizione di Ferstar, attraverso una traduzione automatica che l’articolo stesso segnala, di un impacchettamento silenzioso di storia git, cache LFS, reflog e configurazioni verso object storage Aliyun. L’azienda ha detto che la remediation è arrivata in ZCode v3.14.0, che NSFOCUS ha confermato cancellati un bucket di produzione e i suoi oggetti, che Repo Wiki e il percorso di snapshot erano stati rimossi, e che i dati «non sono mai stati usati per il training dei modelli». Quelle frasi su cancellazione, bucket, training e assessment sono attribuzioni di vendor o di stampa. Vanno trattate come affermazioni. Non sono verificate da Altovar. La reazione dei practitioner su quella pagina, Cris Thomas e Katie Paxton-Fear di Semgrep, resta solo una reazione: dichiarare l’egress e partire dal minimo dei permessi, non dal massimo. La pagina è il report di InfoWorld del 22 settembre.

Ciò che la classe sostiene, per un buyer, è l’immagine di uno snapshot dell’intero workspace verso object storage, con materiale di decifrazione descritto come tenuto dal server e con la storia git dentro il pacchetto. Non sostiene che ogni agente di coding faccia questo, né che gli assessment citati abbiano chiuso la domanda, né che un albero pubblico successivo riavvolga settembre. La nota che aveva già fissato questi due URL è la FAQ Lane B del 23 settembre. Questo testo non aggiunge aneddoti che quella nota non aveva.

Tre cataloghi incorniciano lo stesso errore del buyer senza trasformare il pezzo in una recensione solo su ZCode. Ognuno è guida primaria o adiacenza, come etichettato. Nessuno è stato riletto per questo giro: gli URL sono quelli citati dal file di tavolo del 23 settembre.

Il cheat sheet OWASP sulla gestione dei secret tratta i secret scritti nel sorgente e nella configurazione come una superficie di perdita ordinaria: chiavi di API, credenziali, materiale SSH e residui simili. Chiede minimo privilegio, un ciclo di vita controllato, e tool che non diventino un’uscita silenziosa per quei secret. Se c’è esposizione, la risposta è rilevazione, revoca e rotazione, non una scrollata di spalle perché la funzione era comoda. Un upload dell’intero workspace, in quella cornice, è un fallimento di gestione dei secret con un raggio largo, perché l’albero e i secret nell’albero si muovono insieme. Il foglio è il cheat sheet OWASP sui secret. Il file di tavolo lo ha letto il 23 settembre 2026. Questo articolo non lo ha riletto.

Il NIST Special Publication 800-53 Revisione 5, catalogo datato settembre 2020 con aggiornamenti al 10 dicembre 2020, indica AC-4 come controllo del flusso informativo e SC-7 come protezione del confine. AC-4 riguarda autorizzazioni approvate su dove l’informazione può viaggiare dentro un sistema e fra sistemi. SC-7 riguarda la protezione del confine e il controllo delle comunicazioni sulle interfacce gestite. L’egress di default di un workspace cliente, senza un flusso approvato e senza una decisione gestita di far attraversare quel confine all’albero, manca quegli intenti. Non è «AI locale». La pagina del portale citata dallo stesso file è la scheda della pubblicazione NIST, e il DOI è 10.6028/NIST.SP.800-53r5. Non riletto oggi.

La sezione del SaaS Lens di AWS Well-Architected sulla prevenzione dell’accesso cross-tenant è adiacenza, non un finding AWS su ZCode e non un audit di un vendor di agenti. Il punto della sezione è che lo scope del tenant deve derivare da un’identità verificata e che il runtime deve rifiutare le risorse di un altro tenant. Un agente di coding condiviso che indicizza molti alberi cliente su un solo profilo di tecnico è la stessa classe di fallimento di confine: accesso pooled, scope per cliente debole, e un login che sembra pulito perché ha autenticato la persona invece del confine del cliente. La pagina citata dal file di tavolo è Preventing cross-tenant access. Chiamarla adiacenza tiene la citazione onesta. Non importa un verdetto AWS dentro un agente desktop.

Cinque richieste stanno nella policy dell’MSP, ciascuna con una prova che vale e una prova che non vale. Una frase di marketing non è evidenza. Una storia pubblica schiacciata non è evidenza di ciò che il prodotto faceva prima dello schiacciamento. Un conteggio di stelle non è evidenza di custodia.

Primo: negazione di default, oppure un opt-in esplicito, per qualunque indice cloud o upload di workspace. L’evidenza è un export delle impostazioni che il cliente può leggere, o una policy di build che mostra il percorso di indice spento finché un ticket nominato non lo accende. Un banner che dice «prendiamo sul serio la privacy» non è quell’export.

Secondo: allowlist di egress sull’endpoint e controlli di data loss sulle macchine dei tecnici che tengono alberi cliente. L’evidenza è l’allowlist, il registro delle eccezioni, e un ticket quando si aggiunge un host nuovo. La promessa che «l’agente è locale» non è un’allowlist.

Terzo: inferenza privata o self-hosted dove il contratto del cliente esige la residenza. L’evidenza è la clausola e l’endpoint che serve davvero il modello, non una slide che dice che un’opzione privata esiste da qualche parte nel listino. Se il contratto tace, non si inventa un dovere di residenza che la carta non contiene. Se il contratto è esplicito, il processo sul laptop deve comunque corrispondergli.

Quarto: linguaggio di trattamento che nomina che cosa esce dal dispositivo, la retention, i sub-responsabili e l’evidenza di cancellazione. Un PDF di assessment del vendor è una claim finché il cliente non vede lo scope: che cosa era dentro, che cosa è stato campionato, e che cosa si intendeva per «cancellato». L’aggettivo sul PDF non è lo scope.

Quinto: un drop open source del client audita solo l’albero di oggi. L’evidenza è una lettura dei file che sono nel repository ora, datata e ancorata a quella lettura. Non è un racconto sul binario del mese scorso dedotto da file che quel mese non contengono più.

La frase che il buyer può ripetere è corta. Non equiparare «l’agente gira sul laptop» a «il codice del cliente non è uscito».

I buyer scriveranno «niente snapshot silenzioso del workspace» accanto a «niente training sui nostri dati», e la seconda frase non copre la prima.Speculazione — tavolo MSP, non una citazione fonte

La postura residua sull’isolamento applicativo è più stretta della domanda di custodia, e deve restare stretta. Un controllo live di isolamento del tenant ha restituito ok alle 2026-10-03T02:22:33.738Z, cioè alle 04:22:33 Europe/Rome. La forma era tipo m2m, sub app_6CQN4QRiAFcMoF48, aud au_hVn3e7UYQ23GRSja, tenant_id vincolato a cmou3qrd40000yi4pjmgq2sxa, org_id nullo, lifetimeSeconds 3600, probe ok, violazioni vuote. La probe è passata con un claim di org nullo e non ha elencato quel nullo come violazione.

Quel risultato è una postura di isolamento applicativo per l’identità multi-tenant di un MSP: un token macchina di vita breve, vincolato al tenant, e una probe che si è risolta. È complementare a una policy di endpoint sul fatto che il sorgente del cliente possa lasciare un laptop. Non è custodia del codice. Non è una certificazione. Non sostituisce i controlli di egress dell’agente di coding, un accordo di trattamento o un’evidenza di cancellazione.

Linguaggio Auth che questa chiamata di isolamento non ha ri-provato: quattro piani nativi sono CLEAR. L’elenco deferred-honest, che non è una clearance di piano, va comunque detto. GDPR getUser e sessions Admin restano deferred. advancedKeycloakService resta deferred. D1 SAML e D2 keycloakRealm restano deferred. I percorsi di esperienza SPID e CIE restano fail-closed. keycloakAlias resta nell’elenco deferred. eIDAS resta never-synced. Non è una claim di un estate assolutamente privo di binari residui, non è una claim di un estate privo di Admin API, e non è una claim che non esista alcun processo Keycloak. Le ancore di joint-clear d7a8bfbc e il docs tip 119d335e non sono qualcosa che la chiamata di isolamento di oggi abbia ricontrollato.

La telemetria di costo del gateway è in SKIP. Non è stata ri-sondata per questo articolo. Un pulse precedente ha registrato un diniego del gateway il 23 settembre 2026; quella nota non è un’osservazione fresca, e questo testo non inventa né un nuovo orario di diniego né una cifra di utilizzo.