Injecció de prompts: la seguretat del teu agent és als permisos, no al prompt

«Què és el pitjor que pot fer el vostre agent si el text que llegeix l'escriu un desconegut?» A la meitat de les reunions la resposta comença igual: bé, al prompt de sistema li diem que mai…. I aquí és on convé aturar-se, perquè el prompt de sistema no és un control. És una petició. Viu al mateix lloc que l'atac —el context— i es llegeix amb les mateixes regles que el text hostil que acaba d'entrar.

Aquesta peça va d'on sí que es decideix. Avanço la tesi perquè es pugui discutir des del primer paràgraf: la seguretat d'un agent no es decideix al seu prompt, es decideix a la taula de permisos de les seves eines. Tot el que viu dins del context és dins del radi de l'explosió; només allò que s'avalua fora del model —a la passarel·la, al client que executa la crida, a l'IAM— continua sent un control quan el model ja ha estat convençut.

A l'article sobre LLMOps descrivim el cicle complet d'un sistema en producció i a el del gap de qualitat, què es trenca quan arriba el trànsit real. Aquest és el que faltava a sota dels dos: què passa quan el trànsit real, a més, és hostil.

El dia que la dada va començar a donar ordres

La formulació canònica és del febrer de 2023. Kai Greshake, Sahar Abdelnabi i els seus coautors van publicar Not what you've signed up for, on argumenten que les aplicacions integrades amb LLM difuminen la línia entre dades i instruccions, i demostren atacs pràctics contra sistemes reals de l'època —el Bing Chat amb GPT-4 i motors d'autocompletat de codi— injectant instruccions en contingut que el sistema recuperaria. La seva taxonomia ja llistava el que avui veiem als informes d'incidents: robatori de dades, propagació tipus cuc, contaminació de l'ecosistema d'informació i control sobre quines APIs es criden i com.

La distinció operativa és la que recull OWASP a LLM01:2025, el primer risc del seu top ten per a aplicacions LLM. Directa: l'usuari escriu el text que altera el comportament. Indirecta: el contingut arriba des d'una font externa —una web, un fitxer, un correu— i altera el comportament sense que ningú de l'equip l'escrigui. La segona és la que importa en una empresa, i per una raó incòmoda: l'atacant mai no parla amb el teu agent. Escriu el tiquet, el correu, el PDF, el comentari del pull request o la pàgina que el teu agent llegirà demà com a part de la seva feina normal.

El NCSC britànic va publicar el desembre de 2025 l'advertència més clara que ha fet un organisme públic sobre això: la injecció de prompts potser no es mitigarà mai del tot com es mitiga la injecció SQL. El motiu no és la manca d'esforç. En SQL es pot imposar una separació estricta entre instruccions i dades —això és exactament el que fa una consulta parametritzada—, i dins d'un model de llenguatge aquesta separació no existeix: tot token és candidat a interpretar-se com a instrucció. La seva recomanació és la que ordena la resta d'aquesta peça: deixar de perseguir el «com l'aturo» i treballar sobre el risc i l'impacte, assumint que aquests sistemes són intrínsecament confusibles.

Abans de continuar convé aclarir quatre confusions, perquè cadascuna porta a comprar la solució equivocada.

Per què no es pedaça, i per què això no és pessimisme

OWASP enumera set mesures de prevenció per a LLM01 —restringir el comportament amb el prompt de sistema, validar formats de sortida, filtrar entrada i sortida, control de privilegis mínims, aprovació humana per a accions de risc, segregar i identificar el contingut extern i proves adversàries— i tot seguit escriu la frase que gairebé ningú no cita: atesa la influència estocàstica al cor del funcionament dels models, no és clar que existeixin mètodes de prevenció infal·libles. És una llista de mitigacions que es presenta a si mateixa com a incompleta, i fa bé.

La mesura més dura de fins a quin punt és incompleta la van publicar l'octubre de 2025 Milad Nasr, Nicholas Carlini, Florian Tramèr i onze autors més a The Attacker Moves Second. Van agafar dotze defenses publicades —de prompt, d'entrenament adversari, de filtratge i de coneixement secret— i les van atacar amb adversaris adaptatius: descens de gradient, aprenentatge per reforç, cerca aleatòria i exploració guiada per humans. La majoria d'aquestes defenses havia reportat taxes d'èxit d'atac properes a zero. Sota atac adaptatiu, la majoria va superar el 90%. No és que les defenses fossin dolentes: és que s'havien avaluat contra un atacant que no s'adapta, i l'atacant real s'adapta.

