Que é a seguridade dos LLM? Como mitigar os riscos de seguridade do OWASP Top 10

Un ataque que engana unha IA para que trate as instrucións dun atacante como ordes —a inxección de prompts— ocupa o n.º 1 do OWASP Top 10 for LLM Applications en todas as edicións desde 2023.

A lista é o máis parecido a un consenso que existe na seguridade da IA. O proxecto comezou como un pequeno grupo de profesionais da seguridade e hoxe conta coas achegas de máis de 600 expertos colaboradores en máis de 18 países.

Somos unha empresa de IA que publica unha guía sobre como se convence a IA para facer cousas, así que non imos finxir que isto está resolto. Wilson, que codirixe o proxecto OWASP, foi bastante claro sobre as defensas actuais: «...francamente, non creo que esteamos nun 99 %».

A edición de 2026 comeza na mesma liña. O responsable do proxecto pídenos «deixar de tentar construír un modelo que non poida ser enganado» e deseñar o sistema que o rodea para que un modelo enganado non poida romper nada importante.

Mantemos esa postura ao longo dos 10 riscos da lista de 2026 de OWASP.

Que significa a seguridade dos LLM?

A seguridade dos LLM consiste en protexer os modelos de IA e as aplicacións que os usan fronte a ataques e usos indebidos. O risco crece segundo aquilo ao que estea conectado o modelo: os ficheiros e datos que pode ler e as ferramentas que pode usar, como o correo electrónico, a busca ou a base de datos dunha empresa.

Nun software ben protexido hai unha liña firme entre as instrucións que segue un programa e a información que procesa. Pero os LLM non teñen esa liña.

Todo o que le o modelo chega como un único e longo fluxo de texto: as instrucións do desenvolvedor, a túa pregunta, unha páxina web que consultou. Os modelos de IA deberían saber en todo momento quen está a falar, xa sexa o desenvolvedor, o usuario ou o propio modelo razoando sobre un problema.

Pero os investigadores Jasmine Cui e Charles Ye descubriron que os modelos adiviñan quen fala principalmente polo xeito en que soa o texto. Así, se un atacante escribe algo que soa ao razoamento do propio modelo, este pode crer que a idea se lle ocorreu a el. Isto é un problema para calquera sistema de seguridade que dependa de que o modelo saiba quen manda.

Atopámonos co mesmo problema nos nosos propios axentes de IA. O noso CISO, Kyle Polley, díxolle a ISMG que os axentes «poderían non seguir as políticas aínda que as engadas ao prompt do sistema». Por iso creamos Numbat, unha ferramenta de código aberto que comproba o que un axente está a piques de facer e pode bloquealo se a acción incumpre unha regra de seguridade configurada.

A seguridade dos LLM consiste en aceptar que o modelo ás veces recibirá ordes da persoa equivocada e en poñer arredor del barreiras de protección para a IA que sigan funcionando cando isto pase.

Cales son as boas prácticas de seguridade dos LLM?

Repasaremos o OWASP Top 10 for LLM Applications 2026 en orde, do n.º 1 ao n.º 10.

Para cada risco, atoparás unha explicación en linguaxe sinxela de como poden torcerse as cousas e un exemplo real. Despois veremos as prácticas que poden axudar a evitalo ou, polo menos, a limitar os danos.

1. Contén a inxección de prompts

Unha inxección de prompts prodúcese cando un atacante fai que unha IA siga instrucións que non debería. Esas instrucións poden chegar directamente nun chat ou estar agochadas nun correo electrónico, unha páxina web ou un documento.

O segundo tipo coñécese como inxección indirecta de prompts. Pídeslle ao teu asistente que resuma un documento. Quen o escribiu indicoulle ao asistente que lle envíe os teus ficheiros privados. Se o asistente segue esas instrucións, o autor do documento tomou prestado, en efecto, o teu acceso.

PCMag compara a seguridade dos prompts con tapar buratos nunha pedra porosa. Selas unha abertura e a auga atopa outra. «Un ataque abre camiño; corríxese, pero quedan por descubrir infinidade de vías de ataque simplemente polo dinámicos que son sistemas como os LLM».

