==============================================================================
  AGENTES DE IA NECESITAN IDENTIDAD PROPIA Y AÚN NO HAY ESTÁNDAR
==============================================================================

  Fuente:      https://www.vantis.cl/noticias/identidad-de-agentes-de-ia-estandares-emergentes-csa
  Publicado:   2026-10-08  (hora de Chile)
  Ambito:      global   ·   Criticidad: informativa
  Descargado:  2026-10-12 06:25  (hora de Chile)

  COMO USAR ESTE ARCHIVO
  ----------------------
  La regla SIGMA es la canonica: es el formato neutral del que se derivan
  las demas. Si tu SIEM no aparece aca, convierte esa con pySigma.

  Las traducciones a motores concretos se incluyen por conveniencia y
  ESTAN SIN VALIDAR CONTRA TU MODELO DE DATOS. Revisa los nombres de
  tabla, indice y campo antes de ponerlas en produccion. Una regla que
  no dispara por un campo mal escrito es peor que no tener regla.

  QUE 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

==============================================================================
  REGLA 1 de 3   ·   SIGMA (canonica, neutral)
  Posible reuso de token OAuth de agente MCP contra múltiples audiencias (violación de RFC 8707)
==============================================================================
  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.

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

==============================================================================
  REGLA 2 de 3   ·   MICROSOFT SENTINEL - KQL
  Un mismo token de agente MCP presentado contra más de una audiencia en 5 minutos
==============================================================================
  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.

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

==============================================================================
  REGLA 3 de 3   ·   SPLUNK - SPL
  Reuso de token de agente entre audiencias MCP distintas
==============================================================================
  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.

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

==============================================================================
  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.

==============================================================================
  Vantis Chile SpA  ·  https://www.vantis.cl/noticias
  Analisis con fines defensivos. Reutilizable citando la fuente.
==============================================================================