Simon Willison ho diu de la manera més útil per a una decisió de compra. Els productes de guardrail es venen amb xifres de captura del 95%, i en seguretat el 95% és un suspens: l'atacant no llança cent atacs i es conforma amb la mitjana, llança fins a trobar el que passa. Un percentatge alt de detecció és una bona notícia per al cost de l'atac i una mala base per a una garantia.

La trifecta letal i la regla de dos

El juny de 2025 Willison va posar nom a la combinació que converteix un text hostil en una fuita: la trifecta letal. Tres capacitats al mateix agent i a la mateixa sessió — accés a dades privades, exposició a contingut no fiable i capacitat de comunicar-se cap enfora. Amb les tres, l'atac té entrada, botí i sortida. Amb dues, l'incident es queda dins.

El 31 d'octubre de 2025, Meta va publicar la versió operativa de la mateixa idea: la regla de dos. Un agent ha de complir com a màxim dues d'aquestes tres propietats dins d'una sessió: [A] processar entrades no fiables, [B] tenir accés a sistemes sensibles o dades privades, [C] canviar estat o comunicar-se amb l'exterior. I hi afegeix la clàusula que fa que la regla sigui aplicable de debò: si un agent necessita les tres sense obrir una sessió nova —amb finestra de context neta—, no ha d'operar de manera autònoma i necessita com a mínim supervisió humana o una altra validació fiable.

El que fa valuosa aquesta regla per a un comitè tècnic no és la seva precisió formal, és que converteix una discussió irresoluble sobre robustesa de models en una decisió d'arquitectura amb tres caselles, que qualsevol pot auditar en una pissarra sense ser especialista en seguretat d'IA.

D'aquesta taula en surt una recomanació que apliquem des que la regla es va popularitzar, i que gairebé sempre sorprèn l'equip: talla per la C. El valor d'un agent empresarial normalment és a A i B —llegir el que arriba de fora i creuar-ho amb el que sap la casa—, mentre que la C, que la resposta surti sola sense que ningú la miri, és la que menys valor afegeix i la que converteix una fallada en una fuita. I quan es talla, es talla amb llista blanca de destinacions, no amb llista negra: els dos incidents que vénen a continuació van sortir per camins que cap llista negra raonable no hauria contemplat.

Dos incidents que ensenyen el mecanisme

EchoLeak. Publicat l'11 de juny de 2025 com a CVE-2025-32711, descobert per Aim Security a Microsoft 365 Copilot. Un correu. L'usuari no l'havia d'obrir ni fer clic enlloc: n'hi havia prou que arribés a la bústia i que Copilot el tingués dins del seu abast de recuperació. La càrrega anava amagada on l'humà no la veu i el sistema sí, i la cadena encadenava quatre salts: esquivar el classificador d'intents d'injecció de Microsoft, sortejar la redacció d'enllaços amb markdown de referència, aprofitar imatges que el client carrega automàticament i abusar d'un proxy de Teams que la política de seguretat de contingut permetia. Microsoft la va puntuar com a crítica —9,3—, tot i que la fitxa del NVD la deixa en 7,5; la va pedaçar al servidor i afirma que no hi va haver explotació real.

El que ensenya no és la creativitat de la cadena. És que totes les capes que van fallar eren probabilístiques o de sanejament —un classificador, una redacció d'enllaços— i la que hauria tallat el dany era determinista: no carregar recursos remots, no permetre destinacions fora d'una llista. El canal d'entrada, a més, era perfectament legítim: rebre correu.

El flux tòxic de GitHub. El 26 de maig de 2025, Invariant Labs va descriure el mateix mecanisme en un lloc on fa més mal. Un issue en un repositori públic amb instruccions amagades; un agent connectat al servidor MCP oficial de GitHub amb un token que també veia repositoris privats; l'agent va llegir l'issue, va portar dades privades al seu context i va obrir un pull request al repositori públic amb aquestes dades a dins. A la seva demostració van sortir noms de projectes privats, plans personals del propietari i dades salarials.