Exemplo: En xuño de 2025, investigadores de Aim Security descubriron EchoLeak, unha vulnerabilidade que enganaba a Microsoft 365 Copilot para que filtrase información privada da empresa. Cando un empregado facía unha pregunta rutineira de traballo, Copilot podía recuperar o correo, seguir as instrucións agochadas nel e enviarlle información confidencial ao atacante. O ataque eludiu os controis pensados para detectar instrucións maliciosas e eliminar ligazóns sospeitosas.

Que podes facer:

• Segue a «Regra de dous» de Meta: EchoLeak necesitaba unha IA que puidese ler datos da empresa, ler correo externo e enviar información ao exterior, e tiña as tres capacidades. Limitala a dúas delas impide que unha inxección de prompts obteña demasiado control. Se a tarefa require as tres, esixe aprobación humana antes de cada acción.
• Fai probas fronte a atacantes que coñezan as túas defensas: Dálles aos teus probadores de seguridade as regras e os filtros que estableciches e déixaos buscar a maneira de sortealos. Nun estudo, os atacantes que se adaptaron ás defensas tiveron éxito máis do 90 % das veces contra a maioría das 12 defensas probadas.

2. Impide as filtracións de información sensible

Cando os sistemas de IA lle dan información privada a persoas que non deberían vela, chámase divulgación de información sensible. Isto pode supoñer revelar os datos de pagamento dun cliente ou deixar conversas privadas nunha base de datos compartida.

Moitas filtracións comezan por «compartir de máis». Imaxina que unha empresa conecta a súa IA a unidades e bases de coñecemento con permisos laxos. A IA recupera todo o que ten ao seu alcance, exactamente como foi deseñada. Ninguén ten que forzar a entrada, pero, a efectos prácticos, o LLM xa está comprometido.

Exemplo: En xaneiro de 2025, investigadores de Wiz atoparon unha base de datos de DeepSeek exposta a internet con máis dun millón de rexistros, incluído o historial de chats e claves de API, que o software usa para acceder a outros servizos. Os investigadores non tiveron que convencer o modelo para que revelase nada.

Que podes facer:

• Comproba o acceso antes de que a IA lea os datos: A túa aplicación debería comprobar que documentos pode ver a persoa que fai a pregunta antes de pasarllos ao modelo.
• Protexe os rexistros que deixa a túa IA: Elimina os datos privados e as claves secretas antes de gardar os rexistros de actividade, esixe inicio de sesión e restrinxe o acceso ás persoas que os necesiten. Establece un período de conservación para que eses rexistros non se acumulen indefinidamente.

3. Pon freo á axencia excesiva

As IA con axencia excesiva teñen máis poder do que require o seu traballo: ferramentas que non necesitan, permisos que van máis alá da súa tarefa ou liberdade para actuar sen comprobacións. Aquí a causa é irrelevante.

Unha inxección de prompts, un erro ou un modelo que simplemente se equivoca levan ao mesmo resultado. A IA acabará facendo algo destrutivo se ten a capacidade de facelo.

Exemplo: En xullo de 2025, o fundador de SaaStr, Jason Lemkin, informou de que o axente de programación de Replit borrara a súa base de datos de 1206 rexistros de directivos, a pesar das instrucións de non facer cambios. Nun principio, o axente dixo que os datos non se podían restaurar, aínda que despois resultou posible recuperalos. Jason descubriu que dicirlle que non tocase a base de datos non lle quitara a capacidade de borrala.

Ampliar

Fonte: X

Que podes facer:

• Elimina as capacidades que a tarefa non necesita: Limita tanto as ferramentas que recibe un axente como o que poden facer esas ferramentas. Un asistente que resume correos necesita permiso para lelos, non para envialos nin borralos.
• Sitúa as comprobacións de permisos fóra da IA: Cada vez que se solicite unha acción, fai que se contraste coas túas regras de seguridade e esixe que unha persoa a aprobe.

4. Revisa o que entra na cadea de subministración da túa IA

