La cattura che nessuno vuole vedere
Un ricercatore indipendente, in arte cereblab, ha infilato Grok Build CLI dietro un proxy di intercettazione su macOS. Quello che è uscito dalle capture è una fotografia perfetta della nuova filiera del rischio aziendale.
Su un repository di test da 12 GB, il canale modello ha spostato 192 KB di traffico. Il canale storage ne ha spostati 5.1. Non è un bug. È una funzionalità.
Una credenziale canary piantata in un file .env è apparsa in chiaro nei pacchetti. Il toggle chiamato "Improve the model", disattivato, non ha fermato nulla. Il server rispondeva lo stesso trace_upload_enabled: true. Il repository intero — tutta la storia Git, tutti i commit, ogni file mai toccato dall'agente — è finito in un bucket Google Cloud Storage chiamato grok-code-session-traces.
Un vendor che può cambiare il flag domani mattina, senza avviso, senza changelog, senza advisory, è un vendor che possiede la tua fabbrica. Anche se la fabbrica è dentro il tuo ufficio.
Il problema non è Grok
Grok Build è il caso di scuola. Ma è solo il primo che qualcuno ha misurato bene.
L'intera categoria dei coding agent cloud-first funziona così: il tuo codice esce dalla tua rete, attraversa l'infrastruttura del vendor, viene loggato per "migliorare il servizio", e torna indietro. Il vendor ti garantisce che viene cancellato. Tu non puoi verificarlo. Il vendor può cambiare la policy in qualsiasi momento. Lo ha fatto xAI in silenzio, un giorno dopo l'esposizione.
Tre giorni per una disattivazione silenziosa. Zero advisory. Zero risposta pubblica. Nessuna parola su cosa succede ai repo già collezionati. Questa non è una svista. È il modello di business.
Perché la governance classica non basta
Le aziende stanno rispondendo con i ferri vecchi. Policy interne. DLP. NDA con i vendor. Audit periodici. Sono tutte difese cosmetiche.
Una policy interna non impedisce a un CLI di scrivere su un socket verso Google Cloud. Un audit annuale non intercetta un toggle che non disabilita quello che dice di disabilitare. Un NDA non ha alcun valore quando il bucket di raccolta non è nemmeno documentato.
La difesa reale è architetturale. Sposta il punto dove il dato nasce. Sposta il punto dove il dato viene processato. Tienili dentro il perimetro che puoi controllare.
La risposta strutturale: Aura Orchestrator on premise
Aura Orchestrator è il nostro layer cognitivo. Orchestra GPT, Claude, Llama, Mistral in un flusso unico intelligente. Lo fa dentro la tua rete.
On premise significa tre cose concrete:
1. Nessun bucket nascosto.
Il codice non esce dal tuo perimetro. Non c'è un grok-code-session-traces. Non c'è un telemetria che non puoi ispezionare. Se vuoi loggare, logghi tu. Dove vuoi. Per quanto vuoi.
2. Modelli sotto il tuo contratto. Il modello gira dietro il tuo account API, o su inference locale, o su un endpoint privato che tu gestisci. Le chiavi sono le tue. La fattura è la tua. La visibilità sui log è la tua.
3. Politiche di esecuzione verificabili. Aura Orchestrator instrada solo i file necessari al task. Non l'intero repository. Non la storia Git. Non le variabili d'ambiente. Se l'agente deve toccare cinque file, tocca cinque file. Il resto non lascia mai la macchina.
Cosa cambia per chi sviluppa
I tuoi ingegneri non perdono il coding agent. Perdono solo la dipendenza dal bucket di qualcun altro.
Multi-model orchestration significa che puoi usare Claude per il refactor pesante, Mistral per il boilerplate, Llama locale per la documentazione interna senza mandare niente fuori. La rotta la decidi tu. La logga Aura. La controlli tu.
Quando il vendor di turno pubblicherà il prossimo advisory "abbiamo cambiato qualcosa", tu continuerai a lavorare. Perché non è mai stato il loro problema da risolvere.
La visione Oraclum-X
Il caso Grok Build è il manifesto involontario del perché esiste Aura Orchestrator on premise.
La scelta non è fra usare l'AI e non usarla. La scelta è fra dare la tua fabbrica a un vendor che cambia le regole da remoto, oppure tenertela. Con la stessa intelligenza. Con un perimetro che puoi difendere.
Le regole del cloud le scrivono i cloud provider. Le regole dell'on premise le scrivi tu.
Vuoi vedere Aura Orchestrator on premise dentro la tua rete? Parliamo di un deployment reale, non di una demo.