Prompt injection: cómo frenar los riesgos en agentes de IA

El prompt injection plantea un límite básico: un correo que lea tu agente no puede convertirse en permiso para enviar otro mensaje, exportar datos de clientes o modificar una oportunidad de venta. Open Worldwide Application Security Project (OWASP) clasifica la inyección de prompts como LLM01 en su Top 10 para aplicaciones con LLM. Para quienes desarrollan estas aplicaciones, la respuesta práctica es limitar lo que pueden hacer incluso cuando el modelo obedece una instrucción equivocada. Hoy ninguna defensa resuelve por completo el problema.

Verificado con las guías vigentes de OWASP y Anthropic el 26 de octubre de 2026. Los escenarios de correo y CRM que aparecen a continuación ilustran diseños posibles; no son resultados de implementaciones reales.

¿Qué es el prompt injection?

El prompt injection ocurre cuando una entrada desvía a un modelo de lenguaje de las instrucciones que debería seguir. Un modelo de lenguaje de gran tamaño, o LLM, interpreta el lenguaje para generar respuestas y proponer acciones. El problema empieza cuando obedece algo que solo debería leer.

Imagina que un empleado revisa una carta de un proveedor. La carta puede describir un problema con una entrega; no puede concederle al proveedor acceso a tu base de datos de clientes. Un agente necesita distinguir de la misma manera entre información y autoridad, y la aplicación debe imponer esa separación mediante controles.

OWASP identifica tanto la entrada directa del usuario como el contenido externo indirecto como vías de entrada en LLM01:2025: inyección de prompts. El límite importante es quién puede definir la tarea y los permisos, no si el texto sospechoso suena profesional.

Una respuesta equivocada no implica necesariamente una inyección. El modelo puede inventar un dato sin que nadie lo manipule desde fuera. La inyección consiste específicamente en introducir contenido que dirija su comportamiento. Ambos problemas pueden causar daños, pero un filtro que busque instrucciones hostiles no detectará todos los errores habituales del modelo.

¿Cómo funciona la inyección de prompts en la IA generativa?

El modelo lee juntas las instrucciones y la información necesaria para la tarea, y puede atribuir a esa información una autoridad que no le corresponde. Los roles y las etiquetas de origen ayudan a distinguirlas, pero no sustituyen los controles de acceso.

Un agente añade un paso con consecuencias: la aplicación convierte una acción propuesta en una llamada a una herramienta. Una herramienta es una función que permite hacer algo fuera de la conversación, como buscar registros o enviar un mensaje. Si la aplicación ejecuta todo lo que propone el modelo con credenciales de amplios permisos, un error de interpretación del lenguaje puede convertirse en una acción sobre el negocio.

Ese es el límite al que llega cualquier agente que use herramientas: entender una solicitud no demuestra que esté autorizada.

Ejemplos de prompt injection: ataques directos e indirectos

La diferencia está en la vía por la que llega la instrucción hostil. Estos ejemplos describen lo que se intenta conseguir sin publicar el texto del ataque.

Inyección directa de prompts

Un cliente escribe a un asistente de soporte e intenta convencerlo de que revele las notas de la cuenta de otro cliente. Para ello, finge que la solicitud tiene una autorización interna especial. El atacante utiliza directamente el canal de entrada de la aplicación.

La defensa debe incluir un servicio de registros que compruebe a qué puede acceder el cliente autenticado. Aunque el modelo se crea la historia, ese servicio debe denegar el acceso al registro ajeno. Una instrucción de rechazo en el prompt del sistema sirve como orientación; la comprobación de acceso a los registros es lo que hace cumplir el límite.

Prompt injection indirecto

Un fundador que gestiona las ventas pide a un agente que resuma el correo de un cliente potencial y sugiera el siguiente paso. El correo contiene material diseñado para desviar al agente hacia la exportación de otros contactos del sistema de gestión de relaciones con clientes (CRM) a un destinatario externo. La solicitud del fundador es legítima; la instrucción hostil procede del correo que se está procesando.