Poucas empresas crean IA desde cero, e cada ano son menos. Segundo a enquisa The State of Generative AI in the Enterprise 2025 de Menlo Ventures, o 53 % comprou modelos de IA en 2024, unha cifra que subiu ata o 76 % en 2025.

Na maioría dos casos, as empresas descargan modelos de plataformas como Hugging Face, adéstranos máis con conxuntos de datos que recompilaron outras persoas e engádenlles complementos e paquetes de código escritos por descoñecidos.

Cada unha desas pezas é unha porta de entrada. Se alguén manipula unha, o problema chega dentro do teu produto.

Exemplo: Os repositorios públicos de modelos de Hugging Face pasaron de 2,43 a 2,96 millóns entre xaneiro e agosto de 2026. Con todo, en xullo de 2026, os modelos de OpenAI eludiron os controis pensados para mantelos desconectados de internet durante unhas probas de seguridade internas e entraron en partes dos sistemas de Hugging Face. De feito, un axente recuperou 14 credenciais de acceso expostas publicamente, comprobou que funcionaban e compartiunas con outros axentes. Os axentes chegaron a explotar vulnerabilidades que lles permitiron executar código nos servidores de Hugging Face.

«Estamos a impoñer requisitos máis estritos de aliñamento ao longo de todo o ciclo de vida dun modelo e a crear contornos illados máis estancos, restrinxindo o acceso a internet e controlando aínda máis o acceso aos pesos dos modelos», di o informe de OpenAI.

Que podes facer:

• Fixa os modelos nunha versión exacta e verifícaos: Fixa cada modelo nunha versión revisada e comproba a pegada dixital do seu ficheiro antes de cargalo, para que non se poida colar un ficheiro substituído baixo a mesma etiqueta. OWASP tamén recomenda as sinaturas dixitais, cunha advertencia: unha sinatura demostra de onde vén un modelo, non que sexa seguro.
• Revisa cada paquete que suxira a túa IA: Antes de instalar un paquete de código recomendado por un asistente de IA, confirma que existe, que é o paquete que querías e que procede do editor que esperas.

5. Protéxete contra o envelenamento de datos e modelos

Unha IA envelenada aprende de datos corrompidos. Poden ser os exemplos cos que se axustou ou unha base de coñecemento na que busca respostas. O modelo segue parecendo que funciona; simplemente aprende as leccións equivocadas e, ás veces, aprende a comportarse mal só cando ve unha frase desencadeante concreta.

A frase pasará desapercibida en todas as probas que fagas ata que alguén a use.

Ampliar

Ademais, é moi difícil de desfacer. O envelenamento non é un erro que se poida corrixir cun parche. Se os teus datos son incorrectos, quizais teñas que revisalos de novo, volver adestrar o modelo ou substituílo por completo.

Exemplo: En outubro de 2025, investigadores de Anthropic, do UK AI Security Institute e do Alan Turing Institute demostraron que 250 documentos envelenados podían ensinar a un modelo a xerar texto sen sentido sempre que atopaba un desencadeante concreto. O mesmo número funcionou nos catro tamaños de modelo probados, aínda que o máis grande se adestrou con máis de 20 veces máis datos limpos.

Que podes facer:

• Rexistra de onde proceden os teus datos: Garda un rexistro de cada conxunto de datos e modelo que uses, da súa procedencia e do que cambiou entre versións. Recomendamos usar control de versións para os conxuntos de datos para que, se aparece un envelenamento, poidas volver a unha versión limpa e descubrir como entrou.
• Busca portas traseiras: Unha «porta traseira» é un comportamento oculto que un atacante instala nun modelo e que agarda por unha frase concreta ou outro desencadeante para activarse. Detéctaas con entradas deseñadas para que o modelo incumpra as súas regras habituais.

6. Pon límite ao consumo ilimitado

Cando as IA non teñen ningún límite sobre canto traballo poden facer ou canto poden custar, considérase que o seu consumo é «ilimitado». A maioría dos servizos de IA cobran por uso, polo que un atacante podería disparar a túa factura ou construír unha copia do teu modelo.