La seva conclusió mereix llegir-se literal, perquè desactiva la reacció habitual de culpar el proveïdor: no és un error del codi del servidor MCP de GitHub, sinó un problema arquitectònic fonamental que s'ha de resoldre al nivell del sistema d'agents. L'agent va fer exactament allò per a què tenia permís. La lliçó es resumeix en una frase: l'abast del token és l'abast de l'incident. Un token que veu quaranta repositoris converteix qualsevol issue públic en una porta a quaranta repositoris.

On es decideix de debò: la fitxa de l'eina

Un permís, a diferència d'una instrucció, s'avalua fora del model: al client que executa la crida, a la passarel·la, a l'IAM, al codi que embolcalla l'eina. És determinista i no opina sobre com de persuasiu sigui el text que acaba de llegir l'agent. Per això la unitat de treball de la seguretat d'un agent no és el prompt: és l'eina, i cada eina necessita una fitxa tan explícita com la d'un endpoint públic.

Aquests són els camps que fan que aquesta fitxa serveixi per decidir, i no només per documentar.

El sisè camp mereix un nom perquè canvia la conversa: pressupost de dany per sessió. Igual que s'acota la despesa d'una sessió d'agent amb un nombre explícit, s'acota la seva capacitat de fer mal: quantes accions amb efecte, cap a quantes destinacions diferents i amb quin volum de dades abans d'haver de demanar signatura. Quan el pressupost s'esgota no es bloqueja l'agent —continuaria sent útil llegint—, es bloqueja l'efecte. La majoria de les fuites necessiten repetició o volum, i un comptador determinista les talla on un classificador dubtaria.

Els patrons que sí que resisteixen

El juny de 2025, catorze autors de l'acadèmia i de la indústria —entre ells part de l'equip que va construir AgentDojo— van publicar Design Patterns for Securing LLM Agents against Prompt Injections, que és avui el document més pràctic que existeix sobre el tema. El seu principi rector és exigent i s'entén a la primera: un cop un agent ha ingerit entrada no fiable, cal restringir-lo de manera que sigui impossible que aquesta entrada desencadeni accions amb conseqüències. Impossible, no improbable.

D'aquí en surten sis patrons. No són excloents i no es trien per a tot el sistema: es trien per tasca.

• Selector d'accions. El model tradueix la petició a una d'un conjunt tancat d'accions i no en veu el resultat. Encaixa en automatitzacions de disparador, on la varietat és a l'entrada i no al pla.
• Planificar i després executar. El pla es fixa abans de llegir res extern; el contingut de fora pot omplir arguments, però no canviar la llista d'accions ni afegir-n'hi.
• Map-reduce amb LLM. Un agent aïllat per cada tros de contingut no fiable i un agregador que no torna a delegar. És el patró natural per processar dos-cents documents sense donar eines a cap.
• Doble LLM. El model amb eines mai no veu el text no fiable: el processa un altre en quarantena, sense accés a res, i només creua la frontera una dada estructurada. És la resposta estàndard per a correu i tiquets.
• Escriure codi i executar-lo. L'agent escriu un programa que crida les eines, de manera que el flux de control queda escrit abans de trobar-se amb el text hostil.
• Minimització de context. Treure del context el que ja no cal, perquè una instrucció injectada no continuï viva vint torns després.

El cas extrem d'aquesta família també és publicat i mesurat. CaMeL —Debenedetti i altres, 2025— extreu el flux de control i de dades de la consulta de l'usuari, que sí que és fiable, i impedeix que les dades no fiables influeixin en l'execució del programa, amb capacitats que bloquegen l'exfiltració. A AgentDojo resol el 77% de les tasques amb seguretat demostrable, davant del 84% d'un sistema sense defensa. Aquest set és la xifra més útil de tota aquesta literatura: per primera vegada el preu de la seguretat en un agent es pot posar en una taula en lloc de discutir-lo en abstracte. Set punts d'utilitat és una conversa de producte; una fuita de dades, no.

I hi ha bancs de proves per mesurar a casa abans de creure's res. AgentDojo (Debenedetti i altres, NeurIPS 2024) porta 97 tasques realistes —client de correu, banca electrònica, reserves de viatge— i 629 casos de seguretat, i està dissenyat per ser extensible amb atacs adaptatius nous, que és justament el que li faltava a la generació anterior d'avaluacions. InjecAgent (Zhan i altres, 2024) és més específic: 1.054 casos sobre 17 eines d'usuari i 62 d'atacant, amb dues intencions separades —dany directe a l'usuari i exfiltració de dades privades—. El seu resultat continua sent la millor calibració d'expectatives que coneixem: un agent ReAct sobre GPT-4 va resultar vulnerable el 24% de les vegades, i amb instruccions d'atac reforçades la taxa es va doblar aproximadament. No parlem de models febles ni de configuracions de joguina.

