Los agentes de IA destapan una brecha de seguridad entre lo que leen y lo que pueden modificar

El artículo, firmado por Adithyan RK (cofundador y CEO de Hyring) como colaboración externa en VentureBeat, plantea un argumento que se aparta del debate habitual sobre seguridad en IA. Durante los últimos dos años, la conversación se ha centrado casi siempre en el modelo: si está bien alineado, si puede ser manipulado mediante jailbreaks, si alucina bajo presión. Según el autor, esas preguntas siguen siendo válidas, pero ya no capturan el riesgo real que aparece cuando las organizaciones pasan de pilotos con agentes de IA a sistemas en producción. Ese riesgo no vive en los pesos del modelo, sino en la infraestructura construida a su alrededor: la forma en que el agente lee datos, llama a herramientas, escribe en bases de datos y dispara automatizaciones.

El punto de partida es que el patrón de interacción asumido durante la era del chatbot —una persona escribe un prompt, el modelo responde con texto, un humano lo lee— ya no describe cómo funcionan los sistemas de IA actuales. Los agentes en producción leen fuentes de datos vivas, invocan APIs externas, escriben en sistemas reales y, cada vez con más frecuencia, actúan sin que haya ningún humano supervisando en tiempo real. Cada una de esas capacidades nuevas es también una superficie de ataque que simplemente no existía antes.

El autor detalla varias categorías de riesgo que, según argumenta, no tienen relación con la calidad del modelo. La primera es la inyección de prompts a través de datos conectados: cuando un agente recupera contenido de un registro de CRM, un ticket de soporte, una página web o un documento compartido, ese contenido pasa a formar parte de su contexto, y un atacante no necesita acceso al modelo para manipular su comportamiento, solo necesita acceso a algo que el modelo acabará leyendo. Instrucciones escondidas en un PDF, en la firma de un correo o en la reseña de un producto pueden secuestrar la siguiente acción de un agente con la misma eficacia que un prompt escrito directamente en una ventana de chat.

La segunda categoría son las llamadas a herramientas con permisos excesivos. Los frameworks de agentes suelen conceder a los modelos la capacidad de enviar correos, consultar bases de datos, modificar registros o ejecutar código, y muchas de estas integraciones se construyen con permisos pensados para la velocidad de desarrollo —claves de API amplias, cuentas de servicio con mucho más acceso del que la tarea concreta requiere— simplemente porque es la forma más rápida de hacer funcionar una demo. En producción, ese mismo modelo de permisos significa que un prompt manipulado o un simple error de razonamiento puede convertirse en una acción real con consecuencias: un registro borrado por error, un mensaje enviado al destinatario equivocado, un pago disparado indebidamente.

La tercera es la fragilidad de los límites de confianza entre herramientas en flujos multi-agente. Cuando varios componentes se encadenan y se pasan resultados entre sí sin revalidar lo que cruza cada frontera, un modelo que resume un documento no confiable y entrega ese resumen a un segundo agente con permisos de escritura en un sistema de producción está, en la práctica, dejando que un tercero no autenticado influya en ese sistema, aunque ningún humano le haya concedido esa confianza de forma explícita.

La cuarta es la falta de observabilidad. La seguridad de aplicaciones tradicional asume que se puede registrar una petición, rastrear una pila de llamadas y reconstruir qué ocurrió tras un incidente. Los flujos agénticos, señala el autor, a menudo no ofrecen esa posibilidad: las trazas de razonamiento son no deterministas, las secuencias de llamadas a herramientas varían de una ejecución a otra, y muchos equipos todavía no registran las decisiones intermedias del agente con el nivel de detalle necesario para responder una pregunta básica de respuesta a incidentes: qué hizo realmente el sistema y por qué.

