La Amenaza Oculta de los Agentes de IA Exige un Nuevo Modelo de Seguridad

Los sistemas de IA agenticos han alcanzado la corriente principal en el último año. Ahora se utilizan para varias funciones, incluyendo la autenticación de usuarios, el movimiento de capital, el desencadenamiento de flujos de trabajo de cumplimiento y la coordinación en entornos empresariales con una supervisión humana mínima.

Sin embargo, un problema más silencioso está surgiendo con el aumento de la autonomía, no a nivel de instrucciones o políticas, sino a nivel de infraestructura de confianza. Los sistemas agenticos están siendo otorgados con autoridad de insider mientras aún se ejecutan en entornos de cómputo que nunca fueron diseñados para proteger a los tomadores de decisiones autónomos de la infraestructura debajo de ellos.

La seguridad tradicional asume que el software es pasivo, pero los sistemas agenticos no lo son. Razonan, recuerdan y actúan continuamente, de manera autónoma y con autoridad delegada.

No hay que olvidar que los agentes de IA probablemente tengan acceso a datos personales, según su caso de uso, como correos electrónicos y registros de llamadas, entre otras cosas.

Además, mientras que existen protecciones basadas en hardware, como máquinas virtuales confidenciales y recintos seguros, no son aún la base por defecto para la mayoría de las implementaciones de IA agenticas. Como resultado, muchos agentes aún se ejecutan en entornos donde los datos sensibles están expuestos a la infraestructura subyacente durante la ejecución.

Los Agentes Son Insiders, No Herramientas

Los equipos de seguridad ya saben lo desafiante que es contener las amenazas de insiders, un problema destacado en el informe de Verizon de 2025 sobre violaciones de datos, que muestra que la intrusión en el sistema fue responsable de más del 53% de las violaciones confirmadas del año pasado. En el 22% de estos casos, los atacantes utilizaron credenciales robadas para obtener acceso, lo que destaca cuán a menudo tienen éxito utilizando identidades legítimas en lugar de explotar fallos técnicos.

Ahora, considere un agente, que está compuesto por lógica de instrucción, herramientas y plugins, credenciales, así como políticas. No solo puede ejecutar código y navegar por la web, sino que también puede consultar CRM, leer correos electrónicos y empujar tickets, entre muchas otras cosas. Lo que la combinación de funciones ha traído es superficies de ataque tradicionales a una interfaz moderna.

El peligro planteado por tales amenazas de insiders no es especulativo. El Proyecto de Seguridad de Aplicaciones Web Abiertas (OWASP) ahora enumera la “Inyección de Instrucción” como una vulnerabilidad crítica para aplicaciones de LLM, destacando su particular peligro para los sistemas agenticos que encadenan acciones. El equipo de inteligencia de amenazas de Microsoft también ha publicado avisos que advierten que los sistemas de IA con acceso a herramientas pueden ser subvertidos para realizar el robo de datos si no se implementan salvaguardas de manera arquitectónica.

Estos informes ofrecen un recordatorio oportuno de que los agentes que tienen acceso legítimo a sistemas y datos pueden ser volteados en contra de sus propietarios. Sin embargo, el paisaje de riesgos para los sistemas agenticos no es unitario. Las amenazas de la capa de aplicación como la inyección de instrucción y el abuso de herramientas se originan en la incapacidad del modelo para distinguir entre instrucciones confiables y entrada de usuario no confiable, una limitación de diseño que no puede ser corregida por endurecimiento de memoria.

Un problema diferente y igualmente importante existe a nivel de infraestructura: algunos agentes se ejecutan en memoria en texto plano, lo que significa que la información sensible, como historias de chat, respuestas de API y documentos, puede ser vista mientras se procesa y puede seguir siendo accesible más tarde. OWASP identifica este riesgo como Divulgación de Información Sensible (LLM02) y Fuga de Prompt del Sistema (LLM07) y sugiere el uso de aislamiento de contexto, segmentación de espacio de nombres y sandbox de memoria como medidas de seguridad importantes.

