informativa research global

Agentes de IA necesitan identidad propia y aún no hay estándar

Un white paper de Cloud Security Alliance (CSA Labs) mapea cómo NIST, Singapur y proveedores como Microsoft y Okta están tratando de resolver, cada uno por su lado, el problema de que un agente de IA no es ni un usuario ni una cuenta de servicio.

·14 min de lectura ·Equipo Vantis
En 30 segundos
  • Cloud Security Alliance (CSA Labs) publicó un white paper que plantea una tesis simple: los agentes de IA autónomos no caben en el modelo de identidad no humana que usamos hace veinte años, porque son efímeros, delegan autoridad en cadenas de varios saltos y actúan sin que haya un humano presente en el momento de la decisión. Este análisis es una síntesis propia de Vantis sobre ese documento, no una traducción.
  • Durante 2026 se movieron en paralelo tres frentes que el paper documenta: estándares (NIST abrió su AI Agent Standards Initiative en febrero y el NCCoE evaluó OAuth 2.0/2.1, OIDC y SPIFFE/SPIRE para agentes), regulación voluntaria (Singapur recomienda un registro de agentes confiables y verificación humana para acciones de alto impacto), y producto comercial (Microsoft Entra Agent ID, Okta y Auth0 ya venden capas de identidad para agentes).
  • A nivel de protocolo se está consolidando un patrón de capas, no un ganador único: OAuth 2.1 para que un agente use herramientas vía Model Context Protocol, tarjetas de agente firmadas para que se descubran entre sí vía Agent2Agent, y atestación de carga de trabajo (SPIFFE/SPIRE) para confianza entre organizaciones sin infraestructura compartida.
  • Para una organización en Chile no existe hoy una obligación normativa específica sobre identidad de agentes. Pero si ya tienes Copilot Studio, agentes propios sobre MCP o cualquier framework agéntico en producción, el riesgo que describe el paper — un agente operando con una credencial compartida o sin registro — ya existe en tu ambiente, lo sepas o no.

Qué pasó

Cloud Security Alliance (CSA Labs) —que produce estas notas con un pipeline de síntesis automatizado, por lo que funciona como fuente derivada y no primaria— publicó el 16 de septiembre de 2026 un white paper que recopila el estado de la identidad de agentes de IA durante el último año. Los hechos que cita, con su fuente primaria:

Una investigación independiente citada en el paper (arXiv, inicios de 2026) concluyó que tanto MCP como A2A todavía carecen de un mecanismo nativo para verificar la procedencia completa de una acción delegada una vez que pasó por varios agentes. Ese es, en nuestra lectura, el punto más importante del documento: hay autenticación en cada salto, pero no una cadena de custodia verificable de principio a fin.

Por qué importa acá

Nada de esto viene con una alerta de ANCI ni con IOCs: es una pieza de postura, no de incidente. Pero conviene traducirla a términos locales porque la adopción de agentes ya está ocurriendo en empresas chilenas vía Microsoft Copilot Studio, Azure AI Foundry o integraciones propias sobre MCP, normalmente sin que el equipo de seguridad las haya inventariado como una clase de identidad separada.

Evaluación, confianza media: si una organización chilena calificada como Operador de Importancia Vital (OIV) bajo la Ley 21.663 despliega agentes con acceso a sistemas que la ley protege, y uno de esos agentes es comprometido vía suplantación o robo de token —exactamente el escenario que describe el paper—, en nuestra lectura ese incidente debería evaluarse bajo el mismo deber general de reporte que aplica a cualquier otro incidente de seguridad con impacto en el servicio. La alternativa que no podemos descartar es que, al tratarse de una identidad no humana interna y no de una falla del servicio esencial en sí, el incidente se gestione como un hallazgo interno sin umbral de reporte — depende del impacto real, no de la naturaleza del atacante. No existe hoy guía de ANCI específica sobre identidad de agentes; esta es una proyección nuestra, no una obligación confirmada.

Evaluación, confianza media: bajo la Ley 21.719, un agente que opera con delegación amplia sobre sistemas que contienen datos personales —por ejemplo, un agente de atención al cliente con acceso a una base de clientes— actúa, en los hechos, como un tercero procesando datos en nombre de la organización. Si ese agente usa una credencial compartida y no hay forma de atribuirle una acción específica, se pierde exactamente el tipo de trazabilidad que un DPIA exigiría poder mostrar. La alternativa que no descartamos es que el regulador trate esto, al menos en el corto plazo, como un problema de control interno y no como un hecho reportable per se.

