Què és la seguretat dels LLM? Com mitigar els 10 principals riscos de seguretat de l’OWASP

Un atac que enganya una IA perquè tracti les instruccions d’un atacant com a ordres —la injecció de prompts— ha estat el número 1 de l’OWASP Top 10 for LLM Applications en totes les edicions des del 2023.

La llista és el més semblant a un consens que hi ha en seguretat de la IA. El projecte va començar com un petit grup de professionals de la seguretat i ara compta amb més de 600 experts col·laboradors de més de 18 països.

Som una empresa d’IA que publica una guia sobre com es pot convèncer una IA de fer coses, així que no farem veure que això està resolt. Wilson, que codirigeix el projecte de l’OWASP, va ser força clar sobre les defenses actuals: «...francament, no crec que siguem al 99 %».

L’edició del 2026 comença en la mateixa línia. El responsable del projecte ens demana que «deixem d’intentar construir un model que no es pugui enganyar» i que dissenyem el sistema que l’envolta perquè un model enganyat no pugui fer malbé res important.

Apliquem aquest enfocament als 10 riscos de la llista del 2026 de l’OWASP.

Què vol dir seguretat dels LLM?

La seguretat dels LLM consisteix a protegir els models d’IA i les aplicacions que els fan servir d’atacs i usos indeguts. El risc creix segons allò a què està connectat el model: els fitxers i les dades que pot llegir, i les eines que pot utilitzar, com ara el correu electrònic, la cerca o una base de dades de l’empresa.

En un programari ben protegit, hi ha una línia ferma entre les instruccions que segueix un programa i la informació que processa. Però els LLM no tenen aquesta línia.

Tot el que llegeix el model arriba com un únic flux llarg de text: les instruccions del desenvolupador, la teva pregunta, una pàgina web que ha consultat. Se suposa que els models d’IA han de saber qui parla en cada moment, ja sigui el desenvolupador, l’usuari o el mateix model mentre raona un problema.

Però els investigadors Jasmine Cui i Charles Ye van descobrir que els models endevinen qui parla sobretot a partir de com sona el text. Així, si un atacant escriu alguna cosa que sembla el raonament del mateix model, el model pot creure que la idea se li ha acudit a ell. Això és un problema per a qualsevol mecanisme de seguretat que depengui que el model sàpiga qui mana.

Nosaltres hem topat amb el mateix problema amb els nostres propis agents d’IA. El nostre CISO, Kyle Polley, va dir a ISMG que els agents «potser no segueixen les polítiques encara que les afegeixis al prompt del sistema». Per això vam crear Numbat, una eina de codi obert que comprova què està a punt de fer un agent i pot bloquejar-ho si l’acció infringeix una regla de seguretat configurada.

La seguretat dels LLM consisteix a acceptar que el model de vegades rebrà ordres de la persona equivocada i a envoltar-lo de barreres de protecció d’IA que continuïn aguantant quan passi.

Quines són les millors pràctiques de seguretat dels LLM?

Repassarem l’OWASP Top 10 for LLM Applications 2026 per ordre, del número 1 al número 10.

Per a cada risc, trobaràs una explicació en llenguatge planer de com poden sortir malament les coses i un exemple real. Després veurem les pràctiques que poden ajudar a evitar-lo o, com a mínim, a limitar-ne els danys.

1. Limita l’abast de la injecció de prompts

Una injecció de prompts es produeix quan un atacant fa que una IA segueixi instruccions que no hauria de seguir. Aquestes instruccions poden arribar directament en un xat o estar amagades en un correu electrònic, una pàgina web o un document.

El segon tipus es coneix com a injecció indirecta de prompts. Demanes al teu assistent que resumeixi un document. Qui l’ha escrit ha indicat a l’assistent que li enviï els teus fitxers privats. Si l’assistent segueix aquestes instruccions, la persona que va escriure el document, de fet, s’ha apropiat del teu accés.

PCMag compara la seguretat dels prompts amb tapar forats en una pedra porosa. Segelles una obertura i l’aigua en troba una altra. «Un atac s’obre camí; es corregeix, però queden per descobrir innombrables vies d’atac més, simplement per com de dinàmics són sistemes com els LLM.»