La misma vía de entrada puede ser una página web, un documento, un archivo adjunto o el resultado de una herramienta. Que un registro esté almacenado dentro de la empresa no lo vuelve confiable: el texto que ahora está en tu CRM podría haberlo escrito un cliente. Anthropic, la empresa que desarrolla el modelo de lenguaje Claude, trata estas fuentes de terceros como un modelo de amenazas específico en su guía de protección frente al prompt injection.

En un agente de correo, quien envía un mensaje nunca debe heredar los permisos del propietario del buzón sobre las herramientas solo porque este haya pedido un resumen.

¿En qué se diferencia el prompt injection de un jailbreak?

Un jailbreak intenta eludir las restricciones de seguridad de un modelo. El prompt injection también puede atacar la tarea habitual o los permisos de la aplicación. Un resumen de ventas manipulado o una actualización de contacto no autorizada pueden parecer inofensivos para un sistema de moderación de contenido y, aun así, infringir las reglas del negocio.

Usa tanto protecciones de contenido como comprobaciones de autorización. Responden a preguntas distintas.

Por qué los ataques de prompt injection ponen en riesgo al negocio

El daño aumenta con los datos y las acciones a los que tiene acceso el agente. La guía de OWASP sobre autonomía excesiva aborda este problema por separado e identifica el exceso de funciones, permisos y autonomía como causas de comportamientos dañinos de los agentes.

En un sistema de correo o CRM, las consecuencias se traducen en problemas de negocio reconocibles:

• Se filtran datos privados. Una respuesta, un archivo adjunto, una solicitud saliente o un mensaje incluye información que el destinatario no debería recibir.
• Se modifican registros sin autorización. El agente edita una cuenta, borra historial útil o cambia la etapa de una oportunidad de venta porque el texto recuperado lo desvió de su tarea.
• Se distorsiona una decisión sin que resulte evidente. Un cliente potencial parece cumplir mejor los criterios comerciales, una queja desaparece de un resumen o un proveedor recibe una recomendación injustificada.

El acceso de solo lectura es más limitado que el de escritura, pero no impide por sí mismo que se filtren datos confidenciales. Si la aplicación recupera registros privados y puede revelarlos en una respuesta o mediante una conexión saliente, la confidencialidad sigue necesitando protección.

Unit 42, de Palo Alto Networks, documentó instrucciones maliciosas insertadas en contenido web en línea en una investigación publicada el 3 de marzo de 2026. Encontrar un intento no demuestra que todos sus objetivos lo hayan seguido. Sí demuestra por qué hay que incluir el contenido externo en el modelo de amenazas antes de permitir que un agente actúe.

Los fundadores deben aprobar el daño máximo que se permite causar a un flujo de trabajo. Los desarrolladores deben hacer que ese límite se cumpla en el acceso a datos y herramientas. Los operadores necesitan poder pausar la ejecución e investigar cuando se ponen a prueba esos límites.

Cómo evitar que el prompt injection se convierta en un incidente

Diseña el sistema asumiendo que una inyección podría superar las defensas. El siguiente diseño de controles se recomienda para un agente de correo o CRM y aplica las orientaciones de OWASP sobre privilegios y aprobación a un flujo de trabajo concreto. No es una evaluación comparativa de productos ni una garantía de inmunidad.

Empieza por los permisos reales de la herramienta. Una función llamada «resumir el correo» no está limitada a hacer resúmenes si la credencial que utiliza permite enviar mensajes y borrar correos. Comprueba la configuración de la cuenta y del servicio que hay detrás, no solo el nombre de la función.

Después, controla los datos que salen de la aplicación. Una lista de destinos de red permitidos ayuda a reducir las vías de filtración. Pero permitir el acceso a un servicio de correo no autoriza a todos los destinatarios, y permitir un dominio de CRM no autoriza cualquier cuenta u operación de exportación. Valida también la solicitud dentro del servicio permitido.

