Prompt Injection: cómo evitar que un agente de IA se convierta en una puerta de entrada a tus sistemas empresariales
Imagina que una empresa implementa un agente de inteligencia artificial para consultar documentos internos, responder preguntas de sus empleados y recuperar información de diferentes sistemas corporativos. La herramienta funciona bien, reduce tiempos de búsqueda y permite acceder a información que antes requería consultar varias plataformas. Sin embargo, un día el agente recibe un documento aparentemente normal que contiene instrucciones ocultas para modificar su comportamiento. En lugar de limitarse a resumir el contenido, comienza a intentar revelar información interna o utilizar herramientas para las que tiene acceso.
Este escenario tiene nombre: prompt injection, una técnica mediante la cual un atacante introduce instrucciones diseñadas para manipular el comportamiento de un modelo de inteligencia artificial. Puede hacerlo directamente, escribiendo instrucciones maliciosas en una conversación, o de manera indirecta, incorporándolas en documentos, páginas web, correos electrónicos o cualquier otra fuente que el agente consulte durante su trabajo.
El riesgo aumenta cuando estos sistemas dejan de funcionar como simples asistentes y empiezan a interactuar con aplicaciones empresariales, consultar bases de datos o ejecutar operaciones mediante API. Una instrucción maliciosa podría llevar al agente a utilizar herramientas legítimas de una forma que sus desarrolladores nunca contemplaron.
Por eso, implementar inteligencia artificial en una empresa requiere algo más que elegir un buen modelo y conectarlo con las aplicaciones existentes. También es necesario entender cómo puede ser manipulado, qué información tiene disponible y cuáles son los límites de las acciones que puede ejecutar.
¿Qué es el prompt injection y cómo funciona?
Los modelos de lenguaje, conocidos como LLM (Large Language Models), procesan instrucciones y contenido en lenguaje natural para generar respuestas o realizar determinadas tareas. Su capacidad para interpretar información es precisamente lo que permite utilizarlos en asistentes virtuales, sistemas de atención al cliente y agentes capaces de interactuar con herramientas externas.
El problema aparece cuando el modelo recibe instrucciones que intentan alterar las reglas bajo las cuales debería operar. En un ataque de prompt injection, el contenido malicioso busca que la inteligencia artificial ignore sus instrucciones originales, revele información o realice acciones fuera de los límites establecidos.
A diferencia de una vulnerabilidad tradicional, este tipo de ataque no siempre requiere explotar un error en el código o acceder directamente a un servidor. En ocasiones, basta con introducir instrucciones manipuladas en una fuente de información que el modelo considera parte de su contexto.
Por ejemplo, un agente empresarial puede estar configurado para consultar documentos y resumirlos. Un atacante podría introducir en uno de esos archivos un texto que le indique al modelo que ignore la tarea original y trate de recuperar información confidencial de otras fuentes disponibles.
El modelo puede interpretar esas instrucciones como parte del contenido que debe procesar. Si la arquitectura no establece controles adicionales, existe la posibilidad de que termine ejecutando acciones que no corresponden a la solicitud inicial.
Conviene tener presente que el prompt injection no garantiza que el ataque tenga éxito. Su impacto depende del modelo, las herramientas disponibles, los permisos concedidos y las medidas de seguridad implementadas alrededor del agente. Sin embargo, cuando este tiene acceso a información sensible o puede ejecutar operaciones, una manipulación aparentemente sencilla puede convertirse en un incidente de seguridad.
Los dos tipos de prompt injection que deberían conocer las empresas
1. Prompt injection directo
Este ataque ocurre cuando el usuario introduce instrucciones maliciosas directamente en la conversación con el modelo. El objetivo es modificar el comportamiento del asistente y conseguir que ignore las restricciones que debería respetar.
Un ejemplo sería un empleado o usuario que escribe una solicitud diseñada para que el agente revele instrucciones internas, intente acceder a información restringida o utilice una herramienta fuera de su propósito habitual.
En un chatbot que únicamente responde preguntas generales, las consecuencias podrían limitarse a generar respuestas inadecuadas o revelar información que debería permanecer oculta. Sin embargo, en un agente conectado con sistemas empresariales, el alcance puede ser mayor.
Imaginemos un asistente que tiene acceso a un CRM y puede consultar los registros de clientes. Si sus permisos no están correctamente delimitados, una solicitud manipulada podría llevarlo a intentar recuperar información que el usuario no debería conocer.
La empresa debe entender que las instrucciones de seguridad incluidas en el prompt del sistema no constituyen una barrera de protección suficiente. Las restricciones importantes deben implementarse mediante controles técnicos independientes del modelo.
2. Prompt injection indirecto
Este escenario resulta especialmente relevante para los agentes empresariales porque no necesita que el atacante interactúe directamente con el asistente.
La instrucción maliciosa puede estar escondida en una página web, un documento PDF, un correo electrónico o cualquier contenido que el agente consulte durante una tarea. Cuando el modelo procesa esa información, puede encontrar instrucciones que intentan cambiar el objetivo de su trabajo.
Pensemos en un agente que ayuda al departamento de compras a comparar propuestas de proveedores. Para hacerlo, consulta documentos comerciales y páginas web. Uno de los archivos recibidos contiene instrucciones que intentan convencer al agente de enviar información interna a una dirección externa o de ignorar las condiciones de evaluación establecidas por la empresa.
El empleado que utiliza el agente puede no tener conocimiento de esas instrucciones. Desde su perspectiva, simplemente solicitó comparar varias propuestas. El contenido manipulado llegó a través de una fuente externa que el sistema consideraba necesaria para completar la tarea.
Este tipo de ataque demuestra por qué las empresas deben tratar los documentos y las fuentes externas como información potencialmente no confiable. Que un agente tenga permiso para leer un archivo no significa que deba obedecer las instrucciones que encuentre dentro de él.
¿Qué puede ocurrir cuando un agente de IA tiene acceso a los sistemas corporativos?
El impacto del prompt injection depende en buena medida de las capacidades que tenga el agente. Un modelo que únicamente genera texto presenta un escenario de riesgo distinto al de otro que puede consultar información confidencial, ejecutar consultas SQL o realizar operaciones mediante API.
Cuando se habilitan estas capacidades, el agente se convierte en un componente activo de la infraestructura tecnológica. Puede acceder a herramientas, procesar información y ejecutar acciones que tienen consecuencias sobre los sistemas de la organización.
Entre los principales riesgos se encuentran:
Exposición de información confidencial
Un agente conectado a documentos internos, bases de conocimiento o sistemas empresariales puede tener acceso a información que no debería compartirse con cualquier usuario.
Si un atacante consigue manipular su comportamiento, podría intentar obtener datos de clientes, información financiera, contratos o documentación interna. El riesgo aumenta cuando el agente utiliza una identidad con permisos generales en lugar de respetar los permisos específicos de cada usuario.
Ejecución de operaciones no autorizadas
Algunos agentes pueden crear registros, modificar información, enviar correos electrónicos o iniciar procesos empresariales. Si estas capacidades no cuentan con controles independientes, una instrucción manipulada podría provocar acciones no deseadas.
Por ejemplo, un agente comercial podría tener permiso para actualizar oportunidades en el CRM. Si también dispone de facultades para eliminar registros o modificar información contractual, el impacto de una manipulación sería considerablemente mayor.
Acceso a servicios y herramientas externas
Los agentes suelen conectarse con diferentes servicios mediante API, conectores o herramientas especializadas. Si una de estas integraciones tiene permisos excesivos, el agente podría utilizarla de forma distinta a la prevista.
Aquí existe una relación directa con la seguridad de las API: aunque el modelo interprete incorrectamente una instrucción, cada servicio conectado debe verificar por su cuenta si la operación solicitada está autorizada.
Filtración de información a través de respuestas
La información confidencial también puede salir de la organización mediante las respuestas generadas por el agente. Esto puede ocurrir cuando el modelo incorpora datos internos en una respuesta dirigida a un usuario que no tiene autorización para consultarlos.
Por eso, los controles de acceso deben aplicarse antes de entregar los datos al modelo y también antes de presentar sus respuestas al usuario. Confiar únicamente en que la inteligencia artificial identificará qué información puede revelar deja una parte importante de la seguridad en manos de un comportamiento probabilístico.
Cómo proteger los agentes de IA frente a ataques de prompt injection
1. Separar las instrucciones del sistema del contenido externo
Una de las primeras medidas consiste en distinguir claramente las instrucciones que definen el comportamiento del agente de la información que recibe para realizar sus tareas.
Los documentos, correos, páginas web y archivos externos deben tratarse como contenido no confiable. El agente puede analizarlos, resumirlos o extraer información, pero las instrucciones que encuentre en ellos no deberían modificar sus políticas de seguridad ni ampliar sus permisos.
Esta separación puede reforzarse mediante el diseño de los prompts, el uso de formatos estructurados y mecanismos que permitan identificar el origen de cada contenido. Sin embargo, la separación conceptual no elimina por completo el riesgo: los modelos todavía pueden interpretar de manera incorrecta información manipulada.
Por eso, las instrucciones del sistema deben complementarse con validaciones externas que controlen las operaciones disponibles y los datos a los que puede acceder el agente.
2. Aplicar el principio de mínimo privilegio
Un agente de IA debería tener únicamente los permisos necesarios para cumplir su función. Si su trabajo consiste en consultar el estado de los pedidos, no necesita acceso para modificar precios, eliminar clientes o administrar usuarios.
Este principio también debe aplicarse a las integraciones. Cada API, base de datos o herramienta conectada debería contar con una identidad propia y permisos delimitados.
Por ejemplo, un agente que consulta información del inventario puede utilizar una conexión de solo lectura. Si necesita actualizar existencias, esa operación debería habilitarse mediante una función específica, con validaciones adicionales y restricciones sobre los registros que puede modificar.
De esta manera, incluso si el agente recibe una instrucción maliciosa, las posibilidades de ejecutar acciones perjudiciales quedan limitadas por los permisos que realmente tiene disponibles.
3. Exigir validación humana para operaciones sensibles
No todas las acciones deberían ejecutarse automáticamente. Cuando un agente puede aprobar pagos, eliminar información, modificar contratos o enviar comunicaciones externas, conviene establecer mecanismos de confirmación humana.
Por ejemplo, un agente financiero puede preparar una solicitud de pago y verificar que los datos estén completos, pero la aprobación final debería quedar en manos de una persona autorizada. Este mecanismo, conocido como human-in-the-loop, permite incorporar supervisión humana en los puntos donde una decisión automatizada puede tener consecuencias importantes.
La confirmación debe mostrar claramente qué operación se realizará, sobre qué información y cuáles serán sus efectos. Un botón genérico de aprobación no aporta suficiente seguridad si el usuario no puede entender qué está autorizando.
4. Controlar las herramientas que puede utilizar el agente
Los agentes suelen disponer de herramientas o funciones que les permiten interactuar con otros sistemas. En el desarrollo de estas capacidades es importante definir qué puede hacer cada herramienta, qué parámetros acepta y bajo qué condiciones puede ejecutarse.
Una buena práctica consiste en evitar herramientas demasiado generales. En lugar de proporcionar una función que permita ejecutar cualquier consulta SQL, puede ser más seguro ofrecer operaciones específicas para consultar inventario, revisar pedidos o recuperar información de clientes.
También conviene validar los parámetros antes de ejecutar cada operación y limitar las respuestas para evitar que el agente reciba información innecesaria.
Este enfoque reduce la superficie de exposición y facilita las auditorías, porque cada herramienta tiene una función definida y un conjunto de permisos que pueden revisarse.
5. Registrar y supervisar las actividades del agente
Una empresa necesita saber qué hizo un agente, qué herramientas utilizó y qué información consultó durante una operación. Sin registros adecuados, investigar una actividad sospechosa puede convertirse en un proceso lento y complicado.
Los registros deberían incluir la identidad del agente, el usuario que inició la tarea, las herramientas invocadas, los recursos consultados y las operaciones realizadas. También es importante identificar errores, intentos de acceso denegado y patrones de actividad que se alejen del comportamiento habitual.
En determinados escenarios, conviene establecer alertas cuando un agente intenta acceder a información fuera de su ámbito, realiza demasiadas consultas o solicita ejecutar operaciones sensibles.
La supervisión debe permitir detener o revocar rápidamente una integración si se detecta un comportamiento anormal. También hay que proteger los propios registros para evitar que se conviertan en una fuente adicional de exposición de información confidencial.
OWASP y la seguridad de las aplicaciones basadas en inteligencia artificial
La seguridad de los sistemas de inteligencia artificial ya cuenta con marcos de referencia que ayudan a identificar y organizar sus principales riesgos.
Uno de ellos es el OWASP Top 10 for LLM Applications, desarrollado por OWASP (Open Worldwide Application Security Project), una organización internacional que publica recursos y estándares para mejorar la seguridad de las aplicaciones.
Esta guía identifica el prompt injection como uno de los riesgos relevantes en aplicaciones basadas en modelos de lenguaje. También aborda otros problemas, como el manejo inseguro de resultados generados por los modelos, la divulgación de información sensible y los permisos excesivos concedidos a los agentes.
Su utilidad está en ayudar a los equipos técnicos a revisar las aplicaciones desde una perspectiva de seguridad más amplia. No basta con comprobar que el modelo responde correctamente: también hay que evaluar cómo procesa información externa, qué herramientas puede utilizar y qué controles existen antes de ejecutar sus resultados.
Otro recurso importante es el OWASP Top 10 for Agentic Applications, orientado a los riesgos particulares de los sistemas agénticos. Este enfoque resulta especialmente útil para organizaciones que están pasando de asistentes conversacionales a agentes capaces de planificar tareas, utilizar herramientas y realizar operaciones de manera autónoma.
Ambas referencias pueden incorporarse a los procesos de diseño, desarrollo y pruebas de seguridad, especialmente cuando los agentes tienen acceso a información corporativa o participan en procesos críticos.
¿Cómo debería prepararse una empresa antes de implementar agentes de IA?
Antes de conectar un agente con los sistemas corporativos, conviene realizar una evaluación que permita conocer sus capacidades y los riesgos asociados.
El primer paso es definir exactamente qué tareas realizará y qué información necesitará consultar. A partir de allí, el equipo técnico puede identificar las API, bases de datos, documentos y herramientas que estarán disponibles para el agente.
Después es necesario establecer los permisos, las restricciones y las condiciones para ejecutar acciones. Las operaciones de consulta pueden tener un nivel de autonomía diferente al de aquellas que modifican información o generan compromisos económicos.
También es importante realizar pruebas de seguridad con escenarios de prompt injection directo e indirecto. Estas evaluaciones deben incluir documentos manipulados, instrucciones contradictorias, intentos de acceso a información restringida y solicitudes que busquen utilizar herramientas fuera de su propósito.
Finalmente, la empresa debe definir procedimientos para actualizar el agente, revisar sus permisos, supervisar su comportamiento y responder ante incidentes. La seguridad no termina cuando el sistema entra en producción: debe mantenerse durante todo su ciclo de vida.
Conclusión: la inteligencia artificial necesita límites que no dependan de la inteligencia artificial
Los agentes de IA están cambiando la manera en que las empresas consultan información, integran aplicaciones y automatizan procesos. Su capacidad para interpretar instrucciones y utilizar herramientas abre oportunidades importantes, pero también introduce riesgos que deben abordarse desde el diseño de la arquitectura.
El prompt injection demuestra que un agente puede recibir contenido malicioso a través de fuentes que parecen legítimas y que sus instrucciones pueden ser manipuladas durante una tarea. Cuando además tiene acceso a sistemas corporativos, las consecuencias pueden ir mucho más allá de generar una respuesta incorrecta.
Proteger estos entornos requiere separar las instrucciones del contenido externo, limitar los permisos, validar las operaciones, supervisar las herramientas y establecer confirmaciones humanas para las acciones sensibles. También exige realizar pruebas periódicas y adoptar marcos de referencia especializados en seguridad de aplicaciones de inteligencia artificial.
La automatización empresarial puede avanzar sin entregar el control de los sistemas a un modelo de lenguaje. Para conseguirlo, las reglas de acceso, las autorizaciones y las restricciones deben estar implementadas en la arquitectura tecnológica, no depender únicamente de lo que el agente entienda o decida hacer.
Un agente de IA puede interpretar instrucciones y tomar decisiones, pero los límites de lo que está autorizado a hacer siempre deben estar bajo el control de la empresa.