Ciberseguridad
Redacción Teknosfera
Ciberseguridad

El incidente del Pentágono no es un fallo de la IA, sino del control de acceso

Un contratista de Accenture habría conectado un agente personal de Claude a un sistema seguro del Pentágono. La lección va de identidades, permisos y normas para contratistas, no de IA.

Publicado
30 de octubre de 2026
Lectura
4 min
Categorías
Ciberseguridad

Imagen generada con IA

¿Quién expuso realmente los datos: el agente de IA o la persona que le entregó las llaves? Es fácil leer el incidente del Pentágono como la historia de una máquina descontrolada que se cuela en una red restringida. Según lo publicado hasta ahora, fue una persona quien la hizo entrar y le mantuvo la puerta abierta.

Lo que se ha publicado

Según Wired, un empleado de Accenture habría conectado un entorno de producción seguro a su cuenta personal de Claude para que un agente de IA escribiera y desplegara código. Otros medios, como CDO Magazine, señalan que esto pudo exponer credenciales de acceso e información de la red. El relato de Wired se apoya en fuentes anónimas y, según el resumen de aiweekly.co, el agente estuvo funcionando en la red del Departamento de Defensa unos dos meses antes de que nadie lo identificara.

El medio alemán Golem afirma que, al parecer, salieron datos del sistema. Algunas webs más pequeñas van más allá y hablan de información de inteligencia expuesta, pero preferimos tomar esos detalles con cautela hasta que aparezca algo más sólido. Sigue siendo una acusación, y el alcance exacto de la exposición no está establecido.

El agente hizo lo que hacen los agentes

Tomemos el detalle más comprometedor: el agente trabajaba, presuntamente, con acceso de administrador. Un agente que escribe y despliega código necesita credenciales para hacerlo. Usó lo que le dieron. Culpar aquí a la «IA» es como culpar a un repartidor por entrar en un edificio después de que alguien le haya dado una llave maestra.

A nuestro juicio, el fallo interesante es el humano, y es antiguo. La información publicada no explica por qué lo hizo el empleado, pero el patrón es conocido: alguien recurre a una herramienta en la que confía y la conecta a algo que nunca debió tocar. Cambia el agente por una cuenta personal de almacenamiento en la nube o por un script en un portátil de casa y obtendrás una historia parecida. Lo que ha cambiado es que ahora la herramienta actúa por su cuenta, deprisa y con los permisos que se le den.

Por eso esto es más peligroso que el shadow IT al que estamos acostumbrados. Una hoja de cálculo olvidada se queda ahí quieta. Un agente con permisos de despliegue sigue trabajando y, en este caso, presuntamente siguió trabajando unos dos meses.

Los agentes necesitan identidades, no accesos prestados

La solución práctica no es «prohibir los agentes», sino tratarlos como lo que son: un nuevo tipo de actor en la red. En nuestra opinión, eso implica algunas medidas poco vistosas:

  • Identidad propia. Un agente nunca debería funcionar con la cuenta de su usuario y, desde luego, nunca como administrador. Si algo sale mal, los registros deberían decir «el agente X hizo esto», no «Alicia hizo esto».
  • Alcance limitado. El acceso de lectura a un repositorio es una petición razonable. El acceso de administrador a un entorno de producción no es un punto de partida.
  • Revocable y de corta duración. Unas credenciales que caducan solas y se pueden anular de un solo paso convierten un incidente de dos meses en uno de dos horas.
  • Visibilidad. El detalle que más nos llama la atención son esos dos meses. Según lo publicado, el agente estuvo en un entorno seguro todo ese tiempo antes de ser identificado. Parece tanto un fallo de monitorización como de permisos.

Fíjate en que nada de esto tiene que ver con el modelo. Se aplicaría igual a cualquier herramienta autónoma, de cualquier proveedor.

Los contratistas, donde las normas son más laxas

La otra lección es organizativa, y aquí especulamos sobre cómo suelen surgir estas brechas, no describimos lo que ocurrió en este caso. Un contratista se sitúa entre las políticas de dos empresas, y cada una puede dar por hecho que la otra se ocupa del problema. La empresa que lo emplea puede decir que las normas del cliente rigen en los sistemas del cliente, mientras que el cliente puede suponer que a cualquiera con una acreditación ya se le ha informado. Añade a un contratista con prisa por un plazo y una suscripción personal de IA que le facilita el trabajo, y la tentación es evidente.

Prevemos, y es una predicción, que el uso de agentes se escribirá de forma explícita en los contratos con contratistas: qué herramientas se permiten, en qué sistemas, con qué cuentas y con qué registros. Nadie debería tener que deducir que una cuenta personal de IA no tiene cabida en un sistema de producción seguro. Las normas que solo existen como sentido común no sobreviven a un plazo de entrega.

También conviene señalar que Anthropic, cuya herramienta está en el centro de los titulares, aparece en las informaciones como el producto que eligió el empleado, no como la parte que tomó la decisión sobre el acceso. Esa distinción importa, aunque sea razonable preguntar al proveedor qué salvaguardas ofrece para uso empresarial y gubernamental.

Nuestro veredicto

Si diriges un equipo, no pierdas esta semana debatiendo si los agentes son seguros. Dedícala a averiguar qué agentes usa ya tu gente, con las cuentas de quién y con qué permisos. Después, da a esos agentes identidades propias, con alcance limitado y caducidad, y deja por escrito las normas para contratistas. El episodio del Pentágono, si lo publicado se confirma, es el aviso barato. El próximo puede no serlo.

Temas de debate

Aún no hay temas: abre el primero.

Más noticias