AI Security: cómo proteger agentes y aplicaciones de IA

La adopción de Inteligencia Artificial en entornos empresariales está cambiando la superficie de ataque de las aplicaciones. Un modelo que únicamente genera texto presenta un nivel de exposición diferente al de un agente capaz de consultar documentos internos, acceder a un CRM, utilizar APIs o ejecutar acciones sobre otros sistemas.

Esta evolución hace que AI Security tenga que abordar riesgos que no aparecen de la misma forma en una aplicación tradicional. Un agente puede recibir instrucciones desde el usuario, pero también interpretar información procedente de páginas web, emails, documentos, bases de conocimiento y otras fuentes externas. Al mismo tiempo, puede disponer de herramientas y permisos que convierten una respuesta incorrecta en una acción con consecuencias reales.

Esta exposición aumenta todavía más en arquitecturas de Multi-Agent Systems, donde diferentes agentes pueden operar con herramientas, permisos y responsabilidades distintas.

Proteger estos sistemas exige analizar conjuntamente el modelo, los datos a los que puede acceder, las herramientas disponibles, la identidad utilizada para operar y las acciones que está autorizado a ejecutar. La seguridad deja de concentrarse únicamente en lo que la IA puede generar y empieza a depender también de lo que puede hacer.

Qué es AI Security y qué cambia cuando la IA llega a producción

AI Security comprende los controles utilizados para proteger modelos, aplicaciones y agentes de Inteligencia Artificial frente a manipulación, acceso indebido a información, abuso de herramientas y acciones no autorizadas.

Muchos de estos sistemas siguen dependiendo de principios tradicionales de ciberseguridad. La autenticación, autorización, protección de datos, gestión de identidades, segmentación, logging y monitorización continúan siendo necesarios. Lo que cambia es la forma en que el modelo interactúa con estos controles.

Un agente de IA puede decidir dinámicamente qué herramienta utilizar durante un workflow. También puede combinar información obtenida de diferentes fuentes y utilizar el resultado de una acción para decidir la siguiente.

OpenAI diferencia precisamente los agentes de aplicaciones más simples basadas en LLM por su capacidad para gestionar la ejecución de workflows y utilizar herramientas para obtener información o realizar acciones sobre sistemas externos. Esta autonomía introduce capacidades útiles, pero también aumenta la importancia de definir límites claros para su comportamiento.

La superficie de riesgo puede crecer a medida que el sistema incorpora nuevas capacidades. Un chatbot sin acceso a sistemas internos tiene un alcance limitado. Si ese mismo sistema puede consultar información confidencial, enviar mensajes, modificar registros o ejecutar operaciones mediante APIs, una manipulación del modelo puede tener consecuencias más amplias.

Prompt injection y manipulación de agentes de IA

El prompt injection intenta modificar el comportamiento de una aplicación de IA mediante instrucciones que entran en conflicto con el objetivo original del usuario o con las reglas establecidas para el sistema.

El riesgo resulta especialmente relevante en agentes porque las instrucciones potencialmente maliciosas no tienen que proceder necesariamente del usuario.

Un agente que investiga información en Internet puede encontrar instrucciones dentro de una página. Otro que procesa documentos corporativos puede recibirlas desde un archivo. Un sistema conectado al correo electrónico puede interpretar contenido incluido en un mensaje.

OpenAI señala que los agentes capaces de navegar, recuperar información y ejecutar acciones introducen nuevas oportunidades para este tipo de manipulación. Las variantes más sofisticadas pueden parecerse a técnicas de ingeniería social: el contenido intenta convencer al modelo de que determinada instrucción es legítima dentro del contexto de la tarea.

Direct prompt injection en aplicaciones de IA

En un direct prompt injection, la manipulación procede directamente de la interacción del usuario con la aplicación.

El atacante puede intentar que el modelo ignore determinadas restricciones, revele información que debería permanecer protegida o utilice sus capacidades fuera del propósito definido para el sistema.

En una aplicación que únicamente genera contenido, el impacto puede concentrarse en la respuesta producida. Cuando el mismo modelo controla un agente con herramientas, la situación cambia porque la instrucción puede intentar influir sobre decisiones posteriores del workflow.

Por este motivo, la protección no puede depender exclusivamente de que el modelo reconozca una instrucción maliciosa. También debe limitar qué consecuencias podría tener una manipulación que consiga influir sobre su comportamiento.

Indirect prompt injection en agentes conectados a datos externos

El indirect prompt injection introduce un problema diferente. La instrucción maliciosa puede encontrarse dentro del contenido que el agente consulta para realizar una tarea legítima.

