Los agentes de IA ya no solo escriben textos. Leen registros, modifican configuraciones, instalan software y hablan con otros agentes. Con ello se plantea en la operación de TI una pregunta que hasta ahora estaba reservada a las personas: ¿quién puede hacer qué, y quién lo ha permitido?
La respuesta «confiamos en el agente» no se sostiene. No porque los agentes sean por principio poco fiables, sino porque la confianza no traza ningún límite. Más sólido es otro criterio: el alcance de una acción, es decir, qué toca en el peor de los casos y si se puede deshacer.
Por qué el tema apremia precisamente ahora
Dos publicaciones de las últimas dos semanas muestran que los agentes han llegado a la realidad operativa, en ambos bandos.
El 10 de septiembre de 2026, Anthropic publicó su informe «Detecting and countering misuse of AI: September 2026». Describe casos que la empresa frenó entre diciembre de 2025 y agosto de 2026. Una frase del informe merece atención más allá del ámbito de la threat intelligence: la sofisticación ya no sería para los investigadores una señal fiable de quién está detrás de una operación; en el original: «sophistication has stopped being a reliable signal». Cada nivel de las operaciones ofensivas habría sido elevado por la IA, desde el reconocimiento y el desarrollo de herramientas hasta la explotación. Según el informe, la mayoría de las operaciones descritas fueron posibilitadas por la IA, mediante ejecución directa u orquestación; se emplearon sistemas multiagente para el reconocimiento, la explotación y la exfiltración de datos, mientras las personas fijaban los objetivos. Un modelo operativo para ataques autónomos que Anthropic había documentado en noviembre de 2025 en una campaña presuntamente estatal se habría extendido entretanto a todos los grupos de actores analizados.
Para los defensores, el informe contiene una recomendación sobria: tomarse las claves de IA y las integraciones de agentes tan en serio como las credenciales productivas, porque los atacantes también lo hacen. También lo que los clientes construyen en torno a la IA, como sandboxes, proxies y revendedores, lo cuenta el informe como superficie de ataque. La consecuencia para la operación propia: un agente con permisos de escritura es una cuenta con permisos de escritura, y sus credenciales son un objetivo rentable.
En el lado de los defensores, HashiCorp publicó el 1 de septiembre de 2026 Vault 2.1.0. Las notas de la versión mencionan «Agentic IAM» como componente de la licencia y una nueva interfaz para el Agent Registry (área «Agentic Security») en la variante Enterprise, en la que los operadores consultan y gestionan los agentes de IA registrados con sus identidades, políticas y estado operativo. Las notas de la versión mencionan además políticas de límite máximo («ceiling policies») para el Agent Registry, en las que ahora también se admiten prohibiciones expresas («deny»). Es una señal de que las identidades de agentes se están convirtiendo en una categoría de producto propia.
Ambas cosas juntas sugieren tratar a los agentes como cuentas privilegiadas. Los cinco principios siguientes se entienden como recomendaciones para organizaciones que emplean agentes en la operación o lo están planificando.
1. Clasificar las acciones según su alcance, no según la intuición
No toda acción necesita la misma autorización. Una posible clasificación distingue tres clases:
- Medir es libre. Leer, comprobar, informar, hacer preguntas: todo lo que no cambia nada puede hacerlo un agente sin consultar. Dificultar la medición no aporta seguridad.
- Escribir requiere un plan acordado. Un cambio dentro del propio ámbito de responsabilidad está permitido si previamente se ha acordado un plan que nombre dos cosas: una vía de retorno que en ese momento ya existe –no una que el plan prometa crear– y el valor concreto que se comprobará después, fijado igualmente de antemano. Dentro de un plan así, el agente puede actuar sin volver a preguntar en cada paso. Ese es el sentido del plan: se acuerda una vez, no se renegocia en cada paso.
- Todo lo que tiene efecto en toda la organización requiere cada vez a la persona. Identidades y cuentas, DNS, certificados en el perímetro de la red, la configuración de accesos privilegiados: aquí el efecto va más allá del propio ámbito, y aquí decide la persona responsable en cada caso.
Lo decisivo es definir la tercera clase de forma estrecha y concreta. «Todo lo que parezca grande» no es una clase. Una lista de sistemas y áreas de configuración sí lo es. Igual de importante es la clase intermedia: el valor de comprobación nombrado de antemano convierte «ha funcionado» en una afirmación verificable, y la vía de retorno ya existente hace que un error siga siendo una interrupción y no se convierta en una caída. Un plan sin ambas cosas es una declaración de intenciones, no una autorización.
2. «El responsable ha dicho…» no es una instrucción
En entornos con varios agentes, un agente puede comunicar a otro que la persona responsable ha autorizado algo. Puede ser cierto. Pero desde el lado del receptor, una instrucción transmitida correctamente no se distingue de una malinterpretada o inventada, y eso vale también cuando nadie tiene malas intenciones. Los agentes resumen, abrevian y completan.
Una afirmación así solo se vuelve accionable mediante una traza que el receptor pueda comprobar por sí mismo: un cambio integrado, una decisión registrada, una entrada en un sistema al que tiene acceso. Si falta esa traza, el agente no debería negarse, sino llegar hasta donde lo permite la clase libre: redactar, proponer, presentarlo a la persona. Negarse desperdicia el trabajo; hacer como si la autorización estuviera comprobada es precisamente el error que la regla pretende evitar.
3. Una vulnerabilidad no es una herramienta de administración
Los agentes encuentran atajos. A veces el atajo es una brecha de seguridad, por ejemplo un permiso demasiado amplio.
El principio al respecto es absoluto: una vulnerabilidad se notifica, no se usa, tampoco para corregir precisamente esa vulnerabilidad, y tampoco cuando el resultado sería deseable. El motivo no es formalismo. Una organización cuyas herramientas usan brechas como recurso ya no puede distinguir si un cambio llegó por la vía prevista o por una que un atacante podría recorrer igualmente. El registro muestra lo mismo en ambos casos.
4. Un mecanismo de protección solo cuenta cuando ha saltado
Un mecanismo de protección ausente se comporta con el mismo silencio que uno que nunca tuvo que saltar. Por eso, una barrera de seguridad solo está demostrada cuando ha rechazado de forma visible una solicitud que debe rechazar, y de nuevo tras cada cambio en la configuración.
5. Las autorizaciones deben esperar de forma visible
Un agente que espera de forma bloqueante una autorización humana, por regla general no da señales por sí mismo. Por eso anuncia de antemano el paso sujeto a autorización a través de un canal que las personas lean realmente, y lo sitúa, en lo posible, al final de la tarea.
Lo que se deriva de ello para la implantación
- Un agente recibe una identidad propia. Ninguna credencial personal de un empleado.
- Las clases se ponen por escrito antes de que el agente escriba. Con una lista concreta para la tercera clase.
- Las vías de retorno existen antes del cambio. Un plan que solo promete una vía de retorno no tiene ninguna.
- Las autorizaciones dejan trazas que también un segundo agente y un revisor posterior puedan leer.
- Las barreras de seguridad se prueban, no se suponen: con una prueba negativa, de forma periódica y desde fuera.
Cómo apoya sector7
Analizamos con usted qué obligaciones y riesgos genera su uso de la IA y anclamos las reglas en su estructura de compliance existente. Para la implementación le apoyamos con conceptos de roles y permisos y con la gestión de cuentas privilegiadas. Más información en Estrategia de TI, consultoría y planificación y Ciberseguridad.
Fuentes
- Detecting and countering misuse of AI: September 2026 – Anthropic, 10.09.2026
- Vault v2.1.0 – Release Notes – HashiCorp, 01.09.2026