La guía de despliegue seguro de Anthropic describe cómo mantener las credenciales fuera del entorno del agente, restringir el acceso a la red y validar las solicitudes mediante un proxy. Un proxy es un intermediario que puede aplicar políticas antes de reenviar una solicitud. En una integración de correo alojada, ese control puede recaer en tu propio servicio de herramientas: el servicio conserva la credencial y rechaza las operaciones que exceden el alcance autorizado.

Para conocer el conjunto más amplio de comprobaciones de entrada, salida y ejecución, consulta la guía de controles de seguridad para IA.

Cómo aplicar las recomendaciones de Anthropic al contenido recuperado

Anthropic recomienda pasar el material de terceros en bloques tool_result, identificar su origen, establecer una política explícita para el contenido no confiable y codificar las cadenas en JSON en lugar de insertarlas en instrucciones de texto libre. También recomienda examinar las salidas de las herramientas y supervisar el comportamiento. Consulta la guía vigente de Claude.

En el ejemplo de ventas, conserva el cuerpo del correo del cliente potencial de forma que siga siendo identificable como un mensaje de ese remitente. No lo copies dentro de una instrucción privilegiada solo porque el modelo lo haya resumido en un paso anterior. Mantén la referencia a la fuente al pasar la información extraída a otro paso.

JSON es un formato de datos estructurados. Escapar correctamente su texto evita que este rompa la serialización que lo contiene; no impide que su significado persuada al modelo. Trata la recomendación de codificación como una capa más y sigue haciendo cumplir la autorización por otros medios.

Vincula la aprobación a la acción exacta que se va a ejecutar

Un botón de revisión solo protege al negocio si la ejecución depende de lo que la persona revisó. «Continuar procesando esta cuenta» es demasiado impreciso para un agente que puede enviar archivos adjuntos o modificar registros de clientes.

Piensa en una propuesta para responder a un cliente potencial y actualizar una oportunidad de venta. Quien la revise necesita ver el destinatario real, el mensaje, la lista de archivos adjuntos, el registro afectado y los valores de los campos antes y después del cambio. La aplicación debe conservar la propuesta aprobada y ejecutar esa versión. Si después el modelo cambia el destinatario o un archivo adjunto, debe exigir una nueva revisión.

Además, la aprobación debe proceder de una persona autenticada con la autoridad necesaria. Una frase dentro de un correo que afirme que alguien ya aprobó el trabajo es contenido de la fuente, no un evento de aprobación. El modelo no debe poder crear su propio registro de aprobación ni acceder a otra herramienta que eluda el control.

Mantén la acción pendiente si la persona encargada de revisarla la rechaza, la aprobación vence o el sistema de revisión no está disponible. Un tiempo de espera agotado no debe convertirse en permiso de forma silenciosa. Diseña los reintentos para que un fallo de entrega no provoque el envío repetido del mismo mensaje aprobado.

Estas son recomendaciones de implementación para el flujo de trabajo, no una afirmación de que la revisión humana detecte todos los ataques. La guía de IA con supervisión humana explica cómo asignar personal a las colas de revisión y derivar los casos que requieren intervención.

Lista de comprobación para un agente de correo o CRM

Empieza por poner en marcha el flujo más acotado que resulte útil. Usa esta lista antes de habilitar acciones externas autónomas:

• Identidad: Cada lectura y modificación se limita al usuario autenticado y a la cuenta empresarial autorizada. El modelo no puede elegir una identidad con más privilegios.
• Datos: Recupera solo los registros y campos necesarios para la tarea. Mantén los secretos fuera del contenido visible para el modelo y conserva el origen del texto de correos, documentos y registros del CRM.
• Herramientas: Leer, redactar borradores, enviar, exportar y editar son permisos independientes. Elimina las capacidades que el flujo no necesite.
• Salida: Comprueba las respuestas y los argumentos de las herramientas antes de que salgan de la aplicación. Valida destinatarios, archivos adjuntos, destinos y cambios permitidos en los registros.
• Aprobación: Las acciones de alto impacto requieren revisar la acción exacta, y el código de la aplicación debe hacer cumplir ese requisito. Si falta la aprobación o cambia, la acción queda en espera.
• Operaciones: Mantén un registro de acciones que respete la privacidad, designa a una persona responsable de las alertas, ofrece un mecanismo de pausa y prueba el flujo completo antes de ampliar el acceso.

