Seguridad de agentes de IA: inyección de prompt y salvaguardas

La seguridad de un agente de IA parte de una idea sencilla: asumir que el agente puede ser engañado y limitar lo que es capaz de hacer cuando eso ocurre. Ninguna protección detiene por sí sola la inyección de prompt, pero una defensa por capas (permisos mínimos, aislamiento, salvaguardas, aprobación humana y pruebas periódicas) reduce mucho los daños posibles.

Por qué un agente está más expuesto que un chatbot

Un chatbot responde con texto. Si alguien lo empuja a decir una barbaridad, el daño suele limitarse a una respuesta errónea o fuera de lugar. Un agente, en cambio, actúa. Lee su correo, consulta páginas web, abre archivos y usa herramientas mediante la llamada a herramientas, es decir, activando funciones concretas: enviar un mensaje, escribir en una base de datos, hacer un pedido.

Tres ingredientes vuelven delicada la situación cuando coinciden:

1. El acceso a datos privados: bandeja de entrada, documentos internos, base de clientes.
2. La exposición a contenidos no fiables: páginas web, adjuntos, tickets de soporte, reseñas, cualquier cosa que un desconocido pueda escribir.
3. La capacidad de actuar o comunicarse hacia fuera: enviar un mensaje, llamar a un servicio, publicar.

Un agente que reúne los tres puede, si lo manipulan, filtrar información o desencadenar una acción que nadie quería. Si está empezando a construir agentes, nuestra guía completa para crear un agente de IA explica primero lo básico. Este artículo se centra en la protección.

La inyección de prompt, explicada con sencillez

La inyección de prompt consiste en colar instrucciones en un texto que la IA va a leer, para que las siga en lugar de las previstas. Funciona porque un modelo de lenguaje lo recibe todo como texto. Las instrucciones del desarrollador, la petición del usuario y los contenidos consultados llegan por el mismo canal, sin una frontera estanca entre «órdenes» y «datos».

Se distinguen dos familias:

• La inyección directa procede de la persona que escribe al agente e intenta que ignore sus reglas.
• La inyección indirecta está oculta en un contenido externo que el agente procesa: una página, un PDF, un correo. Es la más preocupante, porque el usuario legítimo a menudo no la ve y la activa sin saberlo.

No vamos a detallar cómo se construyen estos ataques. Lo que le importa a usted es diseñar el agente para que una instrucción maliciosa, aunque la siga, no pueda causar mucho daño.

Las capas de defensa que conviene implantar

Ninguna de estas medidas basta por sí sola. Su fuerza está en apilarlas: si una capa falla, la siguiente limita las consecuencias.

1. Conceder los mínimos permisos posibles

Es el principio de mínimo privilegio. Cada herramienta que entregue al agente debe tener el ámbito más estrecho posible: solo lectura cuando leer es suficiente, una carpeta en lugar de todo el disco, un buzón de pruebas en lugar del correo principal. Cree credenciales exclusivas para el agente, revocables y con caducidad, y no use nunca las suyas. Las claves de acceso se guardan en el servidor, nunca en el texto que lee el modelo.

OWASP aconseja además resolver las funciones sensibles en el código y no en el prompt. Por ejemplo, en lugar de decirle al agente «no devuelvas nunca más de 50 euros», haga que la propia herramienta de reembolso rechace cualquier importe superior. Si expone sus herramientas mediante MCP, cada herramienta es una puerta: nuestro tutorial para crear un servidor MCP muestra cómo acotarlas bien.

2. Aislar al agente en un entorno cerrado

El entorno aislado (sandbox) hace que el agente trabaje en un espacio cerrado. Hay dos barreras esenciales: el aislamiento del sistema de archivos (el agente solo ve una carpeta de trabajo) y el aislamiento de la red (solo puede contactar direcciones aprobadas). En un artículo de octubre de 2025 sobre el aislamiento de su herramienta Claude Code, Anthropic insiste en que ambas son necesarias: un agente que puede leer datos sensibles y contactar cualquier servidor puede sacarlos al exterior.

Para los agentes que manejan un navegador o un ordenador, una máquina virtual dedicada que se reinicia tras cada tarea es una buena práctica.

3. Separar y señalar los contenidos externos

Todo lo que viene de fuera debe identificarse como tal y tratarse como un dato, no como una orden. Una arquitectura prudente separa funciones: un componente lee los contenidos no fiables pero no tiene acceso a ninguna herramienta sensible; otro actúa, pero solo recibe un resumen estructurado del primero. Unas instrucciones claras en el prompt de sistema ayudan al agente a mantenerse en su papel, pero no garantizan nada frente a un texto malicioso bien diseñado.

