Un'analisi pubblicata da The Hacker News sostiene che gran parte della sicurezza dell'IA in azienda punta sul bersaglio sbagliato. Il pezzo, contribuito da un partner e con materiale promozionale, afferma che i controlli pensati per l'IA che un'azienda ha deliberatamente adottato non intercettano gli agenti che arrivano dentro software già in uso. Si tratta di un articolo d'opinione. Non descrive una violazione, una vulnerabilità o un'azione di contrasto.
Tre modi in cui un agente entra in azienda
L'autore classifica gli agenti in base a come arrivano:
- Ereditati: distribuiti all'interno di una piattaforma esistente tramite un normale aggiornamento del prodotto.
- Configurati: costruiti a partire dai prompt e dalla logica dell'azienda, ma in esecuzione su runtime, modello e connettori del fornitore.
- Costruiti: assemblati da framework aperti su infrastrutture di proprietà dell'azienda.
Secondo l'autore, i primi due gruppi rappresentano la «stragrande maggioranza» dell'adozione e crescono in modo «esponenziale». Gli agenti costruiti sono descritti come il gruppo più piccolo e con la crescita più lenta. Il pezzo non offre alcuna misurazione a sostegno di queste caratterizzazioni.
La conseguenza, nella ricostruzione dell'autore, è che nessuno decide di adottare un agente ereditato. Compare con un aggiornamento, quindi la verifica che di solito precede una nuova distribuzione di IA non avviene mai.
Un dato da un rapporto senza nome
L'articolo cita il «2026 State of Agent Security Report», che però non è ricondotto a un editore né descritto nel metodo o nel campione. Secondo quel rapporto, circa 1.280 prodotti di terze parti negli ambienti studiati integrano l'IA. Circa 282 di questi si trovano dietro il single sign-on.
L'autore interpreta il divario come un'area in cui «gli altri mille» restano invisibili per impostazione predefinita all'infrastruttura di identità. Si tratta di conteggi di prodotti, non di agenti o di persone. Gli altri esempi di scala dell'articolo, come cinquanta, cinquecento e cinquemila agenti, sono illustrazioni e non dati.
L'esempio di Slack Code
Il caso di studio principale dell'autore è Slack Code, che secondo l'articolo Salesforce ha lanciato ad agosto 2026. Un utente inserisce l'agente di programmazione in una conversazione con un tag. L'agente legge il contesto condiviso, scrive codice e apre pull request, con accesso a GitHub e all'infrastruttura di produzione, secondo l'articolo.
L'annuncio di Salesforce, citato nel pezzo, afferma che gli agenti «ereditano dal primo giorno il modello di sicurezza integrato di Slack, i permessi e i controlli amministrativi, senza alcun intervento IT aggiuntivo». L'articolo mette questa promessa a confronto con la portata più ampia dell'agente, che va oltre Slack stesso.
Dove l'autore colloca il rischio
Il pezzo sostiene che il rischio risieda soprattutto nell'impalcatura dell'agente e nell'ecosistema che lo circonda, non nel modello sottostante. Propone quattro aree da verificare:
- Identità: quale agente sta agendo e per conto di chi.
- Permessi: che cosa è autorizzato a fare.
- Connettività: il raggio d'azione, incluso ciò che può raggiungere indirettamente attraverso altri sistemi.
- Attività: una valutazione basata sul comportamento osservato, non sulle intenzioni dichiarate.
Opet e l'AI Act
L'autore cita Patrick Opet, CISO globale di JPMorgan Chase. Secondo l'articolo, nel 2025 Opet ha descritto la catena di fornitura di terze parti come un rischio sistemico. Aggiunge che gli incidenti erano abbastanza gravi da spingere la banca a isolare i fornitori compromessi, punto ribadito in una lettera aperta. L'articolo non fornisce dettagli su quegli incidenti.
L'autore attribuisce inoltre a Opet la posizione secondo cui un agente dovrebbe ricevere un'identità ma nessuna autorizzazione per impostazione predefinita. Prima che tocchi qualsiasi cosa al di fuori del proprio perimetro, l'IT dovrebbe confermare per conto di chi agisce.
Sul piano normativo, l'autore sostiene che l'AI Act dell'UE, i cui obblighi si applicano in fasi fino al 2026, presuppone che le aziende possano inventariare i propri sistemi di IA, nominarne i responsabili e documentare la supervisione. Secondo il pezzo, ciò è difficile quando gli agenti arrivano senza preavviso dentro i prodotti dei fornitori.
La prospettiva dei fornitori
L'articolo indica Reco, con la sua piattaforma Reco Graph, come «esempio di riferimento» di uno strumento che collega identità umane e non umane, applicazioni, permessi e azioni degli agenti in un'unica vista in tempo reale. Il pezzo proviene da un partner, quindi quell'endorsement è una presa di posizione del collaboratore. Il rilevamento degli agenti di Reco è citato in reco.ai/platform.
Per i team di sicurezza, l'indicazione pratica è più ristretta del messaggio commerciale. La tesi è che l'inventario degli agenti debba partire dalle applicazioni SaaS già in uso, non da un elenco di progetti di IA approvati.
