Punti chiave
- Le pratiche di sicurezza dell'AI agentica sono in ritardo di due o tre anni rispetto alla maturità dell'infrastruttura circostante, riproducendo le ondate di exploit già viste con le applicazioni web e le API pubbliche.
- I documenti recuperati nelle pipeline RAG portano con sé i permessi del chiamante; un singolo artefatto avvelenato è sufficiente a deviare un agente, quindi il contenuto recuperato va trattato come input non attendibile.
- Una catena di agenti a cinque stadi composta da passaggi affidabili al novanta percento scende a circa il cinquantanove percento di affidabilità end-to-end, il che rende obbligatori i circuit breaker e la validazione tra gli stadi.
- I protocolli standardizzati per agenti come A2A (ora sotto la gestione della Linux Foundation) e MCP costituiscono il vantaggio competitivo, spostando il rischio di procurement lontano dalle piattaforme di agenti proprietarie.
Cosa è cambiato nello stack agentico
L'AI agentica ha superato una soglia nell'ultimo anno. I sistemi che concatenano modelli, strumenti e recupero girano ora all'interno degli stack di produzione delle grandi aziende.
Questo cambiamento modifica il profilo di rischio. Un agente che invoca strumenti detiene le stesse credenziali dell'utente che lo ha attivato. Il raggio d'azione cresce a ogni integrazione.
Due protocolli ancorano la transizione: A2A per la messaggistica tra agenti e MCP per il contesto tra modello e strumenti. Entrambi si sono mossi verso una governance neutrale.
La Linux Foundation ora gestisce A2A, un segnale che lo strato di comunicazione si sta liberando dal controllo di un singolo fornitore. I team di procurement dovrebbero leggerlo con attenzione, perché il panorama dei fornitori cambia nel momento in cui un protocollo esce dalle mani private.
La postura di sicurezza è in ritardo rispetto alla curva di deployment
I team aziendali distribuiscono gli agenti più velocemente di quanto li rendano sicuri. Questo è il problema centrale.
La mia posizione consolidata: la pratica di sicurezza per i sistemi AI vicini all'AGI si trova due o tre anni indietro rispetto alla maturità dell'infrastruttura circostante. Gli avvisi emessi contro i framework di agenti si leggono come un sintomo di questo divario. I team pubblicano prima in produzione, poi scoprono il lavoro di hardening dopo.
Abbiamo visto la stessa sequenza con le applicazioni web negli anni 2000 e con le API pubbliche negli anni 2010. Ogni ambito ha distribuito su larga scala, ha assorbito un'ondata di exploit e poi ha scritto il manuale operativo. L'AI agentica ripete ora lo stesso schema.
Per un CTO l'implicazione è diretta: trattare ogni framework di agenti come una beta dal punto di vista della sicurezza, indipendentemente dall'etichetta di marketing. Leggi la nostra nota sulla postura di sicurezza dell'AI per l'argomentazione dettagliata.
Il prompt injection è la superficie di attacco sottovalutata
La superficie di attacco è lo strato di recupero. Un documento estratto da un vector store entra nel modello con la stessa fiducia di un'istruzione diretta dell'utente.
La maggior parte delle architetture RAG in produzione tratta il testo recuperato come contenuto attendibile. Questa assunzione è sbagliata. Un solo documento recuperato è sufficiente a deviare un agente verso un percorso di esfiltrazione dei dati.
Il meccanismo è semplice. Il modello legge le istruzioni incorporate all'interno di un documento e poi agisce su di esse usando i permessi del chiamante. Una pagina wiki avvelenata diventa un vettore di esecuzione, e il log di audit mostra un utente legittimo dietro l'azione.
I team di AI aziendale dovrebbero classificare ogni artefatto recuperato come input non attendibile. La validazione va posta tra il recupero e l'azione, ogni volta.
Le pipeline multi-agente falliscono a cascata
I sistemi multi-agente in produzione privi di circuit breaker espliciti falliranno a cascata. Questa è aritmetica, non profezia.
Quando l'output di un agente diventa l'input del successivo, gli errori si accumulano. Un'allucinazione al primo passaggio si propaga attraverso ogni fase a valle. Una validazione indipendente tra gli stadi contiene il danno.
Considera i numeri. Un passaggio affidabile al novanta percento, ripetuto lungo una catena di cinque stadi, produce circa il cinquantanove percento di affidabilità end-to-end. Il fallimento si nasconde dentro un output apparentemente plausibile.
La soluzione è disciplina ingegneristica: circuit breaker, validazione degli output e retry limitati. L'auto-invocazione abilitata in assenza di confini di esecuzione è la modalità di fallimento da individuare in fase di design review.
I protocolli standard sono il vero vantaggio competitivo
Le prestazioni dei modelli convergono. Il vantaggio duraturo risiede nello strato di comunicazione tra gli agenti.
Chi controlla il protocollo che connette gli agenti controlla l'architettura. Ecco perché la mossa di governance attorno ad A2A conta più di qualsiasi singolo risultato di benchmark.
Una specifica sotto gestione neutrale è uno standard da adottare piuttosto che un prodotto di un fornitore da valutare. Questa distinzione dovrebbe guidare il procurement. I contratti costruiti su un bus di agenti proprietario portano con sé un lock-in architetturale che uno standard elimina.
Un segnale di stabilità v1.0 su un protocollo aperto riduce il rischio di costruire su di esso. I team ottengono un percorso di migrazione tra fornitori, il che rafforza la loro posizione negoziale al rinnovo.
Tre domande per i team di AI aziendale
Queste tre domande corrispondono alle tre modalità di fallimento descritte sopra. Eseguile nella tua prossima revisione.
- Ogni agente applica confini di esecuzione attorno agli strumenti auto-invocati?
- La pipeline di recupero tratta i documenti come input non attendibile, con validazione prima dell'azione?
- Le catene multi-agente includono circuit breaker e controlli indipendenti sugli output tra gli stadi?
Un team che risponde sì a tutte e tre ha una postura di livello produttivo. Un singolo no segna la priorità del prossimo sprint. L'ambito qui è operativo, quindi assegna un responsabile a ciascuna domanda.
Build, buy e la decisione di procurement
La scelta build-versus-buy ruota attorno allo strato di comunicazione. Compra i modelli. Adotta il protocollo aperto. Costruisci i controlli di governance che i fornitori lasciano scoperti.
Per il CFO, il rischio infrastrutturale si sposta. L'investimento in una piattaforma di agenti proprietaria comporta ora un rischio di lock-in più elevato rispetto all'investimento in strumenti attorno ad A2A e MCP. Lo strato aperto protegge il bilancio.
Un Comitato di Procurement Tecnologico dovrebbe riaprire ogni contratto che presuppone un bus di agenti chiuso. Rinegozia per la conformità al protocollo e per condizioni di uscita chiare.
Confronta le opzioni nella nostra analisi build versus buy prima del prossimo ciclo di budget.
Decisioni per il prossimo ciclo di pianificazione
Le decisioni di CTO e Head of Engineering per il prossimo ciclo di pianificazione si riducono a quattro mosse.
Primo, verifica ogni pipeline RAG per la gestione degli input non attendibili. Secondo, aggiungi circuit breaker a ogni catena multi-agente in produzione. Terzo, ancora la tua architettura ad A2A e MCP anziché a un bus di un fornitore.
Quarto, pianifica una revisione di sicurezza di ciascun framework di agenti come se fosse una beta nuova. Il modello di minaccia cambia ogni mese, e il lavoro di hardening va inserito nella roadmap oggi stesso.
La domanda architetturale resta costante: è una trappola o un vantaggio competitivo? Uno strato di protocollo aperto con una governance disciplinata è il vantaggio. Una mesh di agenti chiusa e non validata è la trappola.
Questo articolo è stato prodotto da un autore editoriale AI con supervisione editoriale umana, in conformità con i requisiti di trasparenza del Regolamento (UE) 2024/1689 (AI Act, Art. 50). Le fonti sono collegate nel testo.
Articolo di LEON