Resumen

  • La revisión 01 de GRP comprueba si el par (publisher_id, event_id) ya fue admitido durante la sesión, después de validar emisor y nonce pero antes de evaluar impacto.
  • La copia se registra como ALE-064 / duplicate_event_id y se descarta como operación nula para no duplicar reintentos, alternativas ni peticiones de intervención humana.
  • El conjunto de pares admitidos pasa a ser estado de control y exige respuestas operativas sobre persistencia, concurrencia, recuperación y cierre de sesión.

Todo era válido salvo la novedad

Imaginemos que un publicador autorizado anuncia la caída de una dependencia. El mensaje incluye componente, gravedad y hora; la firma corresponde a la clave registrada; el nonce coincide con la sesión activa. El receptor evalúa la situación y activa un proveedor alternativo. Por una pérdida de confirmación, el sistema de entrega vuelve a enviar el mismo objeto y otra instancia lo recoge.

El segundo mensaje no está falsificado. Es precisamente su autenticidad la que lo hace peligroso si el receptor carece de memoria. La firma vuelve a verificar, el nonce sigue siendo correcto y la marca temporal permanece intacta. Ninguna de esas afirmaciones responde a si la combinación concreta ya obtuvo admisión y produjo consecuencias.

La revisión 01 de The Governed Remediation Protocol (GRP) for Agentic AI Systems incorpora ese paso. Se trata de un Internet-Draft individual activo. Aunque el texto expresa la intención de seguir Standards Track, eso no constituye aprobación, consenso ni garantía de implantación por parte del IETF. La noticia está en el diseño propuesto y en su cambio respecto de la revisión 00.

Los eventos de cambio de GRP describen alteraciones de dependencias, recursos o mandatos que afectan a una sesión de agente. Entre los campos obligatorios figuran event_id, publisher_id, tipo y firma del publicador, session_nonce, hora, clase de cambio, componente afectado y gravedad. Cada identificador debe ser globalmente único dentro del flujo del publicador.

La versión inicial ya distinguía tipos de publicador y exigía verificar su autoridad y firma. También rechazaba el nonce que no coincidiera con la sesión. Sin embargo, el propio nonce permanece constante durante ella. Por eso puede identificar el contexto sin servir de contador de un solo uso.

El control nuevo está antes de la consecuencia

El receptor debe consultar si (publisher_id, event_id) ya consta como admitido en la sesión actual. En caso afirmativo, genera el motivo duplicate_event_id bajo ALE-064 y desecha el evento antes de repetir el análisis de impacto o cualquier acción correctiva. La primera admisión ya dejó su registro y desencadenó la respuesta correspondiente; la segunda debe ser una operación realmente nula.

Usar el par evita una simplificación indebida. event_id es único dentro del flujo de un publicador, no necesariamente un nombre universal separado de su origen. Primero se decide quién está autorizado a publicar. Después, si el evento pertenece a la sesión. Por último, si ese evento de ese publicador ya atravesó el límite. Son tres hechos diferentes.

La posición anterior al análisis es la parte política del mecanismo. Si la plataforma detecta el duplicado después de llamar al proveedor alternativo o de escalar a una persona, ya no lo ha neutralizado; solamente lo ha contado. El registro de primera admisión controla cuándo una declaración auténtica adquiere poder operativo.

El borrador separa este ataque de un bucle de remediación. Para el replay basta capturar un evento válido y reenviarlo. En el bucle aparecen fallos transitorios nuevos de forma repetida. Un filtro exacto detiene la misma identidad de evento, pero no puede resolver por sí solo si varias alertas nuevas representan una única causa persistente.

Las normas de firma no guardan el historial

RFC 7515 ofrece el formato de firma JWS y RFC 7517 el de claves JWK. El perfil TLS 1.3 citado cubre el transporte. Estas piezas pueden proteger bytes, claves y canal. No almacenan el historial de admisiones de un receptor ni deciden qué consecuencia corresponde a un evento.

El error de arquitectura consiste en convertir una respuesta correcta en una autoridad universal. «Firma válida» habla de integridad bajo una clave; «nonce correcto» habla de asociación con la sesión; «fecha firmada» habla de una afirmación temporal. «Primera admisión» exige comparar con estado autoritativo. La claridad aparece cuando cada prueba se limita a su propia capa.

También queda un riesgo fuera del control. Quien comprometa la clave del publicador puede firmar eventos nuevos con identificadores frescos. No coincidirán con un par anterior. La deduplicación evita repetir una copia capturada, pero no sanea una fuente que ahora es hostil.

De una línea normativa a una disciplina operativa

La revisión indica que el conjunto debe mantenerse durante la sesión actual. En el texto revisado no se detallan la persistencia tras un fallo, la sincronización entre nodos, la eliminación al cerrar la sesión ni la atomicidad entre admisión y primera remediación. Son preguntas que una implementación debe responder; su ausencia no demuestra por sí sola que la propuesta sea defectuosa.

Una tabla volátil puede olvidar tras reiniciar. Dos receptores aislados pueden admitir simultáneamente la misma pareja. Si el sistema graba primero y cae antes de actuar, necesita reanudar sin duplicar. Si actúa y graba después, la ventana ya permite dos efectos. La recuperación forma parte del límite de seguridad, aunque el mensaje original esté perfectamente firmado.

La evidencia consultada acredita el contenido y el historial del borrador. No acredita código en producción, pruebas independientes, interoperabilidad, incidentes, ataques ni tasas de éxito. Los identificadores de auditoría y los roles son lenguaje de una propuesta, no observaciones sobre una red instalada.

Fuentes