La quinta categoría son los flujos de decisión automatizados sin ningún mecanismo de frenado. A medida que aumenta la autonomía, el agente ya no se limita a redactar una respuesta, sino que la envía; no solo marca una anomalía, sino que actúa sobre ella. El coste de una sola mala decisión se multiplica, especialmente cuando no existe límite de frecuencia, puerta de aprobación o interruptor de apagado entre el momento en que 'el modelo decide' y el momento en que 'la acción ocurre'. El autor insiste en que ninguno de estos cinco problemas se soluciona cambiando a un modelo más capaz o mejor alineado, porque residen en la fontanería del sistema, no en los pesos del modelo.

El artículo enmarca todo esto como un problema de gobernanza organizativa, no solo técnico. Las preguntas sobre seguridad de la IA suelen recaer en los equipos de machine learning o ciencia de datos, que están preparados para evaluar el comportamiento del modelo pero no necesariamente para asumir la seguridad de las integraciones, el control de accesos o la observabilidad en producción. Mientras tanto, los equipos de seguridad e ingeniería de plataforma —que llevan décadas de experiencia institucional asegurando exactamente este tipo de sistemas: servicios que llaman a servicios, credenciales con permisos acotados, registro de auditoría, respuesta a incidentes— con frecuencia no se incorporan hasta que el flujo agéntico ya está en producción.

Según el autor, las organizaciones que escalan la IA con éxito son las que cierran esa brecha pronto, tratando a un agente de IA como tratarían cualquier nuevo servicio en producción con acceso de escritura a sistemas reales. Eso se traduce, en la práctica, en una lista de comprobación poco glamurosa pero concreta: acceso de mínimo privilegio por defecto, de modo que si un agente solo necesita leer un registro de cliente, no debería tener una credencial que también le permita escribir en él; entornos de pruebas (sandboxing) antes de conceder autonomía, con una vía de graduación deliberada y supervisada hacia el acceso en producción, en lugar de desplegar permisos completos solo porque la demo funcionó; puertas de aprobación humana para acciones de alta consecuencia, entendiendo que la autonomía no es binaria y que un flujo puede dejar que el modelo redacte una acción —un reembolso, un correo a un cliente, un cambio en un sistema en vivo— mientras exige aprobación explícita antes de ejecutarla, con el umbral fijado según el radio de impacto de la acción y no según lo convincente que suene el modelo.

A esa lista se suman otras dos recomendaciones: registrar a nivel de decisión y no solo de resultado, capturando qué leyó el agente, qué herramientas invocó, qué argumentos utilizó y por qué, de forma que tras un incidente la pregunta de qué pasó y por qué tenga una respuesta que no dependa de conjeturas; y tratar cualquier dato de terceros como entrada no confiable, aplicando a una página web, un archivo subido o un correo electrónico la misma sospecha que se aplicaría a la entrada de un usuario en una aplicación web tradicional, porque funcionalmente es exactamente eso. Finalmente, el autor propone mecanismos explícitos de frenado —límites de frecuencia, detección de anomalías y capacidad de anulación manual sobre las acciones automatizadas— para que una sola cadena de razonamiento defectuosa no pueda multiplicarse en miles de acciones erróneas antes de que un humano se dé cuenta.

La conclusión del artículo es que nada de esto es exótico: es la misma disciplina de ingeniería que ha gobernado el software en producción durante dos décadas —permisos acotados, validación de entradas, observabilidad, despliegues escalonados, revisión humana de acciones consecuentes—. Lo nuevo es que ahora, dentro de ese sistema, hay un modelo probabilístico y ocasionalmente impredecible tomando parte de las decisiones sobre qué ocurre a continuación. Por eso, argumenta el autor, el flujo de trabajo alrededor del modelo merece mucho más escrutinio del que recibe hoy: un modelo más capaz no hace más segura una integración con exceso de permisos, y un modelo mejor alineado no arregla la ausencia de una puerta de aprobación. A medida que los agentes de IA asumen trabajo más autónomo y consecuente dentro de empresas reales, las organizaciones que sufrirán los mayores problemas no serán necesariamente las que usan el modelo más débil, sino las que nunca se preguntaron si el sistema construido alrededor de su modelo estaba diseñado para poder asegurarse.