Confidential Computing para IA agéntica: lo que los enclaves no protegen

¿De qué se trata?

El 4 de mayo de 2026, Javad Forough, Marios Kogias y Hamed Haddadi publicaron When Agents Handle Secrets: A Survey of Confidential Computing for Agentic AI (arXiv:2605.03213). Es el primer intento sistemático de proyectar el Confidential Computing (CC) —entornos de ejecución de confianza (TEE) anclados en el hardware— sobre las necesidades de seguridad de los agentes LLM que planifican, invocan herramientas, mantienen memoria persistente y delegan en agentes pares mediante protocolos como MCP y A2A.

El enfoque del estudio resulta valioso justamente por ser honesto con los límites. El CC no corrige la prompt injection. Su conclusión central: aunque varias primitivas de confianza por hardware parecen lo bastante maduras para despliegues concretos, «todavía no existe un marco de extremo a extremo ampliamente establecido que las una en un sustrato de seguridad coherente para la IA agéntica en producción». Es un trabajo de arquitectura defensiva, no un ataque nuevo.

Cómo funciona

Las defensas de agente actuales —filtros de entrada, clasificadores de salida, listas de permitidos— «operan por completo dentro de la pila de software y un adversario suficientemente privilegiado, como un operador cloud comprometido, puede eludirlas en silencio». El CC traslada la frontera de confianza al hardware: el código y los datos se ejecutan en un enclave atestado que ni siquiera el SO anfitrión, el hipervisor o el operador de infraestructura pueden leer ni manipular.

Los autores descomponen un agente en cinco capas —percepción, planificación, memoria, acción, coordinación— y ordenan a los adversarios por fuerza: atacante externo, co-inquilino comprometido, operador de infraestructura malicioso (el caso que el CC busca neutralizar) y agente comprometido. Luego identifican los activos de valor que un TEE envolvería:

perception   -> prompts de usuario, documentos recuperados, entradas de herramientas
planning     -> pesos del modelo, prompts de sistema, adaptadores LoRA ajustados
memory       -> caché KV, historial, base vectorial, credenciales
action       -> llamadas a herramientas, parámetros, salidas de herramientas
coordination -> mensajes entre agentes, reclamaciones de delegación, atestación

La memoria se señala como objetivo prioritario: las bases vectoriales de largo plazo acumulan meses de contexto propietario, y la caché KV puede filtrar una conversación al pie de la letra. El estudio cita el hallazgo real LeftoverLocals, donde residuos de caché KV en memoria GPU compartida permitieron reconstruir conversaciones entre inquilinos: justo la clase de fuga que un TEE de GPU debe cerrar.

El hardware existe. El estudio cubre seis plataformas —Intel SGX, Intel TDX, AMD SEV-SNP, ARM TrustZone, ARM CCA y NVIDIA H100 Confidential Computing—, el primer TEE de GPU, anclado en una raíz de confianza en el chip con informes de atestación firmados. NVIDIA reporta menos de ~7 % de sobrecarga en inferencia LLM en modo CC, y mediciones independientes confirman que la sobrecarga de los TEE de GPU ya es lo bastante baja para producción —a diferencia del cifrado totalmente homomórfico o el MPC, que aún imponen entre dos y cuatro órdenes de magnitud de sobrecarga.

Por qué importa

Los despliegues agénticos concentran secretos: claves de API de proveedores, documentos corporativos recuperados y memoria acumulada conviven en un mismo runtime. En una nube multi-inquilino, el operador —o quien lo comprometa— está dentro de esa frontera de confianza. El CC es el único control que aborda directamente a ese adversario; un estudio de IDC citado por los autores halla un 75 % de organizaciones adoptando CC (18 % en producción, 57 % en pruebas).

Pero el punto más afilado es lo que el CC no resuelve. En un agente, «el LLM es el plano de control», y la superficie de ataque «es el significado de los datos, no su origen ni su formato». Un TEE puede demostrar qué código se ejecuta y mantener la memoria confidencial; no puede demostrar la intención de una entrada. Por eso un enclave ejecutará fielmente una instrucción inyectada. El exploit EchoLeak de 2025 (CVE-2025-32711), una inyección de cero clics que exfiltraba datos de Microsoft 365 Copilot desde un solo correo, se habría ejecutado igual dentro de un enclave perfectamente atestado.

Defensas

• Use el CC contra la amenaza del operador, no contra la inyección. Coloque pesos del modelo, bases vectoriales, caché KV y credenciales en un TEE CPU+GPU para neutralizar a un operador de infraestructura malicioso o comprometido y las fugas de memoria entre co-inquilinos (tipo LeftoverLocals).
• Mantenga las defensas semánticas. El CC complementa —no sustituye— el filtrado de entrada/salida, el mínimo privilegio en herramientas y la disciplina de la lethal trifecta. La prompt injection sigue siendo un problema de arquitectura.
• Exija atestación compuesta. Ateste el TEE de CPU y el de GPU juntos; la atestación solo de GPU deja huecos. Trate la atestación como «qué código se ejecuta», nunca como «esta entrada es de fiar».
• Cuide las fugas residuales. Los TEE no detienen los canales laterales —temporización, contención de caché/bus, ataques de canal controlado y fallos de página, estado residual de GPU—. Combine el CC con builds reproducibles, model cards y trazabilidad del fine-tuning.
• Siga los problemas abiertos. Los autores señalan seis áreas sin resolver, entre ellas la atestación compuesta para cadenas de agentes multi-salto, el aislamiento de RAG respaldado por TEE y las fugas por canal lateral en la inferencia autorregresiva.

Estado

Elemento	Detalle
Fuente	Estudio, arXiv:2605.03213v1 (cs.CR), CC BY 4.0
Publicación	4 de mayo de 2026
Amenaza tratada	Operador de infraestructura malicioso; fuga de memoria entre co-inquilinos
No tratado	Prompt injection, objetivos inseguros, compromiso de la cadena del modelo, canales laterales
Madurez TEE de GPU	NVIDIA H100 CC, ~7 % de sobrecarga en inferencia (cifra de NVIDIA)
Veredicto de madurez	Primitivas utilizables; aún sin sustrato CC agéntico de extremo a extremo