OWASP chama ao problema de fondo «asimetría de custos». Unha solicitude curta e barata pode desencadear cálculos custosos pola túa parte.

Exemplo: En maio de 2024, o Threat Research Team de Sysdig descubriu un novo ataque chamado «LLMjacking». Un grupo de atacantes atacou 10 servizos de LLM aloxados na nube usando credenciais roubadas. Entraron a través dunha versión vulnerable de Laravel e despois descubriron o que permitían facer as credenciais e as cotas existentes, co evidente propósito de vender o acceso. Tamén consultaron moitas opcións de configuración dos rexistros, probablemente para evitar ser detectados. Segundo Sysdig, no peor dos casos, o custo para a vítima podería superar os 46 000 dólares ao día.

Que podes facer:

• Establece orzamentos que deteñan o gasto: Fixa límites de gasto estritos para usuarios individuais, claves de API, equipos e para a conta no seu conxunto. Aplícaos en calquera punto polo que poidan entrar solicitudes.
• Dálle a cada tarefa un punto de parada: Limita canto tempo pode executarse unha tarefa, canto texto pode procesar e xerar e cantas chamadas a ferramentas pode facer. Engade cortes automáticos para os axentes que se repitan ou superen o que teñen asignado.

7. Detecta a desinformación antes de actuar

Cando unha IA produce algo falso que parece correcto e alguén, ou algo, actúa en consecuencia, chámase desinformación. O risco principal non é tanto a resposta errónea en si como o feito de que esa resposta se considere fiable e se utilice.

O historial de incidentes suxire que os profesionais non estaban tan preocupados pola desinformación como deberían. Segundo a carta de presentación da edición de 2026, os votantes situárona preto do final da lista, pero, a xulgar polos incidentes reais, está entre os primeiros postos.

Exemplo: En 2025, Deloitte Australia entregou unha revisión dos sistemas informáticos de prestacións sociais no marco dun contrato público de 440 000 dólares australianos. Na Universidade de Sydney, o investigador Chris Rudge detectou referencias a investigacións inexistentes e unha cita inventada dunha sentenza dun tribunal federal. O informe revisado revelou que Deloitte utilizara Azure OpenAI GPT-4o na súa metodoloxía, e a firma aceptou devolver o último pagamento. E, por desgraza, tratábase dunha revisión de garantía.

Que podes facer:

• Comproba que as probas avalan a resposta: Fundamenta as afirmacións en fontes actuais e autorizadas. Para unha resposta sobre unha política, recupera a política aprobada e comproba que respalda a conclusión, incluídas as súas excepcións.
• Verifica antes de que o sistema actúe: Se un axente afirma que un cliente superou unha verificación de identidade, confírmao co sistema de verificación antes de liberar un pagamento. Esixe aprobación humana para as decisións con consecuencias importantes e pon as probas que as respaldan á disposición de quen as revise.

8. Limita os danos da exposición do contexto oculto

As aplicacións de IA danlle ao modelo instrucións e información de contexto que os usuarios normalmente non ven. Isto pode incluír o prompt do sistema, as políticas internas, as descricións das ferramentas dispoñibles e as regras sobre quen pode usalas. Unha exposición do contexto oculto prodúcese cando o modelo lle revela esa información a alguén.

En 2026, OWASP ampliou esta entrada, que antes se chamaba «filtración do prompt do sistema», porque o prompt do sistema é só unha parte do que pode escapar. O perigo depende do que poñas aí. A filtración dunha guía de ton de voz resulta lixeiramente vergonzosa, pero a dunha clave de API dálle a alguén acceso á túa base de datos confidencial.

Exemplo: En febreiro de 2023, uns usuarios conseguiron que Bing Chat de Microsoft revelase as súas instrucións internas. Un dos intentos exitosos foi o de Marvin von Hagen, que afirmou ser un desenvolvedor de OpenAI e pediu as instrucións para poder configurar o modelo. Bing revelou as regras que rexían as súas buscas, respostas e comportamento de seguridade, xunto co seu nome interno, Sydney. Entre as instrucións reveladas había unha que lle indicaba manter esas instrucións en segredo.