Lo que sí es un hecho, no una evaluación: ninguno de los estándares candidatos —OAuth 2.1, SPIFFE/SPIRE, Agent2Agent— está terminado ni es obligatorio en ninguna jurisdicción, incluida Singapur, cuyo propio addendum se declara voluntario. Eso significa que cualquier control que se implemente hoy es una apuesta arquitectónica, no el cumplimiento de un estándar fijo. La recomendación del propio paper —y la que compartimos— es preferir decisiones que sean compatibles con varios estándares candidatos (credenciales de corta duración, scoping explícito, registros centralizados) antes que apostar temprano por un solo proveedor.

Anatomía del ataque

Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.

MITRE ATT&CKT1550.001Use Alternate Authentication Material: Application Access Token · Defense Evasion / Lateral MovementMAESTROcapa-agent-frameworkCapa de Framework de Agentes · -MAESTROcapa-agent-ecosystemCapa de Ecosistema de Agentes · -
Qué hacer, fase por fase

Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.

GV GobernarQuien decide, que se reporta y a quien

La identidad de agentes necesita un dueño explícito antes que una herramienta. En la mayoría de las organizaciones hoy nadie decide formalmente si un agente puede existir en producción con su propia identidad o si va a heredar la de un desarrollador. Esa decisión debería vivir en IAM o en el CISO, no en el equipo de datos que construyó el agente. Evaluación, confianza media: el compromiso de la identidad de un agente que opera sobre infraestructura calificada como servicio esencial probablemente activa el mismo deber general de reporte de incidentes de la Ley 21.663 que cualquier otro incidente de similar impacto — no hay guía específica de ANCI sobre este punto todavía.

  • Designar explícitamente quién gobierna la identidad de agentes de IA (IAM o CISO), separado de quién gobierna identidades humanas y cuentas de servicio
  • Prohibir como política que un agente pase a producción reutilizando una credencial humana o de cuenta de servicio existente
  • Definir con legal/compliance si un compromiso de identidad de agente activa el deber de reporte bajo Ley 21.663 cuando la organización es Operador de Importancia Vital
ID IdentificarSi esto me toca, por donde me toca

Antes de poder proteger nada hay que saber cuántos agentes existen. La mayoría de las organizaciones no tiene este inventario porque los agentes se crearon dentro de plataformas (Copilot Studio, Azure AI Foundry) o de frameworks propios (LangChain, AutoGen, CrewAI) sin pasar por el proceso de alta de identidades tradicional.

  • Levantar inventario de todo framework de agentes en uso: Copilot Studio, Azure AI Foundry, agentes propios sobre MCP, integraciones con Agent2Agent
  • Revisar en Entra ID / Azure AD cuántos service principals o app registrations corresponden en realidad a agentes y no a aplicaciones tradicionales
  • Identificar servidores MCP expuestos a internet o a terceros y verificar si corren con autorización OAuth deshabilitada (la especificación lo permite, pero elimina el control principal contra reuso de tokens)
PR ProtegerComo evito que ocurra

Los controles priorizados van en el bloque proteger.controles de esta pieza. La idea central: scoping explícito y vida corta por sobre credenciales anchas y permanentes, porque ningún estándar está terminado todavía y esa es la elección que sigue siendo válida se imponga el que se imponga.

  • Exigir OAuth 2.1 con PKCE y Resource Indicators (RFC 8707) en todo servidor MCP expuesto a agentes
  • Migrar cualquier agente detectado operando con credencial compartida a una identidad propia y acotada
  • Levantar un registro interno de agentes con dueño, herramientas permitidas y pares autorizados, equivalente al registro voluntario que recomienda el addendum de Singapur

Controles priorizados

P1: esta semana · P2: este mes · P3: este trimestre

