Notarized Agents: Receiver-Attested Confidential Receipts for AI Agent Actions

Resumen Técnico: Agentes Notarizados: Recibos Confidenciales Atestiguados por el Receptor para Acciones de Agentes de IA

Planteamiento del Problema

La observabilidad de los agentes de IA actuales está estructuralmente comprometida porque la entidad que produce el registro de actividad es la misma entidad cuya actividad está siendo registrada. En el modelo dominante (por ejemplo, Langfuse, LangSmith), las trazas se recolectan desde dentro del proceso del agente o de la infraestructura del operador. Esto crea un punto único de falla: si un agente es comprometido (mediante inyección de prompts, envenenamiento de contexto o código defectuoso) o si el operador tiene incentivos desalineados, las trazas pueden ser omitidas, alteradas o fabricadas. El agente no puede ser un narrador fiable de sus propias acciones, y el propietario no tiene una forma independiente de detectar la manipulación.

Las soluciones existentes no logran cumplir con un modelo de amenaza donde el adversario controla tanto al agente como a su operador. Un registro robusto de las acciones de un agente debe ser:

1. Inimitable por parte del agente o del operador.
   2.icamente verificable por el propietario utilizando infraestructura pública.
2. Confidencial para los operadores de la infraestructura pública.
3. Atribuible a una parte estructuralmente separada presente en el evento.
4. Recuperable incluso si el agente no está disponible.

Ningún sistema analizado ofrece las cinco propiedades.

Metodología: El Protocolo Sello

El artículo propone "Agentes Notarizados", una inversión arquitectónica inspirada en la notarización histórica y en sistemas modernos como la red Find My de Apple. En lugar de que el agente reporte sus acciones, los servicios que el agente llama actúan como testigos independientes.

Los autores instancian esta clase de protocolos como Sello, que combina cuatro propiedades definitorias:

• P1: Firma del lado del receptor: El servicio que recibe la llamada del agente firma el recibo utilizando su propia clave privada, no la del agente ni la del operador.
• P2: Cifrado HPKE hacia una clave vinculada al propietario: El recibo se cifra para la clave pública del propietario del agente. Crucialmente, esta clave pública está vinculada criptográficamente al token de autorización del agente mediante una declaración (claim) JWS, lo que evita ataques de sustitución.
• P3: Publicación en un registro Merkle con co-firma de testigos: Los recibos se anexan a un registro de transparencia público (por ejemplo, Sigstore Rekor) con co-firma de testigos para asegurar la evidencia de manipulación.
• P4: Descubrimiento por parte del propietario: El propietario consulta el registro utilizando una referencia derivada del token, descifra los recibos localmente y verifica las firmas contra un registro de identidad de servicios.

Flujo del Protocolo

1. Vinculación de Token: El agente presenta un token de autorización JWS que contiene una declaración con la clave pública HPKE del propietario (owner_hpke_pk).
2. Generación de Acción y Recibo: Al recibir una llamada, el servicio verifica el token, realiza la acción y construye un cuerpo de recibo (que contiene hashes de acción, estado y marcas de tiempo).
3. Cifrado y Firma: El servicio cifra el cuerpo para la owner_hpke_pk usando HPKE (X25519/KEM, ChaCha20-Poly1305). Luego firma el sobre cifrado usando COSE_Sign1 (Ed25519).
4. Registro: El sobre firmado se envía a un registro de transparencia. El registro devuelve una prueba de inclusión Merkle.
5. Verificación: El propietario consulta el registro usando SHA-256(token-bytes). Verifica la prueba Merkle, resuelve la clave pública del servicio a través de un registro, verifica la firma COSE y descifra la carga útil.

Mecanismos de Seguridad

• Revocación: El protocolo vincula las decisiones de revocación al tiempo integrado del registro de transparencia en lugar de a la marca de tiempo auto-asertada por el servicio. Esto evita que un servicio comprometido antedate los recibos para evadir la revocación.
• Protección contra Replay: Una regla de deduplicación del lado del propietario basada en una tupla de (kid, token_ref, timestamp, action hashes) detecta eventos replicados.
• Confidencialidad: El contenido del recibo se oculta a los operadores del registro y a los observadores de red mediante HPKE; solo es visible la metainformación (ID del servicio, referencia del token).

