Agenti LLM in produzione: rischi sistemici tra codice duplicato, vettori replicanti e limiti di sicurezza

Un edit alla riga 4.000 svela il problema: oltre 6.000 righe nello stesso file del data layer, con setup HTTP e parsing JSON ripetuti per ogni operazione. È dentro un’app da circa 150.000 righe, 120.000 in Rust, il resto in TypeScript e Terraform. L’hanno scritta gli agenti, soprattutto Claude Code, con alcuni passaggi in Cursor. L’autore non ha fatto code review continua. La duplicazione aumenta con nuove funzionalità. La domanda non è tecnica ma economica: quando conviene rifattorizzare?

Tesi: questi fatti si incastrano con due risultati sulla sicurezza, prompt injection che si auto-replica e un difetto strutturale di obbedienza negli LLM, e con integrazioni MCP praticabili ma non immediate. La traiettoria chiede vincoli logici chiari e una messa in servizio attenta.

Il problema pratico: codebase generate da agenti e duplicazione nel data layer

L’app citata arriva a circa 150.000 righe, con 120.000 in Rust. Dentro, un singolo file del livello dati supera le 6.000 righe. Ogni query, lettura o scrittura ripete la stessa sequenza: preparazione HTTP e parsing JSON. Il blocco cresce a ogni nuova feature. Non è un caso isolato, ma un pattern. L’autore ha usato agenti per tutto, soprattutto Claude Code; ha dato solo sguardi occasionali al codice. Ora mette sul tavolo la convenienza di un refactoring per ridurre ripetizioni e accorpare responsabilità.

Il nodo è di manutenzione e controllo. La scoperta casuale, un edit profondo in un file monolite, mostra quanto sia difficile vedere l’accumulo senza meccanismi espliciti di struttura e confini. La duplicazione nel livello dati lega l’aggiunta di funzionalità a un costo ricorrente di ripetizione, e pone il tema di quando valga la pena intervenire per consolidare le responsabilità.

Rischi di sicurezza concreti: prompt injection e istruzioni auto-replicanti

In parallelo, la superficie d’attacco cresce. Håkon Måløy dimostra che istruzioni nascoste in un documento, ad esempio testo bianco su bianco, inducono Copilot per Word a copiarle nell’output e a propagarle nei file successivi. La sequenza crea un worm che si auto-replica via documenti riusati in altre sessioni. Le istruzioni tornano a influenzare il contesto anche quando l’originale è uscito dal flusso di lavoro.

Un paper presentato all’International Conference on Machine Learning sposta l’attenzione sulla “catena di comando” interna agli LLM. Gli autori costruiscono input che ridefiniscono chi impartisce gli ordini. Il modello prende per buone quelle istruzioni e produce risposte che le policy vietano, come indicazioni su sostanze e avionica. La tesi è che esista un difetto di principio nel meccanismo di obbedienza: il modello decide in base a chi crede stia parlando. Se alteri quella percezione, le barriere cedono. “C’è una reale probabilità che questo sia un problema fondamentalmente irrisolvibile”, afferma il coautore Charles Ye.

Mettendo insieme i due risultati, emerge una continuità: vettori che riscrivono il contesto (documenti o prompt) e un interprete che non ha un ancoraggio deterministico dell’autorità. In un ambiente dove gli agenti già producono molto codice, incluso il livello dati, il rischio logico si combina con il rischio strutturale.

Mitigare con ontologie: vincoli logici prima dell’azione generativa

Frank Coyle propone una via diversa dal rafforzare solo i prompt. In un talk all’AI Engineer World’s Fair presenta le ontologie come “logical guardrails” per agenti che usano LLM. Dati come grafi. Prima si chiarisce ciò che esiste in un dominio, come si collega e che cosa l’agente può fare. Poi si lascia al modello la parte probabilistica. La definizione segue Oxford Semantic Technologies: ontologia come struttura di classi, proprietà e relazioni in un dominio di conoscenza.