4. Filtrar entradas y salidas

Las salvaguardas (guardrails) son controles colocados alrededor del modelo. En la entrada detectan peticiones fuera de lugar o datos sensibles. En la salida revisan la respuesta o la acción antes de que se ejecute. Imponer un formato de salida preciso facilita mucho la tarea: si el agente debe devolver un importe y una referencia de pedido, su código puede comprobar con certeza que el importe está dentro de un rango y que la referencia existe. Entre los proyectos conocidos figuran NeMo Guardrails, un conjunto de herramientas de código abierto de NVIDIA, y Llama Guard, un modelo de clasificación de riesgos publicado por Meta.

5. Mantener a una persona en las acciones irreversibles

El humano en el circuito significa que una persona valida ciertas acciones antes de ejecutarlas: pagos, envíos al exterior, borrados, cambios de permisos. Muestre a esa persona la acción exacta con sus parámetros, no un resumen redactado por el agente. Cuidado con el cansancio: si todo exige un clic, se acaba aprobando sin leer. Reserve la confirmación para lo importante y deje el resto dentro del entorno aislado.

6. Registrarlo todo y poder pararlo todo

Guarde cada llamada a herramientas, sus parámetros y el origen de los contenidos leídos. Estos registros sirven para detectar comportamientos anómalos, como un volumen de envíos inusual o una dirección desconocida, y para entender un incidente después. Prevea una parada de emergencia: apagar el agente y revocar sus accesos debe llevar segundos, no una reunión.

7. Probar como un adversario, con regularidad

El red teaming consiste en que un equipo o una herramienta intente desviar al agente en un entorno de pruebas, para encontrar los fallos antes que nadie. Añada escenarios de seguridad a sus baterías de pruebas, junto a las pruebas de calidad descritas en nuestra guía para evaluar un agente de IA. Repítalas tras cada cambio de modelo, de herramienta o de instrucciones: un agente seguro ayer puede no serlo mañana.

Las siete capas de un vistazo

Capa	Qué limita	Ejemplo concreto
Mínimo privilegio	El alcance de los daños	Acceso de solo lectura a una carpeta
Entorno aislado	Fugas y efectos fuera de ámbito	Red limitada a una lista de direcciones
Separación de contenidos	La influencia de textos no fiables	El lector de páginas no puede enviar nada
Salvaguardas	Peticiones y respuestas fuera de lugar	Control automático del importe devuelto
Humano en el circuito	Las acciones irreversibles	Confirmación antes de cualquier pago
Registro	Incidentes que nadie ve	Alerta ante una dirección de destino desconocida
Pruebas adversarias	Fallos aún no descubiertos	Campaña de pruebas tras cada actualización

Qué ofrecen los fabricantes y los frameworks

Las empresas que crean productos con agentes explican cada vez más sus protecciones. Perplexity, por ejemplo, describe para su navegador Comet una defensa por capas contra la inyección de prompt, con clasificadores, solicitudes de confirmación y una auditoría externa. Estas medidas reducen el riesgo, no lo eliminan, y ningún fabricante promete una protección total.

En el desarrollo, los frameworks de agentes suelen incluir piezas útiles: pasos de aprobación humana, trazabilidad de llamadas, integración de salvaguardas. Pero no toman las decisiones de diseño por usted. Nuestra comparativa de frameworks de agentes de IA le ayuda a elegir herramienta, y nuestra herramienta ¿Puedo confiarle esto a un agente? le ayuda a valorar el riesgo de una tarea antes de automatizarla.

Lista de control antes de la puesta en producción

• ¿Tiene el agente solo los permisos que necesita, con credenciales propias y revocables?
• ¿Funciona en un entorno aislado, red incluida?
• ¿Están los contenidos externos separados de las instrucciones y de las herramientas sensibles?
• ¿Se comprueban las salidas con código antes de ejecutarlas?
• ¿Exigen las acciones irreversibles una confirmación humana clara?
• ¿Queda registrada cada acción, con una parada de emergencia preparada?
• ¿Ha realizado pruebas adversarias y ha previsto repetirlas en cada actualización?

Póngase a prueba Su agente de soporte lee los tickets de los clientes y puede hacer reembolsos. ¿Qué medida reduce más el riesgo?

Poner un tope a los reembolsos dentro de la propia herramienta y exigir aprobación humana por encima de un umbral. Los tickets son contenidos no fiables: cualquiera puede escribir en ellos. Una instrucción como «no reembolses nunca sin motivo» puede saltarse, mientras que un límite programado en la herramienta se aplica decida lo que decida el modelo.