Contribuciones Clave

El artículo realiza cuatro contribuciones específicas:

1. Inversión Arquitectónica: Identificar la firma del lado del receptor como la solución estructural para la observabilidad de los agentes y definir las cuatro propiedades criptográficas (P1–P4) que distinguen a los protocolos notarizados.
2. Especificación de Sello: Un protocolo concreto que utiliza primitivas estándar (COSE_Sign1, HPKE, Ed25519, registros Merkle) y un perfil de token JWS novedoso que vincula la clave de cifrado del propietario al token de autorización.
3. Novedad de Vinculación Temporal: Proponer el uso del tiempo integrado del registro de transparencia para las decisiones de revocación de claves, separándolo de la marca de tiempo del cuerpo del recibo para mitigar ataques de antedatado.
4. Análisis Comparativo: Un análisis propiedad por propiedad que muestra que ningún sistema existente (Signet, AgentROA, Agent Passport System, etc.) combina las cuatro propiedades.

Resultados y Evaluación

Los autores proporcionan microbenchmarks de las operaciones criptográficas utilizando una implementación de referencia en un Apple M2.

• Sobrecarga (Overhead): Un servicio compatible con Sello añade aproximadamente 0.45 ms de trabajo de CPU mediano por llamada de agente (sello HPKE + firma + anexar al registro).
• Verificación: Un propietario que reconstruye la actividad realiza aproximadamente 0.28 ms de trabajo de CPU mediano por recibo (verificación de prueba, verificación de firma, descifrado).
• Tamaño de la Carga Útil: Un sobre Sello completo tiene aproximadamente 467 bytes (independiente del tamaño de la acción, ya que las entradas/salidas se pasan por hash).
• Escalabilidad: Un servicio que maneja 1,000 llamadas/segundo gastaría ~0.45 segundos de CPU por segundo en recibos. Un propietario puede reconstruir un día de actividad (100,000 recibos) en ~32 segundos de CPU utilizando verificación por lotes.

El artículo señala que la latencia de red para la sumisión al registro se excluye de estas mediciones y depende del operador específico del registro.

Limitaciones y Afirmaciones

El artículo es explícito sobre lo que Sello no resuelve:

• Ataque de Supresión: Si el agente simplemente no llama a los servicios, no se generan recibos. El propietario no puede distinguir entre "ninguna acción" y una "acción suprimida".
• Colusión de Servicios: Si un servicio colude con el operador para emitir recibos falsos, Sello no puede detectar esto a partir de un solo recibo.
• Incentivo de Adopción: Los servicios actualmente no tienen razones para emitir recibos. El artículo postula que la adopción requiere mandatos regulatorios (por ejemplo, la Ley de IA de la UE), el acoplamiento de liquidaciones o primas de confianza de mercado.
• Completitud del Conjunto: Sello proporciona verificabilidad por recibo pero no completitud criptográfica del conjunto. Un operador de registro podría teóricamente omitir recibos coincidentes sin ser detectado, a menos que se desplieguen mecanismos de completitud específicos (como resultados de consulta autenticados o auditorías completas del registro).

Significancia

El artículo argumenta que la significancia de Sello no reside en nuevas primitivas criptográficas, sino en la composición arquitectónica de las existentes para invertir el límite de confianza. Al desplazar la fuente de verdad del agente hacia los servicios independientes que este toca, Sello proporciona un rastro que es a la vez detectable, confidencial y verificable por el propietario, el cual sobrevive al compromiso del agente.

Los autores concluyen que, si bien el problema del incentivo de adopción sigue sin resolverse, el protocolo proporciona la precondición necesaria para una auditoría rigurosa de la IA. La tesis central es que "el agente no es el narrador adecuado de sus propias acciones; los servicios que toca lo son".