Agentes de IA: solo el 14% puede revocar permisos

Por qué la seguridad de agentes de IA ya no se mide por certificaciones

Cuando un agente autónomo ejecuta acciones en producción, la pregunta que importa no es cuántas certificaciones acumula tu proveedor de nube, sino algo mucho más operativo: si ese agente queda comprometido, ¿puedes aislarlo y revocar sus permisos en minutos sin frenar el resto de tus operaciones?

Según el análisis de VentureBeat recogido por CriptoTendencia, la respuesta para la mayoría de las empresas es hoy un no. Y ese no tiene consecuencias directas sobre la continuidad del negocio.

La brecha de gobernanza: credenciales compartidas y revocación lenta

Los datos de VentureBeat Intelligence son elocuentes. En una encuesta realizada en agosto, la mitad de los participantes afirmó que su organización ya usaba agentes en producción. Dentro de ese grupo, el 61% reconoció algún grado de uso compartido de credenciales entre agentes.

Una investigación posterior, en septiembre, mostró la otra cara: solo el 14% de quienes respondieron sobre revocación aseguró que un responsable identificado podía retirar los permisos de un agente específico en cuestión de minutos.

El problema de las credenciales compartidas es doble. Por un lado, desactivar el acceso de un agente comprometido puede tumbar procesos legítimos que dependen de esa misma autorización. Por otro, las identidades compartidas hacen imposible saber qué agente ejecutó una acción concreta, lo que complica cualquier investigación posterior.

Este patrón no es exclusivo de las empresas encuestadas por VentureBeat. El reporte "Agents Without Guardrails" de Enterprise Management Associates (EMA), elaborado para Cequence Security sobre 202 líderes de tecnología y seguridad, encontró que el 65% de las empresas vio a sus agentes actuar fuera del alcance previsto, y un 29% reportó impacto organizacional medible. Solo el 32,2% podía detectar y contener una acción fuera de alcance en minutos con mecanismos automatizados; el 54,5% necesitaba horas e intervención manual.

La escala del desafío explica por qué los controles tradicionales se quedan cortos. El reporte 2026 Identity Security Landscape de Palo Alto Networks, basado en respuestas de más de 2.900 responsables de decisiones de ciberseguridad, describe una relación de identidades máquina-humano de 109 a 1, según recogió TechRepublic.

Guardrails vs. políticas de acceso: no son lo mismo

Uno de los errores más caros es creer que los guardrails del modelo sustituyen al control de acceso. Nir Chervoni, responsable de productos de seguridad en Nebius, lo plantea con claridad: son capas distintas que resuelven problemas distintos.

• Guardrails del modelo: orientan, limitan o filtran las respuestas y acciones que propone la IA. Pueden fallar frente a manipulación de contexto, ataques de inyección de instrucciones (prompt injection) o comportamientos inesperados.
• Políticas de acceso (IAM): definen qué recursos puede consultar o modificar cada identidad y qué operaciones está autorizada a ejecutar. Deben aplicarse con independencia de las instrucciones que reciba el modelo.

La evidencia de campo respalda esa distinción. En DEF CON 34, la firma Tenet Security presentó su investigación "GhostJacking", que muestra cómo un atacante puede envenenar contenido en sistemas de confianza —alertas de seguridad, logs, reportes de error— para que un agente lo interprete como instrucciones legítimas y las ejecute con sus propios permisos. En una de las demostraciones, un evento que el firewall de Cloudflare ya había bloqueado sirvió como vector: Claude Code cayó en la trampa en 9 de cada 10 intentos, según reportó Dark Reading.

El punto clave: no hubo acceso no autorizado. El agente usó permisos que legítimamente tenía.

Computación confidencial en GPU: qué protege y qué no

La computación confidencial amplía la protección más allá del almacenamiento y las comunicaciones: en implementaciones compatibles, refuerza la confidencialidad de los datos y los modelos mientras se procesan en entornos con CPU y GPU.

Su componente central es la atestación, un procedimiento que verifica la integridad del entorno de ejecución y que puede usarse como condición para liberar claves criptográficas.