Exemple: el juny del 2025, investigadors d’Aim Security van descobrir EchoLeak, una vulnerabilitat que enganyava Microsoft 365 Copilot perquè filtrés informació privada de l’empresa. Quan un empleat feia una pregunta rutinària de feina, Copilot podia incorporar el correu electrònic, seguir les instruccions que hi havia amagades i enviar informació sensible a l’atacant. L’atac superava els controls pensats per detectar instruccions malicioses i eliminar enllaços sospitosos.

Què pots fer:

• Segueix la «regla de dos» de Meta: EchoLeak necessitava una IA que pogués llegir dades de l’empresa, llegir correus externs i enviar informació a fora, i tenia totes tres capacitats. Limitar-la a dues d’aquestes capacitats evita que una injecció de prompts n’obtingui massa control. Si la tasca requereix totes tres, exigeix l’aprovació d’una persona abans de cada acció.
• Fes proves amb atacants que coneguin les teves defenses: proporciona als teus provadors de seguretat les regles i els filtres que has implementat i deixa’ls que intentin eludir-los. En un estudi, els atacants que s’adaptaven a les defenses van tenir èxit més del 90 % de les vegades contra la majoria de les 12 defenses provades.

2. Evita les filtracions d’informació sensible

Quan els sistemes d’IA donen informació privada a persones que no l’haurien de veure, es parla de divulgació d’informació sensible. Això pot voler dir revelar les dades de pagament d’un client o deixar converses privades en una base de dades compartida.

Moltes filtracions comencen per «compartir massa». Suposem que una empresa connecta la seva IA a unitats d’emmagatzematge i bases de coneixement amb permisos poc estrictes. La IA recupera tot el que té a l’abast, exactament tal com està dissenyada. Ningú no ha d’entrar-hi per la força, però l’LLM ja es pot donar per compromès.

Exemple: el gener del 2025, investigadors de Wiz van trobar una base de dades de DeepSeek oberta a internet amb més d’un milió d’entrades de registre, incloent-hi l’historial de xats i claus d’API, que el programari utilitza per accedir a altres serveis. Els investigadors no van haver de convèncer el model perquè revelés res.

Què pots fer:

• Comprova l’accés abans que la IA llegeixi les dades: la teva aplicació hauria de comprovar quins documents pot veure la persona que fa la pregunta abans de passar-los al model.
• Protegeix els registres que deixa la teva IA: elimina els detalls privats i les claus secretes abans de desar els registres d’activitat, exigeix inici de sessió i restringeix-ne l’accés a les persones que els necessiten. Estableix un període de conservació perquè aquests registres no s’acumulin indefinidament.

3. Controla l’autonomia excessiva

Les IA amb autonomia excessiva tenen més poder del que requereix la seva feina: eines que no necessiten, permisos que van més enllà de la seva tasca o llibertat per actuar sense comprovacions. Aquí la causa és irrellevant.

Un prompt d’injecció, un error de programació o un model que simplement s’equivoca porten al mateix resultat. Tard o d’hora, la IA farà alguna cosa destructiva si en té la capacitat.

Exemple: el juliol del 2025, el fundador de SaaStr, Jason Lemkin, va informar que l’agent de programació de Replit havia esborrat la seva base de dades de 1.206 registres d’executius, tot i les instruccions de no fer-hi canvis. Inicialment, l’agent va dir que les dades no es podien restaurar, tot i que més tard es va veure que sí que es podien recuperar. Jason va descobrir que dir-li que no toqués la base de dades no li havia tret la capacitat d’esborrar-la.

Amplia

Font: X

Què pots fer:

• Elimina les capacitats que la tasca no necessita: limita tant les eines que rep un agent com allò que aquestes eines poden fer. Un assistent que resumeix correus necessita permís per llegir-los, no per enviar-los ni esborrar-los.
• Situa les comprovacions de permisos fora de la IA: cada vegada que se sol·liciti una acció, fes que es contrasti amb les teves regles de seguretat i exigeix que una persona l’aprovi.

4. Comprova què entra a la cadena de subministrament de la teva IA