Imaginemos un agente encargado de analizar documentos y preparar un informe. Uno de esos archivos podría contener texto diseñado para modificar su comportamiento. Algo similar puede ocurrir con páginas web, emails o información obtenida desde otras aplicaciones.

El usuario no necesita haber proporcionado directamente la instrucción problemática. El propio workflow lleva al agente hasta ella.

Esto convierte la procedencia de la información en una dimensión importante de AI Security. Los datos recuperados desde una fuente externa pueden ser necesarios para completar una tarea, pero no deberían adquirir automáticamente la misma autoridad que las instrucciones que definen el comportamiento del agente.

OpenAI recomienda limitar el acceso de los agentes a la información necesaria para completar cada tarea y revisar cuidadosamente las acciones importantes antes de confirmarlas. Estas medidas reducen el impacto potencial cuando un agente encuentra contenido manipulado durante su ejecución.

Data leakage y exposición de información en sistemas de IA

La exposición de datos no depende únicamente de que un modelo reproduzca información confidencial en una respuesta.

Un agente puede recuperar información desde diferentes sistemas, incorporarla a su contexto y posteriormente utilizar una herramienta para transmitirla a otro destino. La combinación de acceso a datos + capacidad de acción modifica el alcance potencial de una filtración.

Por ejemplo, un agente podría necesitar consultar información de clientes para completar un proceso interno. Ese acceso no significa que deba poder transmitir todos esos datos mediante cualquier herramienta disponible.

La arquitectura debe determinar qué información puede consultar cada agente, durante cuánto tiempo puede utilizarla y qué operaciones puede realizar con ella.

También resulta relevante controlar la información que se incorpora a memoria, logs o sistemas de observabilidad. Un mecanismo diseñado para mejorar la trazabilidad puede convertirse en otra superficie de exposición si almacena información sensible sin los controles adecuados.

Microsoft incluye los datos introducidos en la memoria de los agentes y la información transferida a herramientas entre las responsabilidades que deben protegerse durante el despliegue de sistemas agentic.

La protección de datos en AI Security requiere, por tanto, establecer límites alrededor de todo el recorrido de la información: origen, recuperación, contexto, memoria, herramienta y destino.

Tool access y permisos de agentes de IA

Las herramientas son uno de los elementos que convierten un modelo en un sistema capaz de actuar.

OpenAI clasifica las tools de los agentes en capacidades relacionadas con datos, acciones y orquestación. Algunas permiten consultar información; otras pueden modificar registros, enviar comunicaciones o ejecutar operaciones sobre sistemas externos.

Desde una perspectiva de seguridad, estas capacidades no deberían tratarse de la misma forma.

Un agente que puede consultar el estado de una orden presenta un riesgo diferente al de otro que puede cancelarla. Leer un registro no equivale a modificarlo. Preparar un email no tiene las mismas consecuencias que enviarlo automáticamente.

La seguridad de las herramientas debe considerar tanto la función disponible como los permisos con los que se ejecuta.

Least privilege aplicado a AI Agents

El principio de least privilege establece que cada agente debe disponer únicamente de los permisos necesarios para cumplir su función.

Microsoft plantea este principio como un requisito de diseño para sistemas agentic: identidad, scope, acceso a herramientas y auditabilidad deberían definirse antes de ampliar la autonomía del agente. También recomienda utilizar identidades específicas y evitar credenciales compartidas que dificulten atribuir posteriormente una acción.

Aplicado a un AI Agent, esto significa controlar cuatro dimensiones relacionadas: qué datos puede consultar → qué herramientas puede utilizar → qué acciones puede ejecutar → sobre qué recursos puede hacerlo.

Un agente encargado de consultar información no debería recibir permisos de escritura simplemente porque la integración utilizada también ofrece esa capacidad. Del mismo modo, una herramienta incorporada durante una prueba debería eliminarse cuando deja de ser necesaria.

El objetivo es reducir el impacto potencial de un comportamiento incorrecto o de una manipulación. Si el agente no dispone de una capacidad determinada, una instrucción maliciosa tampoco puede utilizarla directamente.

Acciones reversibles e irreversibles de los agentes

No todas las herramientas requieren el mismo nivel de control.

Una consulta puede repetirse o descartarse sin modificar el estado de un sistema. En cambio, eliminar información, realizar un pago, cambiar permisos, desplegar software o enviar datos a un tercero puede producir consecuencias difíciles de revertir.

OpenAI propone evaluar las herramientas considerando factores como acceso read-only frente a write, reversibilidad, permisos requeridos e impacto financiero. Las acciones de mayor riesgo pueden utilizar controles adicionales o escalarse a una persona antes de ejecutarse.

Esta clasificación permite adaptar los controles al impacto potencial.