Pero conviene no confundir el alcance. La computación confidencial no elimina vulnerabilidades de las aplicaciones, no impide por sí misma los ataques de inyección de instrucciones y no determina si las decisiones de un agente están autorizadas. Una identidad comprometida todavía puede ejecutar operaciones que sus credenciales permiten.

El mercado se está moviendo rápido en esta dirección. Según ABI Research, la computación confidencial dejó de ser una conversación solo de CPU y avanza hacia GPU, entornos multi-GPU, contenedores y flujos agénticos. NVIDIA lidera con avances en sus plataformas Hopper, Blackwell y Vera Rubin, mientras Intel, AMD y Arm refuerzan la base de cómputo heterogéneo.

En cuanto al rendimiento, NVIDIA publicó en su blog que su framework de computación confidencial sobre GPU Blackwell retiene entre 96% y 98% del rendimiento de una configuración no confidencial, con una sobrecarga de latencia de 1,2% a 4,3%, según recogió Blockchain.news.

El tamaño del mercado confirma el interés: según el reporte de ResearchAndMarkets difundido por GlobeNewswire, el mercado global de computación confidencial pasaría de US$12.280 millones en 2025 a US$16.690 millones en 2026, con una proyección de US$54.920 millones para 2030.

Qué deberías exigir a tu proveedor de infraestructura de IA

Antes de firmar con un proveedor de nube especializado en IA, la recomendación del análisis es ir más allá de las certificaciones y pedir evidencia operativa en cuatro frentes:

• Saneamiento del hardware: cómo se limpia la memoria de las GPU, cómo se verifica la integridad del firmware y cómo se preparan los equipos antes de reasignarlos a otro cliente.
• Aislamiento de redes de alta velocidad: prueba de que las conexiones entre GPU y otros recursos de un cliente permanecen separadas de las de terceros.
• Separación del plano de control: que las cargas de trabajo no puedan alcanzar las interfaces de administración y que los componentes compartidos tengan aislamiento adecuado.
• Soberanía y protección de datos: no solo dónde se almacena la información, sino quién accede, cómo se procesa, cuánto tiempo se conserva y quién controla las claves de cifrado.

A esto conviene sumar pruebas prácticas: revocación de permisos, verificación de integridad y recuperación ante incidentes. Y medir el impacto de todo esto en rendimiento y costos.

¿Qué significa esto para tu startup?

Si tu equipo ya corre agentes en producción —o está a punto de hacerlo—, la seguridad deja de ser un tema de infraestructura y pasa a ser un tema de arquitectura de producto. Tres acciones concretas:

• Una identidad por agente, con credenciales de corta duración. Si dos agentes comparten la misma API key, no puedes apagar uno sin apagar el otro. Empieza por inventariar qué agentes tienes corriendo y con qué credenciales.
• Prueba la revocación antes de necesitarla. Haz un ejercicio real: intenta retirar los permisos de un agente específico y cronometra cuánto tardas y qué más se rompe. Si la respuesta es "horas" o "no sabemos", ese es tu riesgo.
• Separa la lectura de la escritura en lo posible. La pregunta operativa que sugiere Tenet Security es simple: ¿qué agentes leen datos externos y además pueden escribir o ejecutar? Esa lista es tu registro de riesgo, y armarla no cuesta nada.

Para startups en LATAM y España, con equipos pequeños y presión por mover rápido, la tentación es postergar la gobernanza de agentes hasta que haya un incidente. El dato del 14% sugiere que casi todos tus competidores están en esa misma posición. Hacerlo bien antes no es un lujo de enterprise: es una ventaja competitiva cuando llegue la primera due diligence seria de un cliente corporativo.

Conclusión

La madurez en IA corporativa ya no se mide por lo que un agente puede hacer, sino por lo que puedes impedirle hacer cuando algo falla. La prueba real es retirar los permisos de un agente comprometido de forma rápida, verificable y sin interrumpir el resto de la operación. La computación confidencial en GPU resuelve una parte importante del problema —proteger los datos mientras se procesan—, pero no sustituye la identidad, el control de acceso ni la capacidad de respuesta. Esas tres capas siguen siendo responsabilidad tuya.

Fuentes

• CriptoTendencia (fuente original)
• TechRepublic
• Infosecurity Magazine
• Dark Reading
• Yahoo Finance
• Business Insider
• Blockchain.news