Para el asistente de ventas de un fundador, un alcance inicial razonable consiste en leer un hilo seleccionado de un cliente potencial y proponer un borrador. Una exportación masiva, un envío automático o una actualización de oportunidades en lote deben ser capacidades justificadas por separado. Define los permisos en función del trabajo que quieres ofrecer, no de todo lo que permita la integración.

La guía para limitar el alcance de los fallos en agentes de IA en producción desarrolla una arquitectura de contención más amplia. El alcance de un fallo indica hasta dónde puede propagarse por los sistemas conectados.

Pruebas de prompt injection: comprueba los efectos, no solo la respuesta

Una prueba se supera cuando el resultado prohibido no llega a producirse. Un asistente puede mostrar un mensaje de rechazo después de que una llamada a una herramienta ya haya modificado un registro. Inspecciona el servicio de herramientas y el estado resultante, no solo la transcripción del chat.

Usa contactos ficticios, buzones de prueba y un entorno controlado para ensayar el lanzamiento. Lo que sigue es un plan de pruebas de la aplicación, no una colección de instrucciones de ataque.

1. 1

   Comprueba primero el funcionamiento autorizado

   Ejecuta una tarea habitual de resumen de un cliente potencial. Confirma que se recuperan los registros correctos, que el borrador resulta útil y que se exige aprobación exactamente donde lo indique tu política. El trabajo legítimo debe seguir funcionando.

2. 2

   Pon a prueba ambas vías de entrada

   Incluye una solicitud no autorizada en el punto de entrada del usuario y un mensaje de un tercero que intente desviar la tarea. Comprueba que los registros ajenos a la tarea siguen siendo inaccesibles y que se deniegan las operaciones prohibidas de las herramientas.

3. 3

   Prueba la aprobación y la gestión de fallos

   Prueba qué ocurre si cambian los detalles de la acción después de aprobarla, si se rechaza una revisión, si el servicio de políticas no está disponible y si se reintenta una ejecución. Confirma que la aplicación mantiene la acción en espera o la rechaza y evita efectos duplicados.

4. 4

   Revisa las evidencias y las alertas

   Comprueba el estado final del CRM, los mensajes salientes, los destinos a los que se intentó acceder, el registro de aprobación y el registro de políticas. Confirma que quien opera el sistema puede identificar la fuente y detener el flujo sin depender de la explicación del modelo.

Repite las pruebas pertinentes cuando cambien los prompts, los modelos, la recuperación de información, las herramientas o los permisos. Un resultado corresponde a la configuración probada; no certifica todas las versiones futuras.

Registra lo suficiente para reconstruir la decisión sin convertir el historial de auditoría en otra copia de todo el buzón. Prioriza las referencias estables a registros, los detalles necesarios de cada acción, las versiones de las políticas y las evidencias con acceso controlado. Asigna a alguien la responsabilidad de investigar los destinos bloqueados, las exportaciones inesperadas y los fallos de aprobación repetidos.

¿Qué se exagera y qué sigue sin resolverse?

Ningún modelo, prompt, filtro o producto de protección debe considerarse una solución completa. OWASP señala expresamente que la generación aumentada por recuperación y el ajuste fino no mitigan por completo el prompt injection. La generación aumentada por recuperación, o RAG, proporciona documentos para ayudar al modelo a responder; no les da autoridad para cambiar la tarea.

Un prompt del sistema más sólido puede mejorar el comportamiento. No puede reducir los permisos de una credencial amplia. Un clasificador puede señalar contenido sospechoso. No puede decidir si un empleado concreto tiene permiso para divulgar un archivo adjunto determinado. Un segundo modelo que revise al primero añade una comprobación, pero sigue necesitando una política independiente de la aplicación.