Un agente puede ejecutar automáticamente operaciones de bajo riesgo mientras mantiene un punto de aprobación para aquellas que modifican información sensible, afectan a sistemas productivos o producen consecuencias económicas.

Rogue actions y excessive agency en agentes de IA

Un agente no necesita estar completamente comprometido para ejecutar una acción problemática.

Puede interpretar incorrectamente una instrucción, recibir información manipulada o seleccionar una herramienta inadecuada. El impacto depende en gran medida de las capacidades que tenga disponibles.

OWASP utiliza el concepto Excessive Agency para describir situaciones en las que un sistema basado en LLM puede realizar acciones dañinas como consecuencia de outputs inesperados, ambiguos o manipulados. La organización identifica tres causas principales: funcionalidad excesiva, permisos excesivos y autonomía excesiva.

La diferencia entre estas dimensiones resulta importante.

Un agente presenta excessive functionality cuando dispone de herramientas o funciones que no necesita para realizar su trabajo.

Existe excessive permissions cuando las herramientas necesarias operan con privilegios superiores a los requeridos.

La excessive autonomy aparece cuando el agente puede ejecutar operaciones de alto impacto sin controles adicionales o aprobación.

Estas condiciones pueden combinarse. Un agente manipulado mediante prompt injection representa un problema mayor si además dispone de una herramienta innecesaria, credenciales con permisos amplios y autonomía para utilizarla sin confirmación.

La superficie de riesgo puede analizarse a través de las diferentes capas que intervienen en el sistema:

La matriz muestra una característica importante de AI Security: ningún control aislado cubre toda la superficie. La protección necesita combinar controles sobre instrucciones, datos, identidad, herramientas, acciones y comportamiento durante la ejecución.

Cómo proteger agentes y aplicaciones con una estrategia de AI Security

Una arquitectura defensiva debe asumir que un modelo puede encontrarse con instrucciones ambiguas o maliciosas y que algún mecanismo preventivo puede fallar.

Una arquitectura defensiva debe limitar tanto la exposición a contenido problemático como las consecuencias que puede producir si ese contenido influye sobre una decisión del agente.

Esto favorece una estrategia de defensa por capas donde identidad, autorización, guardrails, supervisión humana y observabilidad reducen diferentes partes del riesgo.

Identidad, permisos y aislamiento de agentes

Cada agente debería disponer de una identidad atribuible y de un conjunto definido de responsabilidades.

Microsoft recomienda utilizar identidades específicas para los agentes, documentar qué datos y herramientas pueden utilizar y revisar sus permisos cuando cambian los workflows, las integraciones o el entorno de despliegue.

Esta separación mejora tanto la prevención como la investigación.

Si varios agentes utilizan credenciales compartidas, resulta más difícil determinar qué componente ejecutó una acción. Una identidad propia permite asociar actividad, permisos y recursos con un agente concreto.

La autorización también debería aplicarse en el momento de utilizar una herramienta. Que un agente tenga acceso a una integración no implica que todas las operaciones disponibles deban quedar autorizadas.

Microsoft recomienda tratar las invocaciones de herramientas como decisiones independientes de confianza y aplicar controles más estrictos cuando una operación sea irreversible, tenga un impacto elevado o atraviese una frontera de seguridad.

Guardrails y validación de inputs y outputs

Los guardrails permiten establecer límites adicionales alrededor del comportamiento de una aplicación de IA.

Pueden detectar inputs potencialmente problemáticos, restringir temas fuera del alcance del sistema, filtrar información sensible, validar outputs o introducir comprobaciones antes de utilizar determinadas herramientas.

Su función es importante, pero no deberían convertirse en el único mecanismo defensivo.

OpenAI recomienda combinar guardrails con autenticación, autorización, controles estrictos de acceso y medidas convencionales de seguridad de software. También plantea la utilización de varias defensas especializadas en lugar de depender de un único filtro.

Esto resulta especialmente relevante frente al prompt injection. Detectar una instrucción maliciosa es útil, pero limitar los permisos y herramientas del agente reduce las consecuencias incluso cuando la detección no funciona como se esperaba.

Human oversight para acciones de alto riesgo

La supervisión humana no tiene que introducirse en cada paso de un workflow.

Su valor aumenta cuando se coloca en puntos donde una decisión puede generar consecuencias importantes.

Operaciones económicas, eliminación de información, cambios de permisos, comunicaciones sensibles o acciones difíciles de revertir pueden requerir confirmación antes de ejecutarse.

OpenAI identifica las acciones sensibles, irreversibles o de alto impacto como uno de los principales escenarios en los que conviene transferir el control a una persona.

