Il Red Teaming AI di SK Shieldus passa dai test sui modelli alle azioni degli agenti
Il red teaming AI di SK Shieldus si è esteso oltre le protezioni dei modelli, includendo il comportamento degli agenti, i sistemi medici, i dati connessi e i servizi esterni. Questo ambito più ampio è rilevante perché gli agenti possono agire, non soltanto generare testo non sicuro.
L’azienda afferma che il proprio gruppo di hacker white hat, EQST, sta sviluppando scenari di attacco per sistemi che combinano modelli con applicazioni, informazioni private e strumenti operativi. Il team sta inoltre applicando i propri metodi all’AI medica, dove una decisione manipolata può compromettere la sicurezza dei pazienti.
Non si tratta solo dell’ennesima storia su una gara di hacking. Microsoft, OWASP e ricercatori di sicurezza hanno già dimostrato che il prompt injection può aggirare le difese moderne. SK Shieldus sta ora cercando di trasformare l’esperienza maturata nelle competizioni in test aziendali ripetibili.
Questo cambiamento mette sotto pressione sia i fornitori di sicurezza sia gli acquirenti aziendali. I tradizionali penetration test esaminano i confini del software, le autorizzazioni e le classi di vulnerabilità note. I test sugli agenti devono anche verificare se un’AI segue istruzioni ostili nascoste in informazioni che era autorizzata a leggere.
Cosa ha cambiato SK Shieldus nel red teaming AI
SK Shieldus sta ampliando l’obiettivo, passando da un modello AI isolato all’intero ambiente in cui un agente prende decisioni e compie azioni.
L’azienda ha reso nota l’espansione tramite il gruppo white hat EQST il 18 settembre 2026. Secondo il primo rapporto sulla sicurezza AI, EQST prende di mira modelli, dati connessi, applicazioni, servizi esterni e ambienti per agenti.
Questo perimetro riflette la struttura degli agenti aziendali. In genere, un modello fornisce il livello di ragionamento, mentre il software circostante gli offre accesso a file, messaggi, database e applicazioni aziendali.
Gli attaccanti non devono compromettere ogni componente. Basta un input fidato che modifichi il comportamento dell’agente o un’autorizzazione eccessiva che trasformi un errore in un’azione.
Il prompt injection è centrale in questo problema. Consiste nell’inserire istruzioni malevole nel materiale elaborato da un sistema AI, come email, pagine web, immagini o documenti.
Un attacco indiretto non richiede che un utente digiti il comando ostile. L’agente recupera il contenuto durante un’attività ordinaria e può scambiare il testo incorporato per un’istruzione legittima.
EQST afferma di utilizzare una raccolta proprietaria di scenari di attacco e una metodologia interna di test. L’obiettivo è far emergere rischi di sicurezza che un’organizzazione potrebbe faticare a identificare attraverso le revisioni interne.
Il team ha inoltre contribuito a una guida di red teaming per la sicurezza AI pubblicata dal Ministero della Scienza e delle ICT della Corea del Sud e dalla Korea Internet and Security Agency. La guida del 7 luglio tratta preparazione, esecuzione, organizzazione del team e reportistica.
Questa attenzione al processo è importante. Un jailbreak ingegnoso può attirare l’attenzione, ma una valutazione aziendale richiede obiettivi definiti, prove, classificazioni della gravità, indicazioni per la correzione e un retest affidabile.
L’espansione si collega anche al più ampio approccio di SK Shieldus, che considera gli agenti AI come identità non umane. Si tratta di attori software che necessitano di identità e autorizzazioni controllate perché interagiscono con i sistemi aziendali.
Ad agosto, l’azienda ha dichiarato di estendere le pratiche zero trust agli agenti. Il suo approccio considera ogni richiesta di un agente come qualcosa che richiede verifica dell’identità, autorizzazione limitata e valutazione continua.
Questa espansione zero trust integra il red teaming. I controlli di identità limitano ciò che un agente può raggiungere, mentre i test avversariali esaminano come tali controlli falliscano sotto pressione.
Nessuno dei due elementi è sufficiente da solo. Un agente con un forte ragionamento ma un accesso eccessivo resta pericoloso. Un agente strettamente limitato può comunque esporre dati o produrre raccomandazioni dannose nel proprio ambiente autorizzato.
Il cambiamento più rilevante non è dunque una singola tecnica di attacco. È la decisione di testare l’intera catena tra input non fidato e azione con conseguenze.
Questa catena può includere sistemi di retrieval, selezione degli strumenti, autenticazione, memoria, schermate di approvazione, logging e applicazioni a valle. Ogni collegamento crea un ulteriore punto in cui l’intento può andare perso o l’autorità può essere applicata in modo errato.
Per gli acquirenti, la sicurezza degli agenti di SK Shieldus comporta ora una promessa più ampia. EQST non sta solo verificando se un modello rifiuta richieste proibite. Sta testando se gli agenti implementati si comportano in modo sicuro quando i loro input normali diventano ostili.
Gli agenti AI trasformano i difetti dei modelli in azioni aziendali
Il problema di sicurezza centrale è un’autonomia eccessiva: un output manipolato diventa pericoloso quando il software dispone di autorizzazioni sufficienti per agire su di esso.
Un chatbot potrebbe rispondere a un prompt ostile con testo inaccurato o riservato. Un agente può utilizzare quella stessa risposta manipolata per inviare un messaggio, divulgare un file, modificare un record o chiamare un altro servizio.
OWASP definisce l’autonomia eccessiva attorno a tre comuni difetti di progettazione: funzionalità eccessive, autorizzazioni eccessive e autonomia eccessiva. Le sue linee guida sul rischio di autonomia descrivono come il prompt injection possa attivare azioni dannose tramite strumenti con privilegi eccessivi.
Si consideri un assistente email che deve riassumere una casella di posta. L’accesso in lettura supporta questo scopo. L’autorizzazione a inviare messaggi introduce un’altra capacità che potrebbe non essere necessaria.
Un’email malevola può contenere istruzioni che indirizzano l’assistente a cercare altri messaggi e inoltrare materiale sensibile. L’agente può incontrare tali istruzioni mentre svolge un’attività di recupero autorizzata.
La debolezza attraversa più livelli. Il modello non riesce a distinguere i dati dai comandi, l’applicazione espone uno strumento di invio e l’identità dispone dell’autorizzazione per utilizzarlo.
Un benchmark basato solo sul modello coglie soltanto il primo fallimento. Il red teaming AI di SK Shieldus deve riprodurre l’intero percorso se vuole misurare il rischio operativo.
Microsoft ha fornito un esempio concreto tramite la competizione LLMail-Inject. Il servizio simulato poteva leggere email e agire per conto di un utente, incluso l’invio di messaggi.
Gli attaccanti hanno cercato di inserire istruzioni nelle email che il servizio avrebbe recuperato. Il loro obiettivo era indurre l’assistente a compiere un’azione mai richiesta dall’utente.
La competizione includeva difese quali classificatori di input, analisi dell’attivazione, valutazione basata su modelli e gerarchia delle istruzioni. I partecipanti hanno comunque adattato i loro attacchi a diversi scenari e modelli.
Microsoft ha registrato 621 partecipanti, 224 team e 370.724 invii nella prima sfida. I risultati sul prompt injection illustrano perché una singola valutazione riuscita non possa risolvere la questione.
I difensori modificano filtri, prompt e modelli. Gli attaccanti cambiano quindi formulazione, posizionamento, codifica, lingua o contesto. La sicurezza degli agenti diventa una competizione continua anziché una certificazione una tantum.
Ecco perché anche i dati connessi meritano un esame separato. Gli agenti aziendali acquisiscono materiale da fonti di cui i dipendenti già si fidano, comprese unità condivise, ticket dei clienti, wiki interne e strumenti di collaborazione.
Un payload malevolo può entrare tramite qualunque collaboratore o account compromesso autorizzato a modificare quei contenuti. L’agente potrebbe recuperarlo in seguito senza riconoscere la modifica come un attacco.
Gli input multimodali aggiungono un’altra via. Le istruzioni ostili possono comparire all’interno di un’immagine, di un clip audio o di un video, anziché nel solo testo semplice.
A giugno, il ricercatore EQST Byunghyun Kim ha vinto la competizione di red team AI Judgement Day dopo aver utilizzato il prompt injection multimodale contro scenari di settore. SK Shieldus ha dichiarato che gli attacchi includevano testo nascosto e log falsificati in stile sistema.
La competizione copriva otto scenari, inclusi contesti medici, aeronautici e di risposta ai disastri. Secondo la comunicazione della competizione, altri due ricercatori EQST si sono classificati al quinto e al settimo posto.
Questi risultati dimostrano esperienza pratica nella progettazione di attacchi. Non dimostrano che EQST possa prevenire ogni attacco simile nell’ambiente di un cliente.
La distinzione è importante perché una competizione presenta regole note, obiettivi misurabili e un ambiente di test isolato. Un’implementazione aziendale include integrazioni in evoluzione, dati incoerenti, autorizzazioni ereditate e dipendenti con diverse abitudini di approvazione.
Un incarico aziendale deve tradurre il successo di un attacco in modifiche progettuali. Raccomandazioni utili potrebbero includere ambiti di sola lettura, strumenti circoscritti, validazione deterministica, approvazioni indipendenti e limiti alle azioni ripetute.
Deve inoltre esaminare l’interfaccia di approvazione. Un passaggio di conferma umana offre una protezione limitata quando l’agente redige la descrizione esaminata dalla persona.
Gli attaccanti possono manipolare quella descrizione o nascondere la rilevanza di un’operazione. L’operatore approva quindi un’azione pericolosa credendo che risponda alla richiesta originaria.
L’obiettivo di sicurezza non è quindi soltanto la conformità del modello. È l’esecuzione fedele dell’intento dell’utente attraverso ogni confine attraversato dall’agente.
Il curriculum nelle competizioni costruisce credibilità, non prove
I risultati di EQST nelle competizioni attestano un team di attacco capace, ma gli acquirenti hanno ancora bisogno di prove che tali competenze producano miglioramenti ripetibili nei sistemi implementati.
Il gruppo ha accumulato risultati in diverse forme di test dell’AI e della sicurezza convenzionale. Questa ampiezza offre a SK Shieldus una base credibile per ampliare il proprio red team AI.
Secondo il resoconto dell’azienda, EQST si è classificato secondo nella sfida Re:LLMail-Inject di Microsoft nell’agosto 2025. La gara era incentrata sul prompt injection indiretto adattivo contro un agente basato su email.
Nel giugno 2026, Byunghyun Kim si è classificato primo a Judgement Day. La competizione è durata circa otto settimane e ha testato attacchi contro sistemi AI in scenari industriali ad alto rischio.
Ad agosto, EQST si è classificato quinto a HalCTF, un evento di hacking per agenti AI tenuto presso AI Village durante DEF CON 34. Secondo il rapporto di settembre, hanno partecipato oltre 200 team.
Il team ha inoltre ricevuto un premio principale, un premio di eccellenza e un premio speciale in una sfida di red team AI medico all’inizio di settembre. L’evento ha esaminato sicurezza dei pazienti, cybersecurity, privacy, equità, etica e sicurezza degli agenti.
Questi risultati coprono categorie utili. Gli agenti email rivelano il prompt injection indiretto. I sistemi multimodali testano istruzioni nascoste oltre il normale testo. Gli scenari medici collegano il comportamento dei modelli a decisioni sensibili per la sicurezza.
Tuttavia, le classifiche misurano le prestazioni in condizioni di gara. Raramente rispondono alle domande che un chief information security officer deve risolvere prima dell’implementazione.
Quante criticità ha scoperto un team in un’applicazione simile alla produzione? Quali risultanze si sono riprodotte in modo affidabile? Con quale rapidità gli ingegneri le hanno corrette?
La correzione ha bloccato varianti di attacco correlate o solo il payload inviato? Il sistema ha preservato funzionalità utili dopo l’introduzione di controlli più severi?
Anche i falsi positivi sono rilevanti. Una difesa che blocca documenti normali, messaggi dei clienti o chiamate legittime agli strumenti può rendere un agente inutilizzabile.
I falsi negativi sono ancora più importanti quando il sistema gestisce informazioni sensibili o azioni irreversibili. Gli acquirenti necessitano di misurazioni per entrambi, anziché di un’affermazione generica secondo cui un agente ha superato il red teaming.
Il profilo di rischio del NIST per l’AI generativa raccomanda test avversariali per prompt injection, avvelenamento dei dati, estrazione di modelli e altri attacchi. Richiede inoltre metriche che coprano aggiramenti dei controlli, accessi non autorizzati, tentativi di penetrazione e remediation.
Il profilo di rischio del NIST inquadra il red teaming come una componente della gestione continua del rischio. Non presenta un test riuscito come una garanzia permanente.
Questo crea la sfida principale per il red teaming AI di SK Shieldus. EQST deve trasformare le competenze individuali degli attaccanti in un servizio che produca evidenze comparabili tra clienti, settori e architetture agentiche.
Una valutazione matura dovrebbe iniziare con un inventario degli agenti. I tester devono sapere quali identità, strumenti, dataset, archivi di memoria, modelli e servizi esterni partecipano a ciascun workflow.
Il team deve poi definire scenari di minaccia collegati ai risultati di business. Estrarre una stringa di test innocua è diverso dall’esporre dati dei pazienti, modificare una registrazione di pagamento o cambiare una configurazione di produzione.
I tester dovrebbero registrare l’intero percorso di attacco. Ciò include l’input ostile, l’evento di retrieval, la decisione del modello, la chiamata allo strumento, il controllo dei permessi, la fase di approvazione e il risultato finale.
La remediation deve affrontare il percorso, non il prompt. Bloccare una frase specifica offre poca protezione se un attaccante può parafrasarla o inserirla in un altro formato di dati.
Una correzione più solida potrebbe ridurre i permessi, separare le istruzioni affidabili dai contenuti non affidabili, convalidare gli argomenti degli strumenti o richiedere a un sistema indipendente di approvare un’azione ad alto rischio.
Il retest necessita quindi di nuove varianti di attacco. In caso contrario, la valutazione conferma solo che gli sviluppatori hanno bloccato l’esempio noto.
SK Shieldus non ha fornito pubblicamente metriche dettagliate sugli esiti aziendali per questo servizio ampliato. L’annuncio di settembre non specifica tassi di rilevamento, risultati dei retest, volume degli incarichi o tempi di remediation dei clienti.
Questa assenza non invalida la capacità. Limita ciò che gli acquirenti possono dedurre da premi e dichiarazioni aziendali.
Il passo successivo più persuasivo sarebbe costituito da evidenze anonimizzate provenienti da valutazioni reali. Informazioni utili mostrerebbero categorie di attacco, livelli coinvolti, gravità, modelli di remediation e ricorrenza dopo le correzioni.
Fino ad allora, il curriculum di EQST dovrebbe essere letto come prova di competenza offensiva. Non è ancora una dimostrazione pubblica di riduzione coerente del rischio nelle implementazioni enterprise.
L’AI medica aumenta il costo di un errore
L’AI medica rende più difficile il red teaming degli agenti perché sicurezza, privacy, sicurezza clinica e supervisione umana possono fallire nello stesso workflow.
Un assistente medico può riassumere informazioni sui pazienti, recuperare riferimenti clinici, programmare le cure o raccomandare un’azione successiva. Ogni attività può coinvolgere dati sensibili e decisioni dipendenti dal fattore tempo.
Il rischio cambia nuovamente quando un’AI diventa un agente. Può collegarsi a cartelle cliniche, fonti di conoscenza esterne, sistemi di comunicazione o dispositivi medici anziché limitarsi a generare una risposta.
Un’istruzione iniettata potrebbe distorcere le evidenze recuperate dall’agente. Potrebbe inoltre influenzare una raccomandazione, esporre informazioni personali o dirigere uno strumento oltre il suo compito previsto.
Un filtro di sicurezza sul modello sottostante non può ispezionare ogni conseguenza a valle. L’applicazione circostante deve applicare limiti di accesso, convalidare gli output e preservare decisioni umane responsabili.
La 2026 Advanced AI Digital Medical Products Red Team Challenge riflette questo problema più ampio. I partecipanti hanno testato modalità per aggirare le protezioni relative a sicurezza dei pazienti, privacy, equità, etica, cybersecurity e sicurezza degli agenti.
I premi ottenuti da EQST suggeriscono che il team possa operare in queste categorie. SK Shieldus afferma che l’esperienza lo sta aiutando a estendere il red teaming AI agli ambienti medici.
Tuttavia, una challenge resta distinta da un programma di validazione clinica. I sistemi medici operano secondo workflow specifici, popolazioni di pazienti, vincoli sui dati e responsabilità professionali.
Un red team può identificare un percorso di attacco. Da solo non può determinare l’efficacia clinica, il rischio residuo accettabile o la corretta ripartizione delle responsabilità tra software e clinici.
Questo limite dovrebbe plasmare la progettazione del servizio. I risultati di sicurezza devono connettersi con l’ingegneria della sicurezza, la revisione della privacy, la governance del prodotto e il monitoraggio post-deployment.
Per esempio, un agente potrebbe recuperare un documento errato dopo aver incontrato metadati manipolati. Il problema immediato appare come un problema di integrità del retrieval.
L’impatto clinico dipende da ciò che segue. Un assistente a basso rischio può mostrare una fonte per la revisione umana. Un sistema più autonomo potrebbe usare il documento per dare priorità a un paziente o raccomandare un intervento.
La stessa debolezza tecnica comporta quindi una gravità diversa tra le implementazioni. I report di red teaming devono tenere conto dei permessi effettivi, dell’autorità decisionale e delle opportunità di correzione umana.
I test medici necessitano inoltre di casi limite rappresentativi. Un sistema può comportarsi in modo sicuro con un linguaggio ordinario ma fallire quando le cartelle contengono abbreviazioni, note contraddittorie, annotazioni di immagini o testo esterno copiato.
Gli attaccanti possono sfruttare tali ambiguità. Possono anche imitare formattazioni affidabili, dichiarazioni di autorità, avvisi di sistema o istruzioni cliniche.
Il risultato di Judgement Day offre un indizio rilevante. Secondo quanto riportato, EQST ha aumentato il successo degli attacchi creando input simili ai log di sistema e prendendo di mira eccezioni assenti dal system prompt.
Questo metodo attacca i segnali di fiducia, non solo le parole proibite. Verifica se l’AI sa distinguere la fonte e l’autorità delle informazioni all’interno di un contesto complesso.
Una cartella clinica contiene molti segnali di questo tipo. Le note provengono da professionisti, sistemi, momenti e livelli di certezza diversi. Un agente non deve trattare ogni stringa come un’istruzione dotata della stessa autorità.
Il problema evidenzia anche un compromesso. Aggiungere un contesto ampio può migliorare l’utilità dell’agente, ma ogni nuova fonte amplia la superficie di input non affidabile.
Concedere più strumenti può ridurre il lavoro amministrativo, ma ogni strumento aggiunge possibili azioni. Una maggiore autonomia può abbreviare un workflow riducendo al contempo il tempo disponibile per la revisione.
Le organizzazioni non possono risolvere queste tensioni con un prompt universale. Hanno bisogno di controlli architetturali allineati alle conseguenze di ciascuna azione.
Il retrieval a basso rischio può procedere automaticamente con logging. La divulgazione di dati sensibili può richiedere la convalida delle policy. Una modifica clinica o operativa può necessitare di un’approvazione umana indipendente.
L’interfaccia utente deve mostrare chiaramente l’azione prevista, la cartella interessata, la fonte delle informazioni e il permesso utilizzato. Non dovrebbe basarsi soltanto su un riepilogo generato dall’agente.
L’AI medica offre a SK Shieldus un banco di prova impegnativo. Il successo dimostrerebbe che EQST sa collegare gli exploit tecnici ai controlli operativi critici per la sicurezza.
Il fallimento rivelerebbe la debolezza di trattare il red teaming AI come un penetration test esteso. La sicurezza degli agenti richiede una visione più ampia della qualità decisionale, dell’autorità e della responsabilità umana.
Il vero test è la ripetibilità enterprise
SK Shieldus deve dimostrare che il suo red team AI può produrre risultati coerenti anche quando modelli, strumenti, fonti dati e permessi continuano a cambiare.
Il testing delle applicazioni tradizionali parte spesso da una release relativamente stabile. Un agente può cambiare comportamento dopo un aggiornamento del modello, una revisione del prompt, una modifica del connettore o un adeguamento dei permessi.
Una nuova fonte documentale può introdurre contenuti ostili. Un nuovo strumento può aumentare l’impatto di una debolezza esistente del modello. Un flusso di approvazione rivisto può creare un nuovo percorso per aggirare la supervisione umana.
Questa volatilità rende inadeguati i test annuali per le implementazioni importanti. Le organizzazioni necessitano di valutazioni prima del rilascio, dopo modifiche sostanziali e durante le operazioni in corso.
Gli attacchi automatizzati possono aiutare nella copertura. Possono generare varianti dei prompt, testare diversi contesti e ripetere scenari tra modelli.
L’automazione ha anche dei limiti. Tende a ottimizzare rispetto a obiettivi misurabili e può non cogliere presupposti organizzativi che un attaccante umano metterebbe in discussione.
Gli specialisti umani possono individuare tali presupposti. Potrebbero notare che un agente di sola lettura può comunque creare una raccomandazione dannosa o che una schermata di approvazione nasconde gli effettivi argomenti dello strumento.
Il servizio più solido combinerà entrambi gli approcci. I controlli automatizzati offrono frequenza e copertura delle regressioni, mentre i red team umani esplorano percorsi di attacco inattesi.
Il database di scenari di SK Shieldus potrebbe supportare questo modello. Gli attacchi riutilizzabili possono diventare test di regressione dopo che i ricercatori li hanno convalidati rispetto a un sistema reale.
Tuttavia, la libreria deve evolvere. Gli esempi pubblici diventano rapidamente dati di addestramento per i difensori, mentre gli attaccanti cambiano codifica, contesto, lingua e formato di distribuzione.
La ricerca di Microsoft illustra questo ciclo. Dopo il primo round, la competizione aggiornata ha aggiunto una blocklist ad alta precisione, sanitizzazione, classificatori più robusti e istruzioni riviste.
I ricercatori hanno poi ricevuto un’altra opportunità di adattarsi. Questo processo rispecchia la sicurezza enterprise reale, in cui la mitigazione di ieri diventa il bersaglio dei test di domani.
La ripetibilità dipende anche dal reporting. Due valutatori dovrebbero applicare criteri di gravità comparabili anche quando la loro creatività negli attacchi differisce.
I report dovrebbero separare le vulnerabilità del modello dai fallimenti dell’applicazione. Dovrebbero inoltre identificare debolezze nell’identità, nella progettazione dei permessi, nella provenienza dei dati, negli strumenti e nelle interfacce utente.
Un’unica etichetta come “prompt injection” nasconde troppo. Un attacco può rivelare testo indesiderato, mentre un altro può attivare un pagamento o esporre un intero repository documentale.
La gravità dovrebbe riflettere dati raggiungibili, azioni disponibili, accesso richiesto all’attaccante, coinvolgimento dell’utente, rilevabilità, reversibilità e conseguenze per il business.
Le organizzazioni hanno inoltre bisogno di prove che le correzioni riducano il rischio senza distruggere il valore dell’agente. Un controllo che disabilita ogni documento esterno può fermare l’injection, ma vanificare il workflow.
È qui che la partecipazione degli acquirenti diventa essenziale. I team di sicurezza definiscono il rischio accettabile, ma i responsabili di prodotto comprendono il compito che l’agente deve continuare a svolgere.
Gli sviluppatori sanno dove i controlli deterministici possono sostituire il giudizio del modello. I team di identity possono limitare gli scope, mentre i team di compliance chiariscono gli obblighi di logging e conservazione.
Anche i knowledge worker influenzano l’esposizione. Decidono quali documenti entrano nei sistemi condivisi e se l’output di un agente riceve una revisione significativa.
Confini informativi chiari possono ridurre il pericolo. I team dovrebbero identificare istruzioni affidabili, contenuti non affidabili, fonti sensibili e azioni che richiedono un’autorizzazione separata.
Una knowledge base ricercabile può migliorare la gestione del contesto, ma il solo retrieval non stabilisce la fiducia. Provenienza e permessi determinano ancora come gli agenti dovrebbero usare il materiale.
Le organizzazioni dovrebbero evitare di trasformare i risultati del red team in ticket isolati. I risultati devono aggiornare standard architetturali, policy dei connettori, regole di approvazione e suite di regressione.
La sicurezza degli agenti di SK Shieldus diventerà più credibile quando i clienti potranno confrontare i risultati nel tempo. Un programma utile dovrebbe mostrare se i percorsi critici si riducono dopo ogni ciclo di test.
L’azienda potrebbe anche pubblicare una tassonomia anonimizzata mappata sulle architetture agentiche comuni. Ciò aiuterebbe gli acquirenti a capire se la copertura degli scenari corrisponde alle loro implementazioni.
Un’ulteriore convalida indipendente rafforzerebbe il caso. Benchmark esterni, metodi sottoposti a peer review o criteri di valutazione trasparenti possono distinguere una capacità ripetibile dal linguaggio di marketing.
La tensione centrale resta semplice. Gli agenti diventano più utili quando ricevono contesto e autorità, ma queste stesse caratteristiche aumentano le conseguenze della manipolazione.
Il red teaming AI di SK Shieldus mira proprio a questa tensione. Il suo valore nel lungo periodo dipenderà dalla capacità di EQST di misurarlo in modo coerente e di guidare i clienti verso progettazioni più sicure.
Cosa dovrebbero osservare gli acquirenti
Tre segnali indicheranno se SK Shieldus ha costruito una disciplina enterprise o ha semplicemente esteso la narrazione di una competizione di successo.
Il primo segnale è una metodologia pubblicata. Gli acquirenti dovrebbero cercare una descrizione chiara di come EQST definisce l’ambito degli agenti, mappa le superfici d’attacco, classifica i risultati e svolge i test di verifica.
Una metodologia utile dovrebbe coprire il modello, il livello di retrieval, la memoria, l’identità, le autorizzazioni, gli strumenti, le fonti dati e le interfacce di approvazione. Dovrebbe inoltre distinguere gli attacchi diretti dalla prompt injection indiretta.
Se SK Shieldus pubblicherà criteri ripetibili, sarà più facile valutare la sua espansione nei vari settori. Se il processo resterà opaco, i clienti dovranno valutare le capacità caso per caso.
Il secondo segnale è costituito dalle evidenze provenienti da sistemi implementati. Casi di studio anonimizzati dovrebbero riportare quali percorsi d’attacco sono emersi, come i clienti li hanno corretti e se le varianti sono riuscite dopo la mitigazione.
Le evidenze più solide includerebbero tassi di rilevamento, falsi positivi, risultati critici, esiti dei retest e tempi di mitigazione. Dovrebbero evitare di presentare un test pulito come prova di sicurezza permanente.
Le prove fornite dai clienti rafforzerebbero l’affermazione centrale dell’azienda. Un’attenzione costante verso classifiche e premi lascerebbe invece incerto l’impatto operativo.
Il terzo segnale è l’integrazione tra test e governance degli agenti. SK Shieldus ha già collegato gli agenti a identità non umane e controlli zero-trust.
Gli acquirenti dovrebbero verificare se i risultati del red team alimentano automaticamente autorizzazioni, monitoraggio, policy dei connettori e requisiti di approvazione. Questo ciclo di feedback trasformerebbe gli attacchi in controlli duraturi.
Il segnale si indebolisce se il red teaming resta un’attività di consulenza separata. I report spesso perdono valore quando le loro raccomandazioni non raggiungono mai i sistemi di identità, gli standard di ingegneria o le barriere di distribuzione.
Anche l’attività dei concorrenti conterà, ma dovrebbe restare un contesto di supporto. Microsoft e la più ampia comunità della sicurezza continuano a sviluppare difese, benchmark e modelli progettuali contro la prompt injection indiretta.
Questi sforzi alzano le aspettative per ogni fornitore. Rivendicare competenze nella prompt injection non è più sufficiente, quando la ricerca pubblica documenta già attacchi adattivi contro difese stratificate.
Prima di commissionare un test, gli acquirenti enterprise dovrebbero porre una serie di domande dirette. Quali workflow completi verranno attaccati dal team e quali azioni rilevanti si trovano alla fine di ciascun percorso?
Dovrebbero chiedere se i tester possono esaminare il codice applicativo, i prompt, le definizioni degli strumenti, gli ambiti di accesso e i log. I test black-box offrono una prospettiva, ma l’accesso interno può rivelare errori di progettazione più profondi.
Dovrebbero richiedere retest con varianti d’attacco dopo la mitigazione. Dovrebbero inoltre esigere prove che i nuovi controlli preservino le attività legittime.
Infine, dovrebbero identificare chi è responsabile del rischio irrisolto. Il red team può portare alla luce un fallimento, ma i responsabili aziendali devono decidere se ridurre le autorizzazioni, aggiungere una revisione, riprogettare il workflow o rinviare la distribuzione.
SK Shieldus ha costruito un credibile storico offensivo e ha scelto un obiettivo importante. Gli agenti AI creano un problema di sicurezza che coinvolge modelli, software, identità, dati e decisioni umane.
La fase successiva è più difficile che vincere una competizione. EQST deve dimostrare che il red teaming AI di SK Shieldus produce evidenze ripetibili e comportamenti enterprise più sicuri.
Per i team che stanno distribuendo agenti oggi, la domanda pratica non è se un modello possa essere ingannato. Le competizioni pubbliche hanno già risposto a questa domanda.
La decisione riguarda il fatto che ciascun agente disponga di autorità sufficiente per trasformare la manipolazione in danno. Mappate quel percorso, limitate gli accessi non necessari e testate l’intero workflow prima di affidare all’agente attività con conseguenze rilevanti.