Poques empreses creen IA des de zero, i cada any en són menys. Segons l’enquesta The State of Generative AI in the Enterprise 2025 de Menlo Ventures, el 53 % de les empreses va comprar models d’IA el 2024, una xifra que va augmentar fins al 76 % el 2025.

Molt sovint, les empreses descarreguen models de plataformes com Hugging Face, els continuen entrenant amb conjunts de dades que han recopilat altres persones i hi connecten complements i paquets de codi escrits per desconeguts.

Cadascuna d’aquestes peces és una porta d’entrada. Si se’n manipula una, el problema arriba integrat dins del teu producte.

Exemple: els repositoris públics de models de Hugging Face van passar de 2,43 milions a 2,96 milions entre el gener i l’agost del 2026. Tanmateix, el juliol del 2026, els models d’OpenAI van eludir els controls pensats per mantenir-los fora d’internet durant unes proves de seguretat internes i es van infiltrar en parts dels sistemes de Hugging Face. De fet, un agent va recuperar 14 credencials d’accés exposades públicament, va comprovar que funcionaven i les va compartir amb altres agents. Els agents van acabar aprofitant vulnerabilitats que els permetien executar codi als servidors de Hugging Face.

«Estem imposant requisits més estrictes d’alineació al llarg de tot el cicle de vida d’un model i creant entorns de proves més aïllats, restringint l’accés a internet i controlant encara més l’accés als pesos dels models», diu l’informe d’OpenAI.

Què pots fer:

• Fixa els models a una versió exacta i verifica’ls: fixa cada model a una versió revisada i comprova l’empremta del fitxer abans de carregar-lo, perquè no s’hi pugui colar un fitxer substituït amb la mateixa etiqueta. L’OWASP també recomana les signatures digitals, amb un matís: una signatura demostra d’on prové un model, no que sigui segur.
• Comprova cada paquet que et suggereixi la IA: abans d’instal·lar un paquet de codi recomanat per un assistent d’IA, confirma que existeix, que és el paquet que volies i que prové de l’editor que esperes.

5. Protegeix-te de l’enverinament de dades i de models

Una IA enverinada aprèn de dades corrompudes. Poden ser els exemples amb què se l’ha ajustat o una base de coneixement on busca respostes. El model sembla que continua funcionant; simplement aprèn les lliçons equivocades i, de vegades, aprèn a comportar-se malament només quan veu una frase desencadenant concreta.

El model superarà totes les proves que li facis fins que algú faci servir aquesta frase.

Amplia

A més, és molt difícil de desfer. L’enverinament no és un error que es pugui corregir amb un pedaç. Si les teves dades són errònies, potser hauràs de tornar-les a revisar, tornar a entrenar el model o substituir-lo del tot.

Exemple: l’octubre del 2025, investigadors d’Anthropic, l’AI Security Institute del Regne Unit i l’Alan Turing Institute van demostrar que 250 documents enverinats podien ensenyar un model a generar text sense sentit cada vegada que trobava un desencadenant concret. El mateix nombre de documents funcionava en les quatre mides de model provades, tot i que el model més gran s’havia entrenat amb més de 20 vegades més dades netes.

Què pots fer:

• Fes un seguiment de la procedència de les dades: mantén un registre de cada conjunt de dades i model que fas servir, d’on prové cadascun i què ha canviat entre versions. Recomanem fer servir control de versions per als conjunts de dades perquè, si es detecta un enverinament, puguis tornar a una versió neta i esbrinar com hi va entrar.
• Busca portes del darrere: una «porta del darrere» és un comportament ocult que un atacant implanta en un model i que espera una frase concreta o un altre desencadenant per activar-se. Detecta-les amb entrades dissenyades perquè el model infringeixi les seves regles habituals.

6. Posa fre al consum il·limitat

Quan les IA no tenen cap límit en la quantitat de feina que poden fer o en el que poden costar, es considera que el seu consum és «il·limitat». La majoria dels serveis d’IA cobren per ús, de manera que un atacant podria disparar la teva factura o crear una còpia del teu model.