Tampoco existe un porcentaje universal de detección que indique si tu agente de correo está listo. Los límites útiles dependen del flujo de trabajo: qué cuentas puede leer, qué campos puede modificar, adónde pueden ir los datos y qué acciones requieren revisión. Un resultado que un proveedor haya obtenido en otra tarea no demuestra que sea imposible eludir tu proceso de aprobación.

La afirmación que se puede sostener es más acotada y más útil: los controles por capas reducen la exposición y limitan las consecuencias, mientras que las pruebas y la supervisión permiten detectar fallos. Sigue existiendo un riesgo residual.

Actúa ahora si un agente ya lee contenido externo y puede divulgar información privada o modificar el estado del negocio. Espera antes de darle más autonomía hasta que se hagan cumplir los permisos, la aprobación y la gestión de fallos. Un resumidor de documentos públicos sin datos privados ni herramientas de acción tiene un alcance de consecuencias menor, pero también necesita protección frente a respuestas manipuladas.

Preguntas frecuentes

¿Cómo protegerse de los ataques de prompt injection?

Limita el acceso a datos y herramientas, separa el contenido no confiable de las instrucciones, valida las salidas y las acciones, exige revisión para las operaciones de alto impacto y supervisa los resultados. Haz cumplir los permisos fuera del modelo; ninguna capa por sí sola elimina el riesgo.

¿Cuál es un ejemplo de prompt?

«Resume el correo de este cliente potencial y redacta una respuesta para revisar» es un prompt habitual. El correo del cliente potencial es material para la tarea, no un permiso para cambiar la solicitud.

¿Se sigue usando la inyección SQL?

Sí. La inyección SQL sigue siendo relevante para las aplicaciones que construyen consultas inseguras a bases de datos. Requiere defensas específicas para bases de datos, además de los controles contra la inyección de prompts; consulta la guía de OWASP para prevenir inyecciones.

¿Qué es una inyección en programación?

En seguridad, una inyección ocurre cuando una entrada no confiable cambia lo que ejecuta o procesa un intérprete. La inyección de prompts ataca el comportamiento de un modelo; otras vulnerabilidades de inyección afectan a consultas de bases de datos, comandos o código del navegador.

¿Cómo se explica una inyección en palabras sencillas?

Es una entrada que cruza un límite y pasa a tratarse como una instrucción que nunca estuvo autorizada a dar.

¿Qué tipos de inyección de código existen?

Algunos ejemplos son la inyección SQL, la inyección de comandos del sistema operativo y la inyección de scripts. Las defensas dependen del intérprete afectado. La inyección de prompts comparte el problema de los límites de confianza, pero no es sinónimo de toda inyección de código.

¿Qué tipos de inyección de prompts existen?

La distinción principal según la vía de entrada es entre directa e indirecta: el ataque llega por la entrada del usuario o por contenido que recupera la aplicación. El texto en imágenes y otros medios también puede transmitir instrucciones; la vía de entrada y el formato del contenido son dimensiones distintas.

¿Cuáles son los 7 tipos principales de hackers?

Las etiquetas para clasificar hackers no constituyen una política de permisos útil para un agente. Basa los controles en quién está autenticado, quién puede influir en el contenido y a qué puede acceder la aplicación o qué puede modificar.

¿Qué son DDoS y la inyección SQL?

DDoS significa denegación de servicio distribuida: un ataque contra la disponibilidad que utiliza fuentes distribuidas. La inyección SQL manipula consultas a bases de datos. Son problemas distintos del prompt injection; la guía de OWASP sobre denegación de servicio aborda las defensas de disponibilidad.

Qué hacer el lunes

Elige un flujo de correo o CRM que ya esté en uso y enumera los datos, las herramientas y los destinos externos a los que tiene acceso. Elimina los accesos innecesarios, haz que las acciones con consecuencias esperen la aprobación de la acción exacta y demuestra que una propuesta rechazada no produce ningún efecto externo. Amplía la autonomía solo cuando funcionen tanto la tarea útil como las rutas de denegación.

Recibe guías prácticas para crear flujos de trabajo con IA en la boletín.