Por lo tanto, los usuarios no deben tratar a estos agentes como simples aplicaciones, dado que son ejecutores dinámicos y razonadores que requieren un modelo de seguridad que tenga en cuenta su naturaleza única como entidades no humanas con agencia. Este enfoque necesita incluir tanto controles de software para limitar cómo actúa el modelo como protecciones de hardware para mantener los datos seguros mientras se utilizan.

La Arquitectura de la Confianza Tiene un Flaw Crítico

Las prácticas de seguridad actuales se centran en proteger los datos en reposo y en tránsito. La última frontera, los datos en uso, sigue casi completamente expuesta. Cuando un agente de IA razona sobre un conjunto de datos confidenciales para aprobar un préstamo, analizar registros de pacientes o ejecutar una operación, esos datos suelen estar descifrados y procesados en texto plano dentro de la memoria del servidor.

En los modelos de nube estándar, cualquier persona con control suficiente sobre la infraestructura, incluyendo administradores de hipervisores o atacantes de co-inquilinos, puede potencialmente mirar lo que está sucediendo mientras se ejecuta una carga de trabajo. Para los agentes de IA, esa exposición es especialmente peligrosa, ya que necesitan acceso a información sensible para hacer su trabajo, lo que puede convertirse en una superficie de ataque.

Como demostró Lumia Security, los atacantes con acceso a una máquina local pueden obtener JWT y claves de sesión directamente de la memoria del proceso de aplicaciones de escritorio de ChatGPT, Claude y Copilot. Estas credenciales robadas pueden permitirles fingir ser otro usuario, robar historial de conversación e inyectar instrucciones en sesiones en curso que pueden cambiar el comportamiento del agente o plantar recuerdos falsos.

Un ejemplo de esto podría ser el incidente de volcado de memoria de AWS CodeBuild en julio de 2025. Los atacantes agregaron código malicioso a un proyecto en secreto, y cuando el sistema lo ejecutó, el código miró dentro de la memoria del computador y robó tokens de inicio de sesión ocultos almacenados allí. Con esos tokens, los atacantes podían cambiar el código del proyecto y potencialmente acceder a otros sistemas.

Para las instituciones financieras, la manipulación silenciosa es existencial. Los bancos, aseguradoras y firmas de inversión ya absorben costos de violación de datos promedio de más de $10 millones, y entienden que la integridad es tan importante como la confidencialidad. Según un informe reciente de Informatica, el “paradigma de confianza” se explica de la siguiente manera: las organizaciones están desplegando agentes autónomos más rápido de lo que pueden verificar sus salidas. El resultado es la automatización que puede cablear errores o sesgos directamente en procesos centrales, operando a velocidad de máquina.

Computación Confidencial y el Caso para el Aislamiento

Las soluciones incrementales no resolverán el problema en cuestión, aunque los controles de acceso más estrictos y una mejor supervisión pueden ayudar. Sin embargo, ninguno de los dos puede cambiar el problema subyacente. El problema es arquitectónico, y mientras la computación ocurra en memoria expuesta, los agentes serán vulnerables en el momento en que más importa, que es al razonar.

La computación confidencial, definida por el Consorcio de Computación Confidencial (CCC) como la protección de los datos en uso a través de entornos de ejecución de confianza basados en hardware (TEEs), aborda directamente el defecto central.

Para los agentes de IA, este aislamiento a nivel de hardware es transformador, ya que permite que las credenciales de identidad del agente, sus pesos de modelo, las instrucciones propietarias y los datos de usuario sensibles que procesa permanezcan cifrados no solo en disco o sobre una red, sino activamente en memoria durante la ejecución. La separación rompe definitivamente el modelo tradicional en el que el control sobre la infraestructura garantiza el control sobre la carga de trabajo.