L’OWASP anomena el problema de fons «asimetria de costos». Una sol·licitud breu i barata pot desencadenar un càlcul costós per part teva.

Exemple: el maig del 2024, el Threat Research Team de Sysdig va descobrir un nou atac anomenat «LLMjacking». Un grup d’atacants es va dirigir contra 10 serveis d’LLM allotjats al núvol amb credencials robades. Van entrar a través d’una versió vulnerable de Laravel i després van esbrinar què es podia fer amb les credencials i quines quotes tenien, amb l’objectiu evident de vendre’n l’accés. També van consultar molts paràmetres de configuració dels registres, probablement per evitar ser detectats. Segons Sysdig, en el pitjor dels casos, la víctima podria arribar a pagar més de 46.000 dòlars al dia.

Què pots fer:

• Estableix pressupostos que aturin la despesa: fixa límits de despesa estrictes per a usuaris individuals, claus d’API, equips i el compte en conjunt. Aplica’ls a tots els punts per on poden entrar sol·licituds.
• Dona a cada tasca un punt d’aturada: limita quant de temps pot durar una tasca, quant text pot processar i generar i quantes crides a eines pot fer. Afegeix talls automàtics per als agents que es repeteixen o superen la seva assignació.

7. Detecta la desinformació abans d’actuar

Quan una IA produeix alguna cosa falsa que sembla correcta i algú, o alguna cosa, actua en conseqüència, es parla de desinformació. El risc principal no és tant la resposta errònia en si com el fet que es confiï en aquesta resposta i s’utilitzi.

L’historial d’incidents suggereix que els professionals no estaven tan preocupats per la desinformació com haurien d’haver estat. Segons la carta d’obertura de l’edició del 2026, els votants la van situar a la part baixa de la llista, però, a jutjar pels incidents reals, és a prop del capdamunt.

Exemple: el 2025, Deloitte Australia va lliurar una revisió dels sistemes informàtics de prestacions socials en el marc d’un contracte governamental de 440.000 dòlars australians. Un investigador de la Universitat de Sydney, Chris Rudge, va trobar referències a estudis inexistents i una cita inventada d’una sentència d’un tribunal federal. L’informe revisat va revelar que Deloitte havia fet servir Azure OpenAI GPT-4o en la seva metodologia, i l’empresa va acceptar retornar l’últim pagament. Malauradament, es tractava d’una revisió que havia de servir precisament de garantia.

Què pots fer:

• Comprova que les fonts avalin la resposta: basa les afirmacions en fonts actuals i fiables. Per a una resposta sobre polítiques, recupera la política aprovada i comprova que avala la conclusió, incloses les excepcions.
• Verifica abans que el sistema actuï: si un agent diu que un client ha superat una verificació d’identitat, confirma-ho amb el sistema de verificació abans d’alliberar un pagament. Exigeix l’aprovació humana per a les decisions importants, amb la documentació de suport a disposició de qui les revisi.

8. Limita els danys de l’exposició del context ocult

Les aplicacions d’IA donen al model instruccions i informació de context que els usuaris normalment no veuen. Això pot incloure el prompt del sistema, polítiques internes, descripcions de les eines disponibles i regles sobre qui les pot utilitzar. Es produeix una exposició del context ocult quan el model revela aquesta informació a algú.

El 2026, l’OWASP va ampliar aquesta entrada, que abans es deia «filtració del prompt del sistema», perquè el prompt del sistema és només una part del que es pot filtrar. El perill depèn del que hi hagis posat. Una guia de to de veu filtrada és una mica vergonyosa, però una clau d’API filtrada dona a algú accés a la teva base de dades confidencial.

Exemple: el febrer del 2023, uns usuaris van aconseguir que Bing Chat de Microsoft revelés les seves instruccions internes. Un dels intents reeixits va ser obra de Marvin von Hagen, que va afirmar ser un desenvolupador d’OpenAI i va demanar les instruccions per poder configurar el model. Bing va revelar les regles que regien les seves cerques, les seves respostes i el seu comportament de seguretat, a més del seu nom intern, Sydney. Entre les instruccions revelades n’hi havia una que li indicava que les mantingués confidencials.