Els filtres valen — però no poden ser l'última baula

Res del que hem dit no significa que les defenses de detecció sobrin. Spotlighting, de Keegan Hines i el seu equip a Microsoft (2024), proposa marcar l'origen del text perquè el model distingeixi quina part del seu context és dada i quina instrucció, mitjançant delimitadors, marcatge de dades o codificació; als seus experiments amb models de la família GPT va baixar la taxa d'èxit de l'atac de més del 50% a menys del 2% amb impacte mínim en la tasca. És una millora enorme per un cost d'implementació baix, i tot i així deixa fora dos atacs de cada cent.

Google va publicar el 13 de juny de 2025 la seva estratègia per capes per a Gemini, que és un bon mapa del que avui es considera complet: classificadors de contingut per a injeccions, reforç del raonament de seguretat, sanejament de markdown i redacció d'URL sospitoses, un marc de confirmació de l'usuari i avisos de mitigació a l'usuari final. Cinc capes, cap de suficient per si sola, amb l'objectiu declarat d'elevar el cost i la complexitat per a l'atacant — no de garantir res.

El context, a més, s'està movent. L'abril de 2026 el mateix equip de seguretat de Google va publicar una anàlisi d'injeccions trobades a la web oberta a partir d'arxius de Common Crawl, amb categories que van des de la broma inofensiva i la dissuasió d'agents fins a la manipulació SEO, l'exfiltració de dades i l'atac destructiu. La seva xifra: un augment relatiu del 32% a la categoria maliciosa entre novembre de 2025 i febrer de 2026, amb l'advertència explícita dels autors que l'anàlisi no és exhaustiva i que se'ls escapen signatures poc comunes. Com a mesura absoluta no serveix; com a senyal de direcció, és la que hi ha: a la web oberta ja hi ha text escrit per a agents que encara no hi han passat.

L'humà al bucle es trenca per fatiga

La regla de dos permet les tres capacitats a canvi de supervisió humana, i OWASP recomana aprovació humana per a les accions de risc. És correcte i és la sortida més utilitzada. També és la que més silenciosament es degrada, perquè una aprovació repetida deixa de ser una aprovació molt abans que ningú no se n'adoni.

Tres condicions perquè una signatura signifiqui alguna cosa. La primera: que ensenyi l'efecte, no la intenció. «L'agent vol enviar un correu» no és informació; «enviarà aquest text a aquesta adreça externa, amb aquests tres camps del client a dins» sí que ho és. La segona: que arribi abans de l'efecte — una notificació posterior és un registre, no un control. I la tercera, la que gairebé mai no es dissenya: que sigui infreqüent. Si una persona aprova trenta vegades al dia, a la trenta-unena aprova sense llegir, i la culpa no és seva: el permís està mal posat.

D'aquí una conseqüència que convé dir en veu alta al comitè: marcar «aprovar sempre» no és una casella, és un canvi d'arquitectura. Quan algú la marca està dient que aquesta eina hauria de ser al grup que no necessita signatura — o que no hauria d'existir. Totes dues són decisions legítimes; el que no ho és, és que es prenguin a les set del vespre d'un dijous sense que en quedi constància.

La prova del desconegut

Per saber si tens la trifecta no cal un pentest. Cal una pissarra, vint minuts i quatre preguntes, fetes per cada sessió-tipus de l'agent i no pel sistema sencer — que és l'error més comú d'aquestes auditories: s'aprova «el producte» quan el que cal aprovar són les seves maneres d'operar.

1. Quin text entra al context que pugui escriure un desconegut? Si la resposta és «cap», busca-ho una altra vegada: el peu d'un correu, el nom d'un fitxer adjunt, un comentari en un pull request, la descripció d'un producte d'un proveïdor, el resultat d'una cerca web.
2. A què pot arribar l'agent en aquesta sessió que no sigui públic? Contesta amb una llista de recursos, no de sistemes. Si la llista diu «el CRM», encara no has contestat.
3. Per on pot sortir un byte cap enfora? Compta també els camins que no semblen sortides: un enllaç que algú prémerà, una imatge remota que el client carrega sola, un adjunt, una crida a una eina d'un tercer.
4. De tot el que pot fer, què no es desfà en cinc minuts?

