In breve: l'ingegneria degli agenti e la sua superficie di attacco nascosta
L'ingegneria degli agenti è la pratica di costruire tutto ciò che ruota attorno a un modello di intelligenza artificiale (istruzioni, strumenti, permessi, memoria e cicli di feedback) per trasformarlo in un agente funzionante. È in quel cablaggio, non nel modello, che risiede la maggior parte del vero rischio per la sicurezza.
- Il cambiamento: I team hanno smesso di regolare i prompt e hanno iniziato a progettare i cablaggi. Agente = modello + cablaggio.
- Il problema: Il sistema di sicurezza risiede in file di testo semplice (regole, competenze, configurazioni MCP) che vengono esaminati come documentazione, se non addirittura ignorati.
- La prova: La backdoor nel file delle regole e le vulnerabilità CVE reali di MCP dimostrano che gli aggressori la prendono già di mira.
- La correzione: Tratta il cablaggio come un codice. Inventarialo, controllalo e scansionalo prima della spedizione.
Ogni discussione sulla sicurezza dell'IA finisce inevitabilmente per concentrarsi sul modello. Può essere sbloccato? Avrà allucinazioni? Il fornitore sta addestrando il sistema utilizzando i nostri dati?
Domande legittime. Ma sempre più spesso sono quelle sbagliate. Quando un agente di intelligenza artificiale elimina una tabella di produzione, inserisce una backdoor o invia un elenco clienti a uno sconosciuto, raramente è il modello a fallire. Il modello ha fatto esattamente ciò che il suo sistema gli permetteva di fare.
Agente = modello + imbracatura
Nel corso dell'ultimo anno, il settore ha silenziosamente cambiato il significato di "costruire con l'IA". L'ingegneria basata su prompt ha lasciato il posto all'ingegneria contestuale, e quest'ultima ha a sua volta lasciato il posto a qualcosa di più grande: ingegneria di imbracatura per agenti.
L'idea è semplice. Un modello, di per sé, è un motore di ragionamento senza mani. L'armatura è tutto ciò che gli conferisce mani e uno scopo: le istruzioni che segue, gli strumenti che può richiamare, i permessi che detiene, la memoria che conserva e i controlli che individuano i suoi errori. Il sito di Martin Fowler descrive l'ingegneria del cablaggio come il lavoro che gli utenti dell'agente di codifica svolgono ora per rendere gli agenti affidabili e un quadro accademico pubblicato quest'anno suddivide il sistema in undici responsabilità, dall'accesso agli strumenti e alla memoria del progetto fino alle autorizzazioni e alla verifica.
I risultati sono concreti. I team che si occupano di ingegneria dell'infrastruttura per agenti riferiscono che la sola modifica dell'infrastruttura, pur mantenendo lo stesso modello sottostante, può alterare drasticamente le prestazioni di un agente. Questo solleva un punto scomodo per chiunque lavori nel campo della sicurezza: se l'infrastruttura determina il comportamento dell'agente, è l'infrastruttura stessa a determinare come può essere sfruttato.
Prendiamo ad esempio un'operazione banale come l'installazione di una dipendenza. Uno sviluppatore si ferma a controllare il nome del pacchetto. Un agente dotato dello strumento giusto esegue semplicemente il comando e, se il pacchetto è dannoso, nulla nel modello lo impedirà. È proprio questo che analizzeremo in questo episodio di SafeDev Talks: cosa cambia quando gli agenti IA installano le dipendenze in modo autonomo e perché l'ingegneria degli strumenti di lavoro degli agenti è diventata silenziosamente un problema della catena di approvvigionamento.
Come si presenta l'ingegneria di infrastruttura degli agenti in un repository
Apri un repository dove gli sviluppatori utilizzano agenti di intelligenza artificiale e troverai lo strumento necessario, in file che probabilmente non hai mai esaminato:
- File con regole e istruzioni (
AGENTS.md,.cursorrules(istruzioni del copilota) che indicano all'agente come comportarsi. - File delle competenze quel pacchetto di funzionalità riutilizzabili che l'agente carica su richiesta.
- Configurazioni del server MCP che collegano l'agente a strumenti, database e API.
- Messaggi di sistema e modelli di messaggio incorporato nel codice dell'applicazione.
- Cablaggio agente: quali strumenti un agente può raggiungere, quali dati può recuperare e se esiste un meccanismo di protezione tra questi due estremi.
È tutto testo semplice. È tutto commitIl tutto viene elaborato insieme al codice. E tutto viene esaminato come viene esaminata la documentazione: una rapida occhiata, un'approvazione, un'unione. Eppure ognuno di questi file può riscrivere silenziosamente ciò che un agente è incaricato di fare e ciò che gli è consentito modificare.
Questa è la vera conseguenza dell'ingegneria degli agenti: la configurazione più potente del tuo software è ora quella meno esaminata.
Gli aggressori hanno già notato
Non si tratta di una preoccupazione teorica. L'imbracatura ha una storia di incidenti breve ma significativa.
- La porta secondaria del file delle regole. Nel marzo 2025, i ricercatori hanno rivelato un attacco in cui caratteri Unicode nascosti all'interno di un file di regole istruivano gli assistenti di programmazione IA a inserire codice backdoor, senza menzionarlo nella loro risposta visibile. Un revisore che leggeva il file non ha notato nulla di insolito. Ora è catalogato come Studio di caso MITRE ATLAS AML.CS0041.
- Strumenti MCP infetti. Nel corso del 2025, i ricercatori hanno ripetutamente dimostrato che gli agenti si fidano implicitamente delle descrizioni degli strumenti, quindi un server MCP dannoso può guidare un agente semplicemente descrivendosi nel modo giusto. Nello stesso anno, CVE-2025-6514 In un client MCP ampiamente scaricato, era consentita l'esecuzione di comandi remoti durante la connessione a un server non attendibile, con un punteggio di 9.6 su CVSS.
- Eccessivo potere decisionale. Migliori OWASP Top 10 per le domande di LLM elenca l'eccessiva agenzia come rischio principale: agli agenti vengono concessi più strumenti, permessi o autonomia di quanto richiesto dal compito. Questo non è un difetto del modello. È un difetto di progettazione dell'imbracaturacisione.
Osservate lo schema. Nessuno di questi attacchi compromette il modello. Interrompono il sistema di sicurezza, e il modello fa fedelmente il resto.
Perché il tuo stack di sicurezza non lo vede
Ecco il punto critico. La maggior parte delle organizzazioni utilizza già validi strumenti di sicurezza delle applicazioni, e quasi nessuno di questi è stato progettato per questo livello.
L'analisi statica comprende il codice, ma non sa cosa sia un modello o perché un testo non attendibile che fluisce in un prompt di sistema sia rilevante. L'analisi della composizione inventaria i pacchetti, ma non enumera i server MCP o i file delle competenze. Gli scanner di segreti potrebbero non rilevare una chiave API presente in un file di configurazione dell'agente. Nessuno di questi strumenti è difettoso. Sono stati semplicemente creati per un mondo in cui la configurazione non impartiva ordini.
Quindi lo sviluppo dell'infrastruttura dell'agente procede rapidamente, mentre la sicurezza esamina la parte visibile: il modello e il codice. L'infrastruttura si trova nel mezzo.
Cinque abitudini per fissare l'imbracatura
Per la progettazione di sistemi di sicurezza per agenti non serve un nuovo team. Servono solo alcune abitudini che trattino il sistema per quello che è: un intento eseguibile.
| Abitudine | Perché è importante | Cosa fare |
|---|---|---|
| 1. Inventariare ogni imbracatura | Non è possibile garantire agenti che nessuno ha dichiarato. | Trova ogni modello, agente, server MCP, skill e prompt nei tuoi repository, direttamente dal codice sorgente e dai file di configurazione, anziché tramite un sondaggio. |
| 2. Esamina i file del cablaggio come il codice | Regole, competenze e configurazioni MCP possono riscrivere le azioni di un agente, eppure vengono esaminate come la documentazione. | Date loro lo stesso pull request analisi come logica applicativa, compresi i controlli per i caratteri nascosti. |
| 3. Fissa ciò che l'agente carica | Un prompt o un modello a cui si fa riferimento tramite un'etichetta modificabile può essere riassegnato senza modifiche al codice. | Blocca prompt e modelli in versioni immutabili. |
| 4. Metti un parapetto su ogni lavandino | I documenti recuperati, l'output degli strumenti e i contenuti degli utenti possono tutti contenere istruzioni iniettate nel modello. | Posiziona una barriera di protezione lungo il percorso ovunque il contenuto possa raggiungere il modello. |
| 5. Tenere le credenziali fuori dall'imbracatura | Le chiavi inserite dai provider di IA nei file di prompt e nelle configurazioni degli agenti rappresentano una facile preda per un attaccante. | Rimuovili e continua a scansionare i file dell'imbracatura alla ricerca di segreti. È una soluzione semplice. |
Fissare l'imbracatura, non solo il modello
Xygeni AI Security inizia dove l'ingegneria dell'infrastruttura degli agenti lascia la sua impronta: nei tuoi repository. Scopre le risorse di IA in tutta la tua codebase (modelli, agenti, server MCP, competenze, prompt, guardrailse gli strumenti di programmazione AI in uso) dal codice, dalle dipendenze e dai file di configurazione che tali strumenti lasciano dietro di sé.
Successivamente, analizza i file delle competenze, i file delle regole e le configurazioni MCP come artefatti di sicurezza, non come documentazione, e rileva i rischi di iniezione di prompt nel cablaggio dell'agente, come ad esempio contenuti non attendibili che raggiungono un prompt di sistema o un sink di recupero senza protezioni. La scansione dei segreti di Xygeni segnala le credenziali del provider AI nei prompt e nei file di configurazione dell'agente, e le dipendenze del tuo stack AI vengono sottoposte allo stesso rilevamento di malware di qualsiasi altro elemento, prima ancora che esista una firma.
FAQ
Che cos'è l'ingegneria degli agenti?
L'ingegneria dell'infrastruttura per agenti è la disciplina che si occupa di progettare l'ambiente attorno a un modello di intelligenza artificiale (istruzioni, strumenti, permessi, memoria, contesto e cicli di verifica) in modo che si comporti come un agente affidabile. Il modello fornisce il ragionamento; l'infrastruttura decide cosa l'agente può vedere e fare.
In che modo l'ingegneria degli agenti si differenzia dall'ingegneria dei prompt?
L'ingegneria dei prompt modella una singola istruzione. L'ingegneria dell'infrastruttura dell'agente modella l'intero sistema in cui l'agente opera, attraverso molteplici fasi, strumenti e sessioni. Un prompt è un file all'interno dell'infrastruttura.
Perché l'imbracatura rappresenta un rischio per la sicurezza?
Perché controlla ciò che un agente è autorizzato a fare e risiede in file di testo semplice che raramente vengono esaminati come artefatti di sicurezza. Compromettendo un file di regole o una configurazione MCP, si ottiene il controllo dell'agente, senza toccare il modello.
Chi dovrebbe essere responsabile della sicurezza dell'infrastruttura degli agenti?
Sicurezza delle applicazioni, in collaborazione con gli ingegneri che sviluppano e configurano gli agenti. Il framework è parte integrante del software distribuito, pertanto deve essere sottoposto agli stessi processi di revisione, scansione e inventario del resto del codice.
