Un agente AI può essere completamente locale e avere comunque troppo accesso. Se il processo vede la cartella che contiene wp-config.php, le chiavi SSH, i backup dei clienti e gli script di deploy, un comando sbagliato non deve uscire dal computer per creare un problema. La decisione utile, quindi, non è soltanto «locale o cloud?»: è quanto spazio di manovra concedere all’agente.
Il lancio di Local Code del 28 ottobre 2026 rende il confronto concreto. L’app riunisce modello, runtime e strumenti in un ambiente protetto dalla App Sandbox di macOS. Dall’altra parte ci sono gli agenti collegati alla shell e al filesystem di lavoro, più flessibili ma anche più esposti. Per una PMI o un professionista che sviluppa e gestisce siti WordPress, la differenza si misura nel raggio del danno possibile.
Il criterio: la superficie dei permessi
Un modello locale evita l’invio di prompt e file a un provider quando l’inferenza resta sul dispositivo. Non limita però, da solo, ciò che il software può leggere, modificare o trasmettere. Il confine efficace è imposto dall’ambiente di esecuzione: cartelle visibili, rete disponibile, programmi eseguibili e credenziali raggiungibili.
Apple descrive la App Sandbox come un controllo applicato dal sistema operativo per contenere i danni di un’app compromessa. L’app deve dichiarare i privilegi richiesti e può ricevere accesso a file o cartelle scelti dall’utente. È un limite tecnico, non una promessa nelle impostazioni.
La privacy del modello protegge il transito dei dati. La sandbox protegge il raggio d’azione dell’agente. Sono due controlli diversi.
Approccio A: agente confinato
Local Code applica questo modello in modo esplicito. Secondo la sua documentazione open source, l’agente lavora nelle cartelle selezionate, non dispone di accesso completo al disco e non può avviare programmi esterni non inclusi nell’app. Python, Node.js, shell, LibreOffice e altri strumenti vengono eseguiti dentro il processo protetto. I modelli locali possono funzionare offline; per la configurazione più leggera viene proposto Qwen 3.8 27B, con un download che parte da 9,6 GB.
Pro concreti
- Permessi leggibili: il progetto concesso all’agente è separato dalle altre cartelle del Mac.
- Contenimento: una modifica errata resta nel workspace autorizzato, salvo ulteriori permessi concessi.
- Dati locali: usando un modello on-device, prompt e file non vengono inviati a un provider AI.
- Setup coerente: runtime e strumenti inclusi riducono le dipendenze installate nel sistema.
Contro concreti
- Stack incompleto: plugin, binari o servizi non presenti nella sandbox possono richiedere un percorso alternativo.
- Hardware: un modello locale usa memoria e spazio del computer; i modelli più capaci richiedono macchine più dotate.
- Integrazioni limitate: un workflow basato su Docker, SSH, WP-CLI remoto o browser specifici può non entrare nel perimetro.
Approccio B: accesso esteso alla macchina
Un agente collegato alla shell reale può usare lo stack già installato: Composer, npm, WP-CLI, Git, Docker, browser, CLI cloud e script proprietari. Per un progetto WordPress complesso è il percorso più rapido quando bisogna riprodurre la build, aggiornare dipendenze, eseguire test end-to-end o intervenire su un ambiente remoto.
Il costo è una superficie di rischio più ampia. La guida di sicurezza OpenAI per gli ambienti agentici chiarisce il punto: il codice generato può raggiungere file, credenziali e rete disponibili nell’ambiente. Per questo raccomanda isolamento dei workload, traffico in uscita limitato agli endpoint approvati e credenziali separate dall’ambiente eseguito dall’agente.
Pro concreti
- Compatibilità: l’agente usa la stessa toolchain del team senza ricostruirla in un contenitore chiuso.
- Automazione completa: test, build, deploy e verifiche browser possono stare nello stesso flusso.
- Modelli gestiti: il cloud evita di dimensionare RAM, storage e aggiornamenti dei modelli sul computer.
Contro concreti
- Errore più costoso: una directory concessa troppo in alto può includere più progetti, backup o configurazioni.
- Segreti esposti al processo: variabili d’ambiente e file di credenziali diventano utilizzabili se sono visibili all’agente.
- Governance: log, retention e uso dei dati dipendono dal piano e dal provider scelto. Per esempio, OpenAI dichiara che i dati dei prodotti business e delle API non vengono usati per l’addestramento per impostazione predefinita, ma questo non equivale a elaborazione locale.
Confronto operativo per WordPress e web
| Criterio | Sandbox | Accesso esteso |
|---|---|---|
| Avvio su un tema o plugin isolato | Più sicuro per default | Più rapido se la toolchain è già pronta |
| Uso di SSH, Docker e WP-CLI remoto | Può richiedere integrazioni dedicate | Diretto, ma con credenziali esposte al processo |
| Errore su file | Limitato alle cartelle autorizzate | Limitato soltanto dai permessi dell’utente |
| Modello locale | Naturale, con costo hardware | Possibile, ma non riduce i permessi del processo |
| Automazioni di produzione | Da progettare esplicitamente | Flessibili, ma richiedono gate e rollback |
La scelta per PMI e professionisti
Per sviluppo di temi, plugin, snippet e migrazioni, partirei da un workspace sandboxed contenente soltanto il repository e dati di test. Il database va anonimizzato; .env, chiavi private, backup completi e credenziali di produzione restano fuori. È un’impostazione meno spettacolare, ma rende verificabile il confine.
L’accesso esteso ha senso quando il valore nasce proprio dall’integrazione: test con Docker, automazioni browser, deploy o diagnostica su più servizi. In quel caso non userei mai l’account amministrativo abituale. Meglio un container o una macchina dedicata, token con scope minimo, rete allowlist, snapshot prima delle modifiche e approvazione umana prima del deploy.
La take finale è netta: per il lavoro quotidiano scegli la sandbox come default. Concedi accesso esteso solo a un workflow già testato, reversibile e osservabile. Un agente più libero non è automaticamente più produttivo; lo diventa soltanto quando i permessi extra servono davvero e il loro costo è sotto controllo.