PrioControlEsfuerzoMapeo
P1 Inventariar y registrar formalmente cada identidad de agente de IA en uso (incluidas las creadas implícitamente por frameworks que reutilizan credenciales de desarrollador) medio MITRE ATT&CK M1047 CIS Controls v8 5.1 ISO 27001 A.5.9
P1 Migrar todo agente que opera con credencial compartida o de cuenta de servicio a una identidad propia, única y acotada alto MITRE ATT&CK M1026 CIS Controls v8 5.4 ISO 27001 A.5.17
P1 Exigir OAuth 2.1 con PKCE y Resource Indicators (RFC 8707) en todo servidor MCP expuesto a agentes, propios o de terceros medio MITRE ATT&CK M1018 CIS Controls v8 3.10 ISO 27001 A.8.24
P2 Levantar un registro interno de agentes con dueño, herramientas permitidas y pares autorizados, equivalente al registro voluntario que recomienda el addendum de Singapur medio MITRE ATT&CK M1047 CIS Controls v8 5.1 ISO 27001 A.5.16
P2 Exigir verificación humana antes de que un agente ejecute una acción de alto impacto: modificar datos persistentes, acceder a sistemas externos o desplegar cambios medio MITRE ATT&CK M1018 CIS Controls v8 6.8 ISO 27001 A.8.2
P2 Monitorear la telemetría de identidades de agente como clase separada de usuarios y cuentas de servicio en el SIEM bajo MITRE ATT&CK M1047 CIS Controls v8 8.2 ISO 27001 A.8.15
P3 Para agentes que operan íntegramente dentro de infraestructura propia, migrar de secretos estáticos a credenciales de corta duración con rotación automática (SPIFFE/SPIRE o equivalente) alto MITRE ATT&CK M1026 CIS Controls v8 16.9 ISO 27001 A.8.24

Ninguno de estos controles depende de que un estándar específico gane. Scoping, vida corta y registro centralizado son compatibles con OAuth 2.1, SPIFFE/SPIRE o el enfoque de Entra Agent ID a la vez — que es exactamente el motivo por el que el paper los recomienda como punto de partida mientras el panorama de estándares sigue abierto.

DE DetectarComo me doy cuenta de que ya ocurrio

No existen IOCs públicos para este tema porque no es una campaña ni una vulnerabilidad: es una brecha de diseño que recién se está estandarizando. La detección tiene que ser conductual, sobre los logs de autorización del propio agente o del gateway que lo expone, y hoy es experimental porque todavía no hay una base amplia de incidentes reales contra la cual calibrar umbrales.

  • Centralizar los logs de autorización de todo servidor MCP (propio o de terceros) en el SIEM antes de intentar cualquier regla de detección
  • Tratar las identidades de agente (Entra Agent ID, service principals de agente) como una clase de telemetría separada de usuarios y cuentas de servicio en los dashboards de IAM
  • Pilotear las reglas de este artículo en modo de solo alerta (no bloqueo) durante al menos cuatro semanas antes de subirles severidad

Qué necesitas tener logueado

  • Logs de autorización del servidor MCP (propio o vía API Management/reverse proxy que lo expone)
  • Entra ID / AAD Service Principal y Managed Identity Sign-in Logs, para identidades de agente tipo Entra Agent ID
  • Logs del Authorization Server OAuth (jti, aud, exp) si se opera uno propio
  • Okta System Log, cuando el servidor MCP corre sobre Okta/Auth0

Reglas y consultas de detección

sigmaPosible reuso de token OAuth de agente MCP contra múltiples audiencias (violación de RFC 8707) 
title: Posible reuso de token OAuth MCP contra múltiples audiencias (RFC 8707)
id: a47e2d91-6c3f-4b8a-9e15-2f8d6c4a7b02
status: experimental
description: Detecta un mismo identificador de token (jti) presentado como válido ante más de una audiencia (servidor de recursos MCP) en una ventana corta, lo que viola el aislamiento de audiencia exigido por Resource Indicators (RFC 8707) y puede indicar robo o reuso indebido de un token de agente.
references:
  - https://labs.cloudsecurityalliance.org/research/csa-slack-20260916-225950-csa-styled/
logsource:
  category: application
  product: oauth_authorization_server
detection:
  selection:
    event.action: 'token_validated'
  timeframe: 5m
  condition: selection | count(distinct resource_audience) by token_jti > 1
falsepositives:
  - Balanceadores de carga o gateways que reenvían el mismo token a réplicas del mismo servidor MCP (misma audiencia lógica, distinto host)
  - Migraciones de endpoint de un servidor MCP donde el mismo recurso cambia de dirección sin reemitir tokens
level: high
tags:
  - attack.t1550.001
  - attack.defense-evasion