Que podes facer:

• Mantén os segredos fóra do contexto do modelo: Parte da base de que calquera cousa que o modelo poida ler podería acabar sendo visible para os usuarios; garda os contrasinais, as claves de API e os tokens de acceso nun sistema de xestión de segredos separado.
• Fai que os permisos se manteñan aínda que se filtren as regras: Aplica as comprobacións de acceso no código da túa aplicación. Se unha ferramenta está restrinxida aos administradores, comproba os permisos da conta do usuario antes de executala.

9. Blinda os teus vectores e embeddings

Cando unha IA usa a busca vectorial para atopar respostas nos documentos da túa empresa, non busca directamente no texto. Os documentos convértense en “embeddings”, que son longas listas de números que recollen o significado de cada fragmento, e gárdanse nunha base de datos vectorial. As preguntas convértense do mesmo xeito, e o sistema recupera os fragmentos cuxos números están máis próximos.

OWASP resume as catro formas en que pode fallar: o envelenamento fai que o sistema se equivoque, a inversión fai que filtre información, o bloqueo fai que deixe de responder e un control de acceso defectuoso fai que lle entregue calquera cousa a calquera persoa.

Os números non son a abstracción segura que parecen. Os embeddings almacenados poden converterse de novo en texto, e un método recuperou exactamente o 92 % dos fragmentos curtos de 32 tokens nas súas probas. Así, unha copia de seguranza filtrada “só con embeddings” tamén pode expoñer o contido dos documentos.

Exemplo: Nunha investigación presentada en USENIX Security 2025, os investigadores demostraron que un único documento coidadosamente elaborado podía impedir que unha IA respondese a unha pregunta concreta. Engadírono á colección na que buscaba a IA. Cando a IA o atopaba, podía dicir que non tiña información suficiente ou que responder non sería seguro. O documento non precisaba indicarlle á IA que ignorase as súas regras. Isto chámase “bloqueo da recuperación”.

Que podes facer:

• Mantén índices separados para os datos públicos e os privados: Non mestures contido web extraído con datos de socios ou con documentos internos confidenciais. Separa fisicamente os datos segundo o nivel de confianza en lugar de etiquetar o contido nun único índice: así eliminas toda unha clase de erros de configuración, e o contido extraído de internet non pode acabar xunto aos documentos do teu consello de administración.
• Trata os embeddings como os documentos dos que proceden: Cífraos, protexe as copias de seguranza da base de datos vectorial ademais dos ficheiros de orixe e elimina os embeddings cando elimines o orixinal. As claves de API do teu servizo de embeddings deben manterse en segredo.

10. Revisa a saída da IA antes de transmitila

Sempre que unha aplicación pasa a saída da IA a outro sistema sen verificar se é segura para usala alí, está a xestionar incorrectamente a saída do LLM.

Esta entrada tamén abrangue o código inseguro que os asistentes de programación con IA xeran a grande escala. Polo tanto, cada liña que escribe un asistente tamén é saída.

Exemplo: En 2025, o investigador Johann Rehberger demostrou como o asistente de programación Amp de Sourcegraph podía filtrar o contido dos chats simplemente mostrando unha imaxe. Utilizou a inxección de prompts para facer que Amp incluíse información privada no enderezo web dunha imaxe. A aplicación descargou automaticamente esa imaxe e enviou así a información ao servidor del. O fallo na xestión da saída foi esa solicitude automática: o texto xerado polo modelo converteuse nunha conexión cun servidor externo que levaba consigo datos privados.

Que podes facer:

• Fai que a saída sexa segura para o seu destino: Comproba e trata as respostas segundo o lugar ao que vaian. Nunha páxina web, evita que o texto xerado se converta en código executable. Nunha base de datos, usa consultas preparadas que manteñan os valores proporcionados separados dos comandos.
• Impide que as respostas establezan conexións externas automáticas: Desactiva de forma predeterminada a carga automática de imaxes, as vistas previas de ligazóns e as páxinas incrustadas nas respostas do modelo. Restrinxe as conexións necesarias a destinos aprobados explicitamente.