Microsoft aplica un criterio similar al recomendar autorización específica y nuevas aprobaciones para acciones irreversibles o de alto impacto.

El resultado es una autonomía graduada. El agente puede resolver automáticamente operaciones de menor riesgo y solicitar intervención cuando el impacto potencial supera los límites definidos por la organización.

Logging y observabilidad de acciones de agentes

Registrar únicamente la conversación con el modelo proporciona una visión incompleta de lo ocurrido.

Una investigación necesita reconstruir qué identidad actuó, qué permisos tenía, qué herramienta utilizó, qué operación solicitó y sobre qué recurso se ejecutó.

Microsoft recomienda registrar elementos como identidad del agente, rol, scope efectivo, acción, recurso y datos de correlación que permitan seguir el workflow de extremo a extremo.

Esta trazabilidad adquiere mayor importancia en arquitecturas donde un agente utiliza varias herramientas o donde múltiples agentes participan en el mismo proceso.

La observabilidad debe permitir pasar de una respuesta final a la secuencia que la produjo.

AI Security en producción: qué debe monitorizar una empresa

Los controles definidos durante el desarrollo pueden perder efectividad si el sistema cambia después del despliegue.

Un agente puede incorporar nuevas herramientas, acceder a fuentes de datos adicionales o asumir responsabilidades que no existían en su versión inicial. Cada cambio puede modificar su superficie de riesgo.

La monitorización debe observar tanto incidentes evidentes como cambios en las capacidades del sistema.

Un aumento inesperado de llamadas a una herramienta, intentos repetidos de acceder a recursos fuera del scope, escalaciones frecuentes hacia acciones privilegiadas o secuencias de ejecución inusuales pueden indicar problemas que no aparecen al analizar únicamente la respuesta del modelo.

También debe existir un inventario actualizado de agentes y responsables. Microsoft recomienda registrar los agentes para conocer qué sistemas existen, quién es responsable de ellos y qué recursos pueden alcanzar. Los agentes no gestionados quedan fuera de procesos normales de revisión, monitoring y revocación.

La respuesta ante incidentes debe contemplar además mecanismos para reducir rápidamente las capacidades de un agente. Revocar credenciales, invalidar tokens, deshabilitar identidades o retirar permisos puede ser necesario cuando se detecta un comportamiento anómalo.

AI Security en producción requiere, por tanto, mantener una relación continua entre comportamiento observado y permisos efectivos.

Qué perfiles intervienen en la seguridad de sistemas de IA

La protección de sistemas de IA conecta decisiones técnicas con políticas de riesgo y procesos operativos de seguridad.

Un AI Governance Specialist puede participar en la definición de políticas, responsabilidades, controles y criterios de aprobación aplicables a los sistemas de Inteligencia Artificial. Su trabajo ayuda a establecer qué niveles de autonomía son aceptables, qué acciones requieren supervisión y cómo se documentan los riesgos asociados a cada aplicación.

La gobernanza también debe acompañar la evolución del sistema. Incorporar una nueva fuente de datos, una herramienta adicional o mayores permisos puede cambiar el perfil de riesgo aunque el modelo utilizado siga siendo el mismo.

El SOC Analyst interviene desde la perspectiva operativa. La actividad generada por agentes, identidades, tools y sistemas conectados puede incorporarse a procesos de monitorización, detección e investigación para identificar comportamientos anómalos y responder ante incidentes.

Esta relación conecta dos niveles diferentes de AI Security.

La gobernanza establece qué debería estar permitido y bajo qué condiciones. Las operaciones de seguridad ayudan a comprobar qué está ocurriendo realmente en producción y a responder cuando el comportamiento observado se aparta de esos límites.

AI Security debe controlar lo que la IA puede hacer, no solo lo que puede generar

La superficie de riesgo de una aplicación de IA cambia cuando el modelo adquiere capacidad para interactuar con otros sistemas.

Un LLM puede generar una respuesta. Una aplicación conectada puede recuperar información. Un agente puede seleccionar herramientas, combinar datos y ejecutar acciones.

Cada nivel incorpora nuevas decisiones de seguridad.

Proteger estos sistemas requiere controlar quién actúa, qué información puede utilizar, qué herramientas tiene disponibles, qué permisos recibe y qué operaciones puede ejecutar. Las acciones de mayor impacto necesitan límites adicionales, mientras que la observabilidad debe permitir reconstruir el workflow cuando algo no funciona como estaba previsto.

AI Security evoluciona así desde la protección del modelo hacia la protección del sistema completo que lo rodea. Cuando la Inteligencia Artificial puede actuar sobre procesos empresariales, la seguridad también debe controlar el alcance y las consecuencias de esas acciones.