Requiere: Logs de autorización del servidor de autorización OAuth con los campos token jti, audiencia del recurso y resultado de validación. Si no se opera un Authorization Server propio, extraer estos campos del API Management o reverse proxy que expone el servidor MCP.
sentinel-kqlUn mismo token de agente MCP presentado contra más de una audiencia en 5 minutos 
MCPAuthorizationLogs_CL
| where TimeGenerated > ago(1h)
| summarize AudienceCount = dcount(ResourceAudience_s), Audiences = make_set(ResourceAudience_s) by TokenJti_s, bin(TimeGenerated, 5m)
| where AudienceCount > 1
| project TimeGenerated, TokenJti_s, AudienceCount, Audiences
Requiere: Tabla personalizada MCPAuthorizationLogs_CL en Sentinel, con los campos TokenJti_s y ResourceAudience_s, alimentada desde los logs de autorización del servidor MCP o del API Management que lo expone. No existe tabla nativa de Microsoft para este dato todavía.
splunkReuso de token de agente entre audiencias MCP distintas 
index=mcp_auth sourcetype=mcp:authorization
| stats dc(resource_audience) as audience_count values(resource_audience) as audiences by token_jti, _time span=5m
| where audience_count > 1
Requiere: Index mcp_auth con eventos de autorización del servidor MCP ingestados vía HEC o Universal Forwarder, con campos token_jti y resource_audience extraídos en el sourcetype mcp:authorization.
Falsos positivos esperables

Un gateway o balanceador de carga que reenvía el mismo token a réplicas del mismo servidor lógico generará el mismo falso positivo que un reuso malicioso: ambos muestran el mismo jti contra más de un host. Hay que normalizar por audiencia lógica (el recurso, no el host físico) antes de alertar. También puede ocurrir en migraciones de endpoint donde el recurso cambia de dirección sin reemitir tokens. Esta regla es experimental: no existe hoy un corpus público de incidentes reales contra el cual calibrar el umbral de 5 minutos, así que debe correr en modo de solo alerta antes de usarse para bloqueo.

RS ResponderContencion y erradicacion

Si se confirma que un agente fue suplantado o que su token fue reutilizado contra un recurso no autorizado, la contención tiene que ser quirúrgica: revocar solo la identidad de ese agente, no la de toda la flota, y reconstruir la cadena de delegación para saber qué otros agentes confiaron en él.

  • Revocar y rotar de inmediato únicamente la credencial del agente comprometido
  • Reconstruir la cadena de delegación para identificar qué otros agentes o herramientas confiaron en el agente comprometido y pudieron heredar su acceso
  • Retirar el Agent Card o el registro del agente del catálogo interno mientras dure la investigación
  • Revisar en los logs de autorización qué recursos (audiencias) recibieron tokens de ese agente en las últimas 72 horas
RC RecuperarVolver a operar y no repetirlo

La recuperación correcta no es reactivar la identidad comprometida: es emitir una nueva, más acotada que la anterior, y usar el incidente para corregir el registro y las políticas de alta de agentes.

  • Emitir una identidad nueva y con permisos más acotados para el agente en lugar de reactivar la comprometida
  • Confirmar junto al equipo de datos que no se modificaron registros persistentes durante la ventana de compromiso
  • Actualizar el registro interno de agentes y la política de alta con la causa raíz específica del incidente

Llévatelo

Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.

Una página · PDF Qué hacer esta semana 3 controles de prioridad 1, con checkbox. Para imprimir y llevar a la reunión del lunes. Reglas · TXT Reglas de detección 3 reglas listas para pegar — Sigma, Sentinel, Splunk.

La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.

Fuentes

¿Esto te aplica y no sabes por dónde partir?

Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.

Agendar diagnóstico

Relacionado

research

Exploit público para AnyDesk Linux otorga acceso root sin autenticación

La corrección llegó en junio camuflada como un simple arreglo de estabilidad, sin CVE ni aviso formal. El exploit public…

11-10-2026
research

Herramienta de pentest agéntico ARTEX golpeó bancos surcoreanos

Un operador no estatal combinó una herramienta de pentesting open source con varios LLM comerciales para atacar bancos s…

10-10-2026
research

Ataques a registros ccTLD obtienen certificados TLS válidos para Google

Compromisos confirmados en los registros de .gh, .sl y .as permitieron emitir certificados HTTPS legítimos mediante DNS…

09-10-2026