Si les tres primeres tenen resposta i la quarta no és buida, tens la trifecta letal amb una acció irreversible a dins. Això no vol dir que t'atacaran demà; vol dir que si t'ataquen, el resultat no depèn de tu.

El tall de la primera setmana

El que fem quan entrem en un sistema agèntic que ja és en producció, en ordre i sense plataforma nova.

1. Inventari d'eines, mig matí: nom, efecte, abast real de la credencial. A gairebé tots n'apareixen dues coses — una eina que ningú no recordava haver connectat i un token bastant més ampli del que el seu propietari es pensava.
2. Marcar A, B i C per sessió-tipus. És la traducció literal de la regla de dos i cap en una taula de cinc files.
3. Tallar per la C on no aporti: llista blanca de destinacions, sense càrrega automàtica de recursos remots, sense enllaços sortints generats sense revisió.
4. Estrènyer la B: credencials per recurs i per sessió, només lectura on n'hi hagi prou. Aquí és on es tanca el cas del servidor MCP de GitHub, i costa una tarda.
5. Signatura humana només en allò irreversible, amb l'efecte al davant i abans d'executar-lo. Tota la resta, sense signatura, perquè la signatura es llegeixi.
6. Un cas hostil per eina amb efecte al golden set. La resistència a la injecció no és un exercici a part de l'avaluació: és una capacitat més, i s'estratifica com les altres.
7. Traça que permeti respondre «quin text va entrar i quina acció va sortir?» — la mateixa que ja necessites per operar el sistema, amb el text d'entrada desat.

Els set punts són d'arquitectura i de configuració. Cap no exigeix canviar de model, i per això sobreviuen al canvi de model — que passarà dues vegades mentre el sistema és viu.

Què es compra i què es construeix

Es compren classificadors d'injecció, passarel·les que medien les crides a eines, escàners que auditen servidors MCP i models entrenats per resistir millor. Tot això apuja el cost de l'atac i té sentit en un pressupost de seguretat. El que no es compra és la taula: quines eines existeixen de debò, amb quin abast, què és irreversible al teu negoci —que no és el mateix en una asseguradora que en un SaaS— i qui signa cada cosa. Aquest coneixement és a la teva organització i treure'l porta dies de feina amb les persones correctes, igual que els casos que defineixen si el sistema funciona.

És també la raó per la qual als nostres programes això no va en un annex de seguretat al final. Va al mateix lloc on les especificacions descriuen què ha de construir un agent: la constitució del projecte diu què pot fer, amb quin abast i qui signa, i això es revisa en pull request com qualsevol altra regla. Un permís escrit en una spec s'audita; un permís escrit en un prompt es negocia amb el primer que sàpiga escriure un correu convincent.

Preguntes freqüents

Què és la injecció de prompts, en una frase?

És el que passa quan un text que el teu sistema tracta com a dada —un correu, un tiquet, un document, una pàgina web, un issue— conté instruccions i el model les obeeix. La causa no és un error de programació: dins d'un model de llenguatge no hi ha un canal separat per a instruccions i un altre per a dades, així que qualsevol token es pot llegir com una ordre. Per això el NCSC britànic adverteix que probablement no es mitigarà mai del tot com es mitiga la injecció SQL, on aquesta separació sí que es pot imposar.

En què es diferencia d'un jailbreak?

En qui ataca i qui és la víctima. Un jailbreak el fa l'usuari contra les regles del proveïdor del model: vol que el sistema digui alguna cosa que no hauria de dir. Una injecció indirecta la fa un tercer contra la teva empresa, i el teu usuari és la víctima, no l'atacant: algú escriu el contingut que el teu agent llegirà perquè executi accions en nom teu. Confondre'ls porta a comprar filtres de contingut quan el problema és als permisos de les eines.

Es pot evitar del tot amb un bon prompt de sistema o un filtre?