Il punto operativo è il bisogno di binari logici quando gli agenti interagiscono con ambienti complessi. Le ontologie riducono ambiguità e interpretazioni spurie prima che l’agente agisca. Guidano l’interpretazione degli input e limitano le azioni entro confini deterministici, senza rimpiazzare il modello. È un modo per rendere esplicite entità e connessioni e per mettere vincoli formali accanto a un motore probabilistico.

Questa cornice non risolve il difetto di obbedienza degli LLM. Ma sposta il controllo a monte: si chiariscono concetti e relazioni prima di generare. Riduce gli spazi in cui un’interpretazione ambigua può trasformarsi in azione sbagliata.

Controlli infrastrutturali: integrazioni MCP e modellazione del contesto operativo

C’è anche il piano delle integrazioni. Simon Willison documenta che le interfacce web di Claude e ChatGPT possono accedere a server MCP esterni. Funziona, ma “non è ovvio” come impostarle e servono “parecchi passaggi”. Il post nasce da prove dirette e rinvia a modelcontextprotocol.io per chi parte da zero. Parla delle interfacce web standard, non di strumenti separati o client alternativi.

Il messaggio pratico è duplice. Primo: la connessione è possibile dalle UI standard. Secondo: la messa in servizio richiede attenzione procedurale. In uno scenario operativo, una responsabile di produzione si muove tra dashboard IoT, ERP e historian per capire quale linea richiede attenzione. Un dashboard segnala la temperatura di un motore 12°C sopra il baseline da tre giorni. L’ERP mostra la storia delle manutenzioni e la garanzia. Lo historian riporta che una macchina lavora al 130% della capacità nominale. I trend OEE a 30 giorni indicano una discesa della disponibilità dal 94% all’87%. Un’altra linea mostra throughput giù del 6%. Le linee condividono un circuito di raffreddamento, ma nessun sistema modella questa relazione: resta un’ipotesi.

Agenti e server MCP possono aiutare a collegare dati sparsi. Ma, come suggerisce l’esempio, servono modelli espliciti delle relazioni e dei vincoli. Senza, l’agente resta nel campo delle congetture. E quando la configurazione non è autoesplicativa, anche l’integrazione di strumenti che parlano MCP impone procedure chiare e verificabili.

Bilancio operativo: cosa si può mettere a terra ora, cosa resta un limite

I fatti delineano due livelli. Il primo è strutturale. Codebase generate da agenti mostrano duplicazioni crescenti e ripetizioni nel livello dati. L’autore del caso in Rust mira a stimare il beneficio economico del refactoring, segno che il costo della riduzione delle ripetizioni va misurato, non dato per scontato. Il secondo è logico-probabilistico. Esistono vettori che manipolano il contesto (documenti, prompt) e un meccanismo di obbedienza vulnerabile a chi ridefinisce “chi comanda”. La tesi di irrimediabilità di principio, riportata da Charles Ye, invita alla prudenza sull’idea di “chiusure” definitive.

Dentro questa cornice, le ontologie offrono binari formali prima dell’azione generativa. Chiariscono entità, relazioni e azioni consentite. Limitano l’ambiguità e forniscono guardrail che non dipendono dalla casualità del prompt. È una mitigazione esplicita e compatibile con agenti che restano probabilistici.

Resta l’aspetto di messa in produzione. Collegare gli agenti a dati e strumenti tramite server MCP è possibile dalle UI web di Claude e ChatGPT, ma richiede passaggi non ovvi. L’esempio operativo mostra che senza modelli dichiarati delle relazioni tra sistemi, si interpretano segnali e ipotesi senza un telaio condiviso. È qui che si gioca il margine: ridurre codice-fardello e ambiguità di dominio, sapendo che alcuni limiti di sicurezza non vengono risolti dal tuning.

Quando si attivano più collegamenti MCP dalle chat web, il carico non è solo tecnico: va deciso quali concetti vincolare prima che l’agente agisca e quali casi d’uso accettare, dato che alcune scorciatoie di obbedienza del modello restano aperte.