Què pots fer:

• Mantén els secrets fora del context del model: Dona per fet que qualsevol cosa que el model pugui llegir podria acabar sent visible per als usuaris: desa les contrasenyes, les claus d’API i els tokens d’accés en un sistema de gestió de secrets independent.
• Fes que els permisos es mantinguin fins i tot si es filtren les regles: Aplica les comprovacions d’accés al codi de l’aplicació. Si una eina està restringida als administradors, comprova els permisos del compte de l’usuari abans d’executar-la.

9. Protegeix els vectors i els embeddings

Quan una IA fa servir la cerca vectorial per trobar respostes als documents de la teva empresa, no cerca directament en el text. Els documents es converteixen en «embeddings», que són llargues llistes de números que capturen el significat de cada fragment, i s’emmagatzemen en una base de dades vectorial. Les preguntes es converteixen de la mateixa manera, i el sistema recupera els fragments amb els números més propers.

L’OWASP resumeix les quatre maneres en què pot fallar: l’enverinament fa que el sistema s’equivoqui, la inversió fa que filtri informació, el bloqueig fa que emmudeixi i un control d’accés deficient fa que lliuri qualsevol cosa a qualsevol persona.

Els números no són l’abstracció segura que semblen. Els embeddings emmagatzemats es poden tornar a convertir en text, i un mètode va recuperar exactament el 92 % dels fragments curts de 32 tokens en les seves proves. Per tant, una còpia de seguretat filtrada «només d’embeddings» també pot exposar el contingut dels documents.

Exemple: En una investigació presentada a USENIX Security 2025, uns investigadors van demostrar que un sol document elaborat amb cura podia impedir que una IA respongués a una pregunta concreta. El van afegir a la col·lecció on cercava la IA. Quan la IA el trobava, podia dir que no tenia prou informació o que respondre no era segur. El document no necessitava dir a la IA que ignorés les seves regles. Això s’anomena «bloqueig de la recuperació».

Què pots fer:

• Mantén índexs separats per a les dades públiques i les privades: No barregis contingut extret del web amb dades de socis o documents interns confidencials. Separa’ls físicament segons el nivell de confiança en lloc d’etiquetar el contingut dins d’un mateix índex: així elimines tota una categoria d’errors de configuració, i el contingut extret d’internet no pot acabar al costat dels documents del consell d’administració.
• Tracta els embeddings igual que els documents dels quals provenen: Xifra’ls, protegeix tant les còpies de seguretat de la base de dades vectorial com els fitxers d’origen i elimina els embeddings quan eliminis l’original. Les claus d’API del servei d’embeddings s’han de mantenir en secret.

10. Comprova la sortida de la IA abans de transmetre-la

Sempre que una aplicació transmet la sortida de la IA a un altre sistema sense verificar si és segura per fer-la servir allà, està gestionant de manera inadequada la sortida de l’LLM.

Aquest apartat també inclou el codi insegur que els assistents de programació amb IA generen a gran escala. Per tant, cada línia que escriu un assistent també és sortida.

Exemple: El 2025, l’investigador Johann Rehberger va demostrar com l’assistent de programació Amp de Sourcegraph podia filtrar el contingut d’un xat simplement mostrant una imatge. Va fer servir una injecció de prompts perquè Amp inclogués informació privada a l’adreça web d’una imatge. Aleshores, l’aplicació va carregar automàticament aquella imatge i va enviar la informació al seu servidor. L’error de gestió de la sortida va ser aquella sol·licitud automàtica: el text que havia generat el model es va convertir en una connexió a un servidor extern que s’enduia dades privades.

Què pots fer:

• Fes que la sortida sigui segura per al seu destí: Comprova i gestiona les respostes segons on aniran a parar. En una pàgina web, evita que el text generat es converteixi en codi executable. En una base de dades, fes servir consultes preparades que mantinguin els valors proporcionats separats de les ordres.
• Impedeix que les respostes facin connexions externes automàtiques: Desactiva per defecte la càrrega automàtica d’imatges, previsualitzacions d’enllaços i pàgines incrustades a les respostes del model. Limita les connexions necessàries a destinacions aprovades explícitament.