No, i hi ha evidència directa. El prompt de sistema viu al mateix context que l'atac, així que és una petició, no un control. I sobre els filtres: el 2025, catorze investigadors encapçalats per Milad Nasr i Nicholas Carlini van atacar dotze defenses publicades amb atacants adaptatius i en van superar la majoria amb taxes d'èxit per sobre del 90%, quan aquestes mateixes defenses havien reportat taxes properes a zero. Els filtres apugen el cost de l'atac i valen la pena com a capa; el que no poden ser és l'última baula abans d'una acció irreversible.

Què són la trifecta letal i la regla de dos?

Dues formulacions de la mateixa idea, i les dues eines de disseny més útils que hi ha avui. Simon Willison va anomenar trifecta letal la combinació de tres capacitats en un mateix agent: accés a dades privades, exposició a contingut no fiable i capacitat de comunicar-se cap enfora. Meta li va donar forma operativa amb la regla de dos: un agent no hauria de reunir més de dues d'aquestes tres propietats dins d'una sessió i, si necessita les tres, no hauria d'operar de manera autònoma. Amb les tres juntes, un text hostil pot convertir-se en una fuita de dades.

Són insegurs els servidors MCP?

El protocol no és el problema; l'abast de les credencials que se li lliuren, sí. El maig de 2025 Invariant Labs va demostrar el cas amb el servidor MCP oficial de GitHub: un issue en un repositori públic amb instruccions amagades va bastar perquè un agent portés dades de repositoris privats i les publiqués en un pull request. La seva pròpia conclusió és que no és un error del codi del servidor, sinó un problema arquitectònic que es resol al sistema d'agents: credencials per recurs i per sessió, no un token que ho veu tot.

Per on començo si el meu agent ja és en producció?

Per l'inventari d'eines, no pel model. Mig matí: cada eina amb el seu efecte (llegeix, escriu o comunica), l'abast real de la seva credencial i si el que fa es desfà en cinc minuts. Després, marcar per cada sessió-tipus quines de les tres capacitats de la regla de dos estan actives i tallar la que menys valor aporti, que gairebé sempre és la sortida: llista blanca de destinacions en lloc de llista negra. Signatura humana només en allò irreversible, perquè signifiqui alguna cosa.

Fonts citades

• Greshake, Abdelnabi, Mishra, Endres, Holz, Fritz — Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection (2023; la línia entre dades i instruccions i la taxonomia d'impactes)
• OWASP — LLM01:2025 Prompt Injection (directa vs. indirecta, set mitigacions i l'absència de mètodes infal·libles)
• NCSC (Regne Unit) — Mistaking AI vulnerability could lead to large-scale breaches (10 de desembre de 2025; per què no és una injecció SQL i què cal fer en el seu lloc)
• Nasr, Carlini, Sitawarin, Schulhoff i altres — The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections (2025; dotze defenses, taxes d'èxit per sobre del 90%)
• Willison, S. — The lethal trifecta for AI agents (16 de juny de 2025; i per què el 95% és un suspens en seguretat)
• Meta — Agents Rule of Two: A Practical Approach to AI Agent Security (31 d'octubre de 2025)
• Beurer-Kellner, Buesser, Creţu, Debenedetti i altres — Design Patterns for Securing LLM Agents against Prompt Injections (2025; els sis patrons i el principi de l'«impossible»)
• Debenedetti, Shumailov, Fan, Hayes, Carlini i altres — Defeating Prompt Injections by Design (CaMeL; 77% de tasques amb seguretat demostrable davant del 84% sense defensa a AgentDojo)
• Debenedetti, Zhang, Balunović, Beurer-Kellner, Fischer, Tramèr — AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents (NeurIPS 2024; 97 tasques i 629 casos de seguretat)
• Zhan, Liang, Ying, Kang — InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents (2024; 1.054 casos, GPT-4 amb ReAct vulnerable el 24% de les vegades)
• Hines, Lopez, Hall, Zarfati, Zunger, Kiciman — Defending Against Indirect Prompt Injection Attacks With Spotlighting (Microsoft, 2024; de més del 50% a menys del 2%)
• Google Security Blog — Mitigating prompt injection attacks with a layered defense strategy (13 de juny de 2025) i AI threats in the wild: the current state of prompt injections on the web (23 d'abril de 2026)
• Aim Security — EchoLeak, CVE-2025-32711 a Microsoft 365 Copilot (11 de juny de 2025; anàlisi tècnica de la cadena a Reddy i Gujral, 2025)
• Invariant Labs — GitHub MCP Exploited: Accessing private repositories via MCP (26 de maig de 2025)