Resumen

  • GAR-07 apareció en el archivo de la IETF el 3 de septiembre de 2026. Datatracker lo identifica como borrador individual sin aval de la IETF, vía RFC, Area Director responsable ni posición formal en el proceso de estándares.
  • En GAR-06, la regla de firma externa se asignaba a R-3 y llamaba a esa clase fallo de integridad de atestación. MAD-03, la dependencia citada, define R-3 como falta de respuesta y solo enumera R-1 a R-7.
  • GAR-07 mueve la regla a R-8, amplía los campos de revocación hasta ocho clases y reserva para R-8 el evento que registra la reatestación de identidad del componente gobernante.
  • MAD-04, fechado el 4 de septiembre, incorpora R-8 para un mandato o credencial presuntamente comprometidos. Ordena revocación inmediata, reautorización humana y cascada total, pero también exige verificar el origen de la señal para evitar una revocación falsa.
  • La semántica vigente coincide; la cadena documental no. Un perfil reproducible debe fijar GAR-07 y MAD-04 juntos, conservar sus hashes y probar por separado R-3, R-8 válido y R-8 falsificado.

La prueba de recuperación no puede venir del acusado

El punto más sólido de GAR-06 no cambió: si el componente que gobierna y firma los registros puede haber sido comprometido, su propia firma no basta para probar la recuperación. El evento de reatestación debía recibir la firma de un servicio KIA externo.

Lo que fallaba era la ruta para llegar a ese evento. GAR-06 hablaba de R-3 como fallo de integridad de atestación. MAD-03, al que remitía normativamente, usa R-3 para Non-Response: la sesión dejó de responder a una señal de gobierno. Su tabla conoce siete clases, ninguna dedicada al compromiso.

La diferencia determina autoridad. Ante una falta de respuesta, el operador puede tener una vía de continuación. Ante una clave robada, la propia credencial que sostenía la autoridad está bajo sospecha. El mismo código no puede decidir ambas cosas sin convertir la auditoría en interpretación local.

El cambio coordinado en el texto público

La versión 07 de GAR, publicada el 3 de septiembre, sustituye R-3 por R-8 en el principio de firma externa, en el evento ALE_KIA_REATTESTATION_COMPLETED y en el párrafo que describe el riesgo de un componente comprometido que todavía firma. También extiende de seis a ocho clases los campos de revocación de sesión e hijo.

Así queda separado el objeto de la revisión de quien certifica el resultado. La prueba identifica al verificador externo y conserva su firma Ed25519, las atestaciones anterior y nueva, el hash de la política, la versión del núcleo y la duración del lapso. Las sesiones ejecutadas durante ese lapso deben quedar marcadas.

La corrección no blanquea toda la historia. El propio GAR admite que un componente comprometido podría haber producido registros falsos válidamente firmados. La firma externa protege el hito de recuperación, no demuestra que cada acción anterior fuera veraz. Esa limitación debe viajar con cualquier afirmación de conformidad.

El MAD-04 del día siguiente completa la taxonomía. Su nota editorial dice que R-8 cierra el hueco descubierto al comparar la lista con otro perfil que ya disponía del motivo compromise.

R-8 abarca la sospecha o confirmación de que un mandato o una credencial fueron comprometidos por un ataque externo. La lista incluye exposición de claves, robo de credenciales o un fallo de atestación que muestre una identidad de ejecución distinta de la atestada. No es R-1: allí el agente rebasa una prohibición; aquí el instrumento que le concede autoridad puede estar corrupto.

La respuesta no espera un punto natural. La sesión se detiene, nunca termina con estado limpio y no puede continuar sin autorización humana. No se reutiliza la clave afectada ni una derivada. La revocación alcanza a todos los descendientes y anula sus registros de composición y referencias efímeras, porque su legitimidad dependía del mandato raíz.

MAD-04 añade una cautela decisiva. Una señal falsa de compromiso puede convertirse en ataque de denegación de servicio. Antes de cerrar el árbol, el componente debe comprobar la autenticidad e integridad del aviso con las claves de la autoridad emisora. El registro de COMPROMISE_REVOCATION conserva la fuente y, cuando existe, la referencia de atestación concreta.

La referencia quedó un día atrás

Quien visite hoy las páginas de GAR y MAD verá las revisiones 07 y 04. En ese par, R-8 tiene definición, consecuencias y firma. Pero la bibliografía normativa dentro de GAR-07 aún especifica draft-sato-soos-mad-03.

La secuencia temporal ofrece una explicación posible, no una conclusión: GAR-07 tiene fecha 3 de septiembre y MAD-04, 4 de septiembre. No hay base pública para atribuir intención. Sí hay base para distinguir dos procedimientos. Resolver el nombre activo lleva a MAD-04; reproducir la cita exacta lleva a MAD-03, donde R-8 es imposible.

En documentación corriente, una referencia móvil mantiene al lector al día. En auditoría, puede reescribir el pasado. Una declaración genérica de soporte cambia de contenido cada vez que el alias avanza. Una declaración fijada solo a GAR-07 queda incompleta porque su dependencia fijada no aporta la clase requerida.

El recibo mínimo que falta

No hace falta otra capa institucional. Basta un recibo que una revisión y hash de GAR, revisión y hash de MAD, motivo original, código R, clave que autenticó la señal, alcance del árbol, estado parcial, decisión humana, verificador externo y evento de restauración.

La batería debe buscar fallos. Un R-3 auténtico no debe activar la rama de compromiso. Un R-8 auténtico debe detener raíz y descendientes. Un R-8 falsificado debe rechazarse sin revocar autoridad. Una firma de recuperación emitida por el componente investigado, una clave heredada de la comprometida o un estado parcial abierto deben bloquear la restauración.

Cuando cambien los borradores, el nuevo recibo se añade. No borra el anterior. Así se preserva qué norma interpretó el sistema en el momento de actuar, aunque el documento vivo ya muestre otra revisión.

La idea de primacía del código en ejecución de Heng Lu funciona aquí como lente analítica. Publicar reglas no equivale a ejecutarlas. La especificación común mínima debe ser suficientemente estrecha para evitar poder innecesario y suficientemente precisa para que la validación local no bifurque el sentido.

Dos borradores, ninguna norma aprobada

Datatracker es inequívoco. GAR y MAD son Internet-Drafts individuales. Cualquiera puede presentar uno. No cuentan con respaldo de la IETF ni posición formal en su proceso; no tienen corriente RFC, patrocinador AD ni telechat.

La mención Standards Track en el encabezado expresa la intención del autor. No describe el estado institucional observado. Los textos pueden cambiar, ser sustituidos o caducar. Tampoco se halló evidencia pública de implementación, interoperabilidad, uso productivo, aceptación regulatoria o incidente real.

Por eso la noticia no es que la IETF haya regulado los agentes de IA. Es que dos documentos públicos hicieron coherente una decisión delicada y, al hacerlo, mostraron la fragilidad de una referencia sin versión actualizada. Para verificar quién tenía derecho a recuperar un sistema, hay que conservar también el texto exacto que otorgaba ese derecho.

Fuentes

  1. Anuncio del archivo IETF sobre GAR-07
  2. Datatracker — Governance Audit Record
  3. GAR-07
  4. GAR-06
  5. Comparación GAR-06/GAR-07
  6. Datatracker — Multi-Agent Delegation
  7. MAD-04
  8. MAD-03
  9. Comparación MAD-03/MAD-04
  10. Heng Lu — Running-Code Primacy
  11. Heng Lu — especificación inicial mínima
  12. Heng Lu — realidad, no promoción