Cómo Proteger la IA Agéntica: 5 Prácticas Que Todo Equipo de Seguridad Debe Adoptar Ahora
La semana pasada analizamos por qué la inyección de instrucciones indirecta (indirect prompt injection) se ha convertido en uno de los riesgos más urgentes para los equipos de seguridad en 2026, catalogado como el riesgo número uno según OWASP para aplicaciones de LLM e inteligencia artificial generativa, y ya vinculado a incidentes confirmados de exfiltración de datos, pagos no autorizados e incluso ejecución remota de código. La siguiente pregunta natural es qué hacer al respecto.
La buena noticia es que este no es un problema imposible de resolver. Es un problema nuevo y requiere una mentalidad distinta a la seguridad de aplicaciones tradicional, pero existe un cuerpo creciente de recomendaciones concretas, de organizaciones como OWASP y OpenAI, sobre cómo construir y operar agentes de IA que resistan un ataque. Aquí presentamos cinco prácticas que vale la pena implementar ahora.
1. Delimite el radio de impacto de cada agente antes de ponerlo en producción
El investigador Simon Willison describió un patrón que llama la «trifecta letal», y es un marco útil para cualquier equipo de seguridad que evalúe agentes de IA. Un agente se vuelve verdaderamente peligroso cuando combina tres elementos a la vez: acceso a datos privados, exposición a contenido externo no confiable, como correos electrónicos o páginas web, y la capacidad de comunicarse hacia afuera, ya sea enviando datos, llamando a una API o renderizando un enlace. Cualquiera de estos elementos por sí solo es manejable. Los tres juntos significan que un atacante capaz de insertar instrucciones en el contenido que su agente lee podría llevarse todo lo que ese agente puede ver.
Antes de poner cualquier agente en producción, hágase una pregunta simple: ¿tiene estas tres capacidades a la vez? Si es así, trátelo como un sistema de alto riesgo que necesita los controles descritos a continuación, no como una aplicación estándar que recibe una revisión de rutina y sigue su curso.
2. Aplique el principio de mínimo privilegio a lo que los agentes realmente pueden hacer
Otorgue a los agentes credenciales acotadas en lugar de acceso amplio a los sistemas con los que interactúan, y establezca límites reales para acciones de alto impacto como pagos, eliminaciones y ejecución de código. Piénselo igual que pensaría en un nuevo empleado. Un representante de atención al cliente humano suele tener un límite para reembolsos y necesita autorización para montos mayores. Sus agentes de IA merecen la misma disciplina. Si un agente no necesita la capacidad de eliminar registros o mover dinero, no debería tenerla, sin excepciones.
3. Mantenga el contenido no confiable fuera del canal de instrucciones
Una parte importante de los ataques de inyección de instrucciones que ocurren en el mundo real funciona porque no existe un límite claro entre lo que se le indicó al sistema que hiciera y lo que este termina leyendo mientras lo hace. Diseñe sus prompts de manera que el contenido externo (páginas web, documentos, correos electrónicos, registros de actividad) quede claramente separado de las instrucciones a nivel de sistema, y añada filtrado de entrada y salida como una capa adicional, no como la única defensa. El filtrado detecta patrones conocidos. La separación estructural es lo que lo protege frente a los que todavía nadie ha visto.
4. Exija aprobación humana para acciones privilegiadas o irreversibles
Cualquier acción con consecuencias financieras, operativas o de pérdida de datos reales debe contar con la intervención de una persona antes de ejecutarse. No se trata de frenar a sus equipos en todos los frentes. Se trata de ser deliberado respecto a qué acciones pueden ejecutarse de forma autónoma y cuáles merecen una segunda revisión, la misma distinción que ya aplicaría a una solicitud de transferencia bancaria o a un cambio en una base de datos de producción.
5. Realice pruebas de forma continua y trate al modelo como un usuario no confiable
Esta es la práctica que la mayoría de las organizaciones todavía no implementa, y es la que más importa. El escaneo de vulnerabilidades estándar y la revisión de código no detectarán la inyección de instrucciones, porque la falla reside en cómo el sistema procesa el contenido, no en una pieza de código con una firma conocida. Esto explica precisamente por qué la inyección de instrucciones puede ocupar el primer lugar entre las preocupaciones de los expertos en seguridad mientras aparece con mucha menos frecuencia en los registros tradicionales de incidentes y vulnerabilidades: las herramientas que la mayoría de los programas ya utilizan nunca fueron diseñadas para detectarla.
La única forma confiable de saber si sus agentes realmente resisten es probarlos como lo haría un atacante, tratando al propio modelo como una parte no confiable y examinando las integraciones de herramientas, los permisos y el acceso a datos detrás de él, no solo las respuestas del modelo de forma aislada. Aquí es exactamente donde las pruebas de penetración especializadas en IA y LLM demuestran su valor. Las pruebas de seguridad de IA generativa y LLM de Orenda están diseñadas específicamente para este modelo de amenazas, evaluando cómo se comporta un agente al encontrarse con contenido manipulado y dónde podrían explotarse sus permisos e integraciones de herramientas. Combinadas con ejercicios de red team y gestión continua de vulnerabilidades, le ofrecen una respuesta real, basada en evidencia y no en suposiciones, a la pregunta que todo CISO que despliega agentes de IA debería hacerse: si alguien intentara esto contra nosotros hoy, ¿funcionaría?
En resumen
Ninguna de estas cinco prácticas requiere frenar sus iniciativas de IA. Requieren que las construya con la misma disciplina que ya aplica a sus redes, aplicaciones y entornos de nube: saber qué está exponiendo, limitar lo que puede salir mal y probarlo con regularidad frente a técnicas de ataque reales, en lugar de asumir que todo está bien porque nada se ha roto todavía.
