Agentes de IA: el nuevo riesgo no está en el modelo, sino en todo lo que puede tocar
A medida que los agentes de inteligencia artificial pasan de responder preguntas a leer bases de datos, utilizar APIs, modificar registros y ejecutar acciones sin supervisión humana, la superficie de ataque se desplaza desde el modelo hacia el sistema que lo conecta con el mundo real.
Durante años, buena parte de la conversación sobre seguridad en inteligencia artificial estuvo concentrada en el modelo: si podía ser manipulado mediante un jailbreak, si produciría información falsa o si seguiría correctamente las instrucciones de sus desarrolladores. Pero la llegada de agentes capaces de actuar sobre sistemas empresariales está cambiando la naturaleza del problema.
El riesgo ya no está únicamente en lo que un modelo puede decir. Está en lo que puede hacer.
Un análisis publicado por VentureBeat plantea que los sistemas de IA que están entrando en producción ya no funcionan como los chatbots tradicionales. Pueden consultar fuentes de datos en tiempo real, utilizar herramientas y APIs externas, escribir en bases de datos, activar automatizaciones y, cada vez con mayor frecuencia, ejecutar acciones sin que una persona intervenga en cada paso. Cada una de esas capacidades abre una superficie de ataque adicional.
La diferencia es fundamental. En el modelo tradicional, un usuario escribía una instrucción, el sistema generaba una respuesta y una persona decidía qué hacer con ella. En un flujo agentic, la respuesta puede ser apenas el comienzo de una cadena de acciones.
Un agente puede leer un registro de CRM, consultar un documento, interpretar un correo electrónico y después utilizar esa información para llamar una API. Si además tiene permisos para modificar datos o ejecutar operaciones, el límite entre interpretar información y alterar un sistema empresarial se vuelve mucho más estrecho.
Uno de los problemas señalados por VentureBeat es la denominada inyección indirecta de instrucciones. Un agente puede recibir información desde un CRM, un ticket de soporte, una página web, un documento compartido o un correo electrónico. Ese contenido pasa a formar parte del contexto que utiliza el modelo para decidir qué hacer.
El atacante, por tanto, no necesariamente necesita acceder directamente al modelo. Puede intentar manipular una de las fuentes que el agente consultará posteriormente. Una instrucción escondida en un PDF, una firma de correo o incluso una reseña de producto podría influir sobre la siguiente acción del sistema.
OWASP (Open Worldwide Application Security Project), una fundación global dedicada a mejorar la seguridad del software mediante herramientas, documentación y estándares de código abierto gratuitos, identifica precisamente la inyección de instrucciones, el abuso de herramientas, la escalada de privilegios, la exposición de datos, el envenenamiento de memoria y la autonomía excesiva entre los riesgos relevantes de los agentes de IA. Su recomendación central es tratar los datos externos como información no confiable y limitar los permisos de cada herramienta al mínimo necesario.
La consecuencia empresarial es directa: un documento aparentemente inocuo puede convertirse en una vía para influir sobre un sistema que tiene capacidad de escritura.
La velocidad con la que las empresas están construyendo prototipos de agentes también puede generar otro problema. Para poner una demostración en funcionamiento, los equipos de desarrollo pueden asignar a una integración permisos mucho más amplios de los estrictamente necesarios.
El problema aparece cuando ese prototipo llega a producción. Un agente que únicamente necesita consultar un registro debería, en principio, tener permisos de lectura. Si utiliza una credencial que también permite modificar o eliminar información, un error de razonamiento o una instrucción manipulada puede terminar en una acción real.
OWASP recomienda precisamente separar los permisos de lectura y escritura, utilizar credenciales específicas y evitar conceder a los agentes acceso indiscriminado a herramientas o sistemas. También plantea que las operaciones de alto impacto deberían requerir autorización explícita.
No se trata de impedir la autonomía, sino de determinar dónde termina la autonomía y dónde comienza una acción que necesita una barrera adicional.
La complejidad aumenta cuando una arquitectura deja de tener un único agente y comienza a combinar múltiples herramientas o agentes especializados.
Un sistema puede recibir un documento no confiable, resumirlo con un primer agente y enviar ese resultado a un segundo agente que posee permisos de escritura sobre un sistema de producción. Si no existe una validación adecuada entre ambos componentes, la información originalmente no confiable puede terminar influyendo sobre una acción que sí tiene consecuencias operativas.
Ese problema introduce una nueva clase de frontera de confianza. Ya no basta con asegurar cada componente individualmente. También es necesario controlar qué información atraviesa las conexiones entre ellos.
La preocupación ya está llegando a los marcos especializados de seguridad. En septiembre de 2026, OWASP presentó su Agent Control Standard, una iniciativa orientada a que los agentes sean inspeccionables, trazables e instrumentables y a que las políticas de seguridad puedan aplicarse durante su ejecución.
Otro desafío es la observabilidad. En una aplicación convencional, los equipos de seguridad pueden reconstruir un incidente mediante registros, solicitudes y llamadas entre servicios. Los agentes introducen una dinámica diferente: sus secuencias de herramientas pueden variar entre ejecuciones y las decisiones intermedias no siempre quedan registradas con suficiente detalle.
Eso dificulta responder una pregunta elemental después de un incidente: qué hizo exactamente el sistema y por qué.
La recomendación es pasar de registrar únicamente el resultado final a registrar también las decisiones y acciones intermedias: qué información leyó el agente, qué herramientas utilizó, qué argumentos envió y qué ocurrió después.
La seguridad de los agentes, en otras palabras, comienza a parecerse menos a una discusión sobre la personalidad o el comportamiento de un modelo y más a una discusión clásica de arquitectura empresarial.
Comentarios