Como protexe Perplexity os LLM?

Partimos da base de que todos os riscos anteriores acabarán materializándose, e deseñamos os sistemas para que, cando iso ocorra, non poidan causar moito dano. O noso CISO, Kyle Polley, explicou como o facemos nun obradoiro recente.

• O axente ten o seu propio ordenador, que comeza baleiro: As ferramentas de axentes instaladas no teu portátil poden acceder aos ficheiros, ás aplicacións e ás credenciais gardadas nel. Perplexity Computer funciona ao revés. Cada tarefa execútase no seu propio contorno illado e, como di Polley, “de forma predeterminada non ten acceso a nada”.
• O axente nunca ve os contrasinais: As credenciais dos servizos conectados gárdanse fóra do contorno illado. Cando o axente precisa acceder a un servizo como GitHub, envía unha solicitude sen ningunha credencial. Unha pasarela comproba que o destino e a solicitude son os esperados e engade as credenciais xusto antes de que a solicitude saia. O axente pode usar a conexión sen chegar a ter as claves.
• Os teus permisos mantéñense e podes restrinxilos aínda máis: As conexións establecidas mediante OAuth conservan os teus permisos de acceso no servizo conectado. Se ti non podes ver algo, o teu axente tampouco.
• Tratamos cada páxina web como unha descoñecida: Creamos BrowseSafe para Comet, o noso navegador agéntico, porque as ferramentas que probamos non cubrían as nosas necesidades no uso real. O navegador analiza as páxinas web e outro contido externo, incluídos os correos electrónicos, en busca de inxección de prompts. Publicamos como código aberto tanto o modelo como o conxunto de datos.
• Vixiamos o axente e as máquinas nas que se executa: Numbat sitúase entre o momento en que un axente decide actuar e a execución real da ferramenta. Numbat rexistra a actividade dos axentes de programación compatibles e pode bloquear as accións que incumpran as políticas configuradas antes de que se executen. Bumblebee inventaría os paquetes de software de portátiles, servidores e pipelines de compilación, e sinala os que se sabe que son maliciosos. Ambos son de código aberto.
• Os provedores de modelos non conservan os teus datos: Temos acordos de retención cero de datos cos nosos provedores externos de LLM. Os administradores de Enterprise tamén poden configurar a retención de datos da propia Perplexity para que sexa de tan só 24 horas.

Creamos Numbat de maneira proactiva, por un motivo que Polley resume nunha frase: “Canta máis autonomía lle dás a un axente, máis risco hai”.

Preguntas frecuentes sobre a seguridade dos LLM

Cal é o LLM máis seguro?

Ningún LLM fai que unha aplicación sexa segura por si só: os modelos aínda poden confundir o contido que deberían ler con instrucións que deberían seguir. As defensas que parecen sólidas nas probas estándar tamén poden ceder baixo presión.

Unha pregunta mellor é que configuración é a máis segura para o teu caso de uso. Iso significa permisos limitados, credenciais lonxe do modelo, aprobación humana para as accións arriscadas e probas realizadas por persoas que coñezan as túas defensas.

Que son as vulnerabilidades dos LLM?

As vulnerabilidades dos LLM son debilidades que permiten que un sistema de IA sexa enganado, filtre datos ou cause danos, xa sexa por acción dun atacante ou polos seus propios erros.

Os dez riscos principais son a inxección de prompts, a divulgación de información sensible, a axencia excesiva, a cadea de subministración, o envelenamento de datos e modelos, o consumo ilimitado, a desinformación, a exposición do contexto oculto, as debilidades de vectores e embeddings e a xestión incorrecta da saída.

É seguro un LLM privado?

É unha opción máis segura para algunhas cousas, pero non de por si. Tes máis control sobre o tratamento dos datos se executas un modelo na túa propia infraestrutura ou nun contorno na nube. Non hai ningunha forma automática de evitar as inxeccións de prompts, a axencia excesiva, o envelenamento ou a desinformación.

Se aloxas ti mesmo o modelo, tamén es responsable do modelo que descargas, incluídos os riscos da cadea de subministración e a infraestrutura que require.