Seguridad y gobierno práctico de la IA — Artículo 4 de 5
Cuando un documento intenta dar órdenes: protección en capas para agentes de IA
La inyección indirecta de instrucciones llega dentro del contenido que un agente está procesando. El objetivo es que el contenido no confiable nunca adquiera autoridad operativa.
Un empleado le pide a un asistente de IA que resuma una propuesta de un proveedor. Dentro del documento, un atacante colocó instrucciones que le dicen al asistente que obtenga los precios internos y los envíe a un destino externo.
El empleado pidió un resumen. El documento intenta crear una tarea nueva.
Este es un ejemplo hipotético de inyección indirecta de instrucciones: las instrucciones llegan a través del contenido que el sistema de IA está procesando y no a través de la solicitud del usuario autorizado. OWASP identifica este riesgo y recomienda combinar controles como restricciones de privilegios, validación de salidas, filtrado y supervisión. Ningún filtro por sí solo debería tratarse como una solución completa. OWASP: Prompt Injection
El objetivo práctico es impedir que el contenido no confiable adquiera autoridad operativa. Marcar un documento como no confiable puede ayudar al modelo a interpretarlo, pero una instrucción del tipo "ignora el contenido malicioso" no reemplaza el control sobre lo que la aplicación puede ejecutar.
En el flujo del proveedor, haría posible el resumen sin darle al asistente acceso a los precios internos ni a una herramienta de envío externo. Así, un proceso de resumen comprometido tendría menos formas de causar daño. Si otro flujo necesita esas capacidades, dale permisos separados y condiciones de aprobación explícitas.
La protección en ejecución debe seguir el camino real de los datos y las acciones. Inspecciona el material entrante antes de que llegue al contexto del modelo cuando ese límite necesite protección. Valida una llamada a herramientas propuesta antes de ejecutarla. Revisa los datos que devuelven las herramientas antes de pasarlos al modelo cuando la aplicación requiera esa salvaguarda. Revisa el contenido saliente antes de entregarlo a su destino.
La ubicación determina lo que un control puede lograr. Una inspección hecha después de que el modelo recibió información sensible no puede deshacer esa exposición. Un gateway no puede inspeccionar una conexión directa que lo esquiva. Dibuja las rutas, incluidas las herramientas locales, los trabajos en segundo plano y las APIs externas, antes de afirmar que tienes cobertura.
Piensa en una operación autorizada que crea el registro de un proveedor. La aplicación debería validar los tipos de campo, los valores permitidos, la pertenencia al tenant y la autoridad de quien llama. En un mensaje externo, inspecciona el destinatario real y los adjuntos elegidos. Estas verificaciones limitan la ejecución aun cuando la acción propuesta suene razonable en lenguaje natural.
La inspección de contenido suma otra fuente de evidencia. Puede identificar sospechas de inyección, información sensible o violaciones de políticas, pero hay que evaluarla tanto por las amenazas que se le escapan como por los bloqueos innecesarios. Decide cómo se comporta el flujo si el servicio de inspección no está disponible. Ante una acción con consecuencias, puede ser preferible pausar para revisión que seguir sin el control necesario.
La aprobación humana debe quedar atada a una acción concreta. Muestra el destinatario, el contenido, los datos involucrados y el efecto esperado. Si esos detalles cambian después de la aprobación, exige una nueva decisión cuando el cambio afecta el riesgo. Una aprobación vaga para "continuar" protege poco frente a una operación sustancialmente distinta.
Cisco posiciona AI Defense como un componente de protección en ejecución; DefenseClaw se describe como una capa de aplicación de políticas y de evidencia, con integraciones de escaneo e inspección. Estas herramientas necesitan una cobertura y una validación de políticas propias de cada despliegue. Su presencia no garantiza que se bloquee cualquier ataque. Arquitectura de Cisco, DefenseClaw
Una prueba útil es colocar una instrucción maliciosa simulada e inofensiva en un documento de prueba y observar el flujo completo. El éxito significa que la tarea prevista sigue siendo útil mientras el acceso o la ejecución no autorizados se impiden y quedan registrados.
El límite que importa es el punto en que la sugerencia de un modelo se convierte en una acción en el mundo real.