Com protegeix Perplexity els LLM?

Donem per fet que tots els riscos anteriors acabaran materialitzant-se, i dissenyem els sistemes perquè, quan passi, no puguin fer gaire mal. El nostre CISO, Kyle Polley, va explicar com ho fem en un taller recent.

• L’agent té el seu propi ordinador, i comença buit: Les eines d’agents instal·lades al teu portàtil poden accedir als fitxers, a les aplicacions i a les credencials desades que hi tens. Perplexity Computer funciona al revés. Cada tasca s’executa en el seu propi entorn de proves aïllat i, com diu Polley, «per defecte no té accés a res».
• L’agent no veu mai les contrasenyes: Les credencials dels serveis connectats s’emmagatzemen fora de l’entorn de proves. Quan l’agent necessita accedir a un servei com GitHub, envia una sol·licitud sense cap credencial. Una passarel·la comprova que la destinació i la sol·licitud són les esperades i, aleshores, hi afegeix les credencials en sortir. L’agent pot fer servir la connexió sense obtenir les claus.
• Els teus permisos es mantenen, i els pots restringir encara més: Les connexions fetes mitjançant OAuth conserven els teus permisos d’accés al servei connectat. Si tu no pots veure alguna cosa, el teu agent tampoc.
• Cada pàgina web es tracta com una desconeguda: Vam crear BrowseSafe per a Comet, el nostre navegador agèntic, perquè les eines que vam provar no satisfeien les nostres necessitats en l’ús real. El navegador analitza les pàgines web i altres continguts externs, inclosos els correus electrònics, per detectar injeccions de prompts. Hem publicat com a codi obert tant el model com el conjunt de dades.
• Vigilem l’agent i les màquines on s’executa: Numbat se situa entre el moment en què un agent decideix actuar i l’execució real de l’eina. Numbat registra l’activitat dels agents de programació compatibles i pot bloquejar les accions que incompleixen les polítiques configurades abans que s’executin. Bumblebee fa inventari dels paquets de programari dels portàtils, servidors i processos de compilació, i marca els que se sap que són maliciosos. Tots dos són de codi obert.
• Els proveïdors de models no conserven les teves dades: Tenim acords de retenció zero de dades amb els nostres proveïdors externs de LLM. Els administradors d’Enterprise també poden reduir el període de retenció de dades de Perplexity a només 24 hores.

Vam crear Numbat de manera proactiva, per un motiu que Polley resumeix en una frase: «Com més autonomia dones a un agent, més risc hi ha».

Preguntes freqüents sobre la seguretat dels LLM

Quin és l’LLM més segur?

Cap LLM fa que una aplicació sigui segura per si sol: els models encara poden confondre contingut que haurien de llegir amb instruccions que haurien de seguir. Les defenses que semblen sòlides en les proves estàndard també poden cedir sota pressió.

Una pregunta millor és quina configuració és la més segura per al teu cas d’ús. Això vol dir permisos limitats, credencials allunyades del model, aprovació humana per a les accions de risc i proves fetes per persones que coneixen les teves defenses.

Què són les vulnerabilitats dels LLM?

Les vulnerabilitats dels LLM són debilitats que fan que un sistema d’IA pugui ser enganyat, filtrar dades o causar danys, ja sigui per l’acció d’un atacant o pels seus propis errors.

Els deu riscos principals són la injecció de prompts, la divulgació d’informació sensible, l’agència excessiva, la cadena de subministrament, l’enverinament de dades i models, el consum il·limitat, la desinformació, l’exposició del context ocult, les debilitats dels vectors i els embeddings, i la gestió inadequada de la sortida.

Un LLM privat és segur?

És una opció més segura per a alguns usos, però no per defecte. Tens més control sobre la gestió de les dades si executes un model a la teva pròpia infraestructura o en un entorn al núvol. No hi ha cap manera automàtica d’evitar les injeccions de prompts, l’agència excessiva, l’enverinament o la desinformació.

Si l’allotges tu mateix, també ets responsable del model que baixes, inclosos els riscos de la cadena de subministrament i la infraestructura que necessita.