La verificación remota proporciona evidencia criptográfica verificable de que una solicitud de inferencia específica se ejecutó dentro de un entorno de ejecución de confianza respaldado por hardware, ya sea un CPU o una GPU. La prueba se genera a partir de mediciones de hardware y se entrega junto con la respuesta, lo que permite la verificación independiente de dónde y cómo se ejecutó la carga de trabajo.

Los registros de verificación no revelan el código que se ejecutó. En su lugar, cada carga de trabajo se asocia con un ID de carga de trabajo o ID de transacción único, y el registro de verificación de TEE se vincula a ese identificador. La verificación confirma que la computación se ejecutó dentro de un entorno de confianza sin divulgar su contenido.

La configuración crea una nueva base para la cumplimiento y la auditoría, lo que permite vincular las acciones de un agente a una versión específica de código que ha sido verificada y a un conjunto conocido de datos de entrada.

Hacia la Autonomía Responsable

Las implicaciones para el sistema descrito anteriormente van más allá de la seguridad básica. Considere las leyes que rigen las finanzas, la atención médica y la información personal. Muchas jurisdicciones aplican reglas de soberanía de datos que restringen dónde se puede procesar la información. En China, la Ley de Protección de Información Personal y la Ley de Seguridad de Datos requieren que ciertas categorías de datos, como datos personales importantes, se almacenen en el país y se revisen antes de transferirlos al extranjero.

De manera similar, varios países del Golfo, como los Emiratos Árabes Unidos y Arabia Saudita, han adoptado enfoques similares, especialmente para datos financieros, gubernamentales y de infraestructura crítica.

La computación confidencial puede fortalecer la seguridad y la auditoría al proteger los datos mientras se procesan y permitir la verificación del entorno de ejecución. Sin embargo, no cambia dónde se realiza el procesamiento. Donde las reglas de soberanía de datos requieren procesamiento local o imponen condiciones en las transferencias transfronterizas, los entornos de ejecución de confianza pueden respaldar controles de cumplimiento, no reemplazar requisitos legales.

Además, la computación confidencial permite la colaboración segura en sistemas de múltiples agentes, donde los agentes de diferentes organizaciones o dentro de diferentes departamentos a menudo necesitan compartir información o validar salidas sin exponer datos propietarios.

Y cuando la tecnología se combina con una arquitectura de confianza cero, el resultado es una base mucho más sólida. La confianza cero valida continuamente la identidad y el acceso, mientras que la computación confidencial protege la memoria del hardware contra la extracción no autorizada y evita que la información sensible se recupere en texto plano.

Juntos, defienden lo que realmente importa, por ejemplo, la lógica de decisión, las entradas sensibles y las claves criptográficas que autorizan la acción.

Nueva Línea Base para Sistemas Autónomos

Si cada interacción pone a las personas en riesgo de exposición, no dejarán que la IA maneje cosas como registros médicos o tome decisiones financieras. De manera similar, las empresas no automatizarán sus tareas más importantes si hacerlo podría generar problemas regulatorios o la pérdida de datos importantes.

Los constructores serios reconocen que las soluciones de la capa de aplicación por sí solas son insuficientes en entornos de alta confianza.

Cuando los agentes están investidos con autoridad financiera, datos regulados o coordinación interorganizacional, la exposición a nivel de infraestructura se convierte en más que una preocupación teórica. Y sin ejecución confidencial en tales contextos, muchos agentes siguen siendo un objetivo blando, con sus claves robables y su lógica maleable. El tamaño de las violaciones modernas muestra exactamente hacia dónde conduce ese camino.

La privacidad y la integridad no son características opcionales que se pueden agregar después de la implementación. Deben ser diseñadas desde el nivel de silicio hacia arriba. Por lo tanto, para que la IA agéntica se pueda escalar de manera segura, la confidencialidad respaldada por hardware no puede considerarse solo como una ventaja competitiva, sino como la línea base.