Un TrustReceipt es un registro firmado del contexto y de la decisión que Trusteed registró para una acción cubierta. Puede incluir referencias de transacción o pago cuando están disponibles. Por sí solo no demuestra intención del comprador, liquidación del pago ni que el hecho ocurriera, y no determina responsabilidades legales.
Corpus v1.0 existente · la emisión en producción está ENCENDIDA (`/api/v1/health` → `trust_receipts.issuing`) · lo que no genera recibo por defecto es el camino MCP autónomo · hardening v1.1 detrás de bandera.
Emitir un recibo no significa que se haya liquidado un pago. En la revisión del 2026-09-13, el registro público de comercios declaraba beta_closed, ningún comercio de producción y accepts_real_payments=false. Consulta /.well-known/merchant-index.json para conocer la disponibilidad actual; las demostraciones y vistas previas de checkout no acreditan compras reales.
Un Trust Receipt es un registro firmado de lo que un agente de IA hace en tu tienda y de lo que decidieron tus reglas. Cualquiera puede comprobarlo con herramientas estándar, y si alguien cambia un solo dato la firma deja de coincidir. Te ayuda a preparar disputas y auditorías; por sí solo no prueba el pago ni decide quién tiene razón.
Ejemplo ilustrativo · emitir un recibo no acredita un pago real.
Un agente de IA acaba de comprar en tu tienda. Lo hizo por encargo de un cliente; nadie de tu equipo estaba mirando.
¿Qué queda como prueba de esa compra? El registro del agente, en los servidores de otra empresa; tu tienda; la pasarela de pago; la logística. Trozos sueltos que no cuentan la historia completa.
Tres meses después llega una reclamación: «Yo no autoricé esta compra». Lo que tienes para responder es una fila en una base de datos, y una fila se puede editar sin dejar rastro.
Aquí entra el Trust Receipt: un registro firmado de lo que un agente hace en tu tienda y de lo que decidieron tus reglas.
Paso 1 · El agente pide comprar, con el encargo de su cliente: qué quiere, cuánto puede gastar y dónde enviarlo.
Paso 2 · Tus reglas deciden. Antes de cerrar la compra se comprueba contra las reglas que has configurado: permitida, bloqueada o pendiente de tu aprobación.
Paso 3 · Se genera el recibo y se firma. Lo que se pidió, lo que decidieron tus reglas y el resultado quedan registrados y sellados en el momento.
Paso 4 · Cualquiera puede comprobarlo: tu pasarela de pago, un auditor o tú mismo, con herramientas estándar y sin pedirnos permiso.
¿Y si alguien lo modifica después? Basta cambiar un solo dato para que la firma deje de encajar. Como un precinto: no impide abrir la caja, pero delata que alguien la abrió.
Qué ganas tú: disputas mejor preparadas, auditorías sin sufrir, menos trabajo a mano y control sobre los agentes.
Lo que un recibo hace: demuestra que el registro es auténtico y que nadie lo ha tocado desde que se firmó. Lo que no hace: no prueba por sí solo que el pago o el hecho ocurrieran. No decide quién tiene razón. Se emite en las operaciones y superficies donde está habilitado.
No te limites a guardar lo que hacen los agentes. Hazlo verificable.
La intención declarada por el agente, la decisión de tu política, el pedido creado y el resultado final viven en sistemas distintos: los registros del agente, tu tienda, tu proveedor de pagos, tu logística. Cuando llega una disputa, una devolución o una auditoría, rehacer esa traza a mano es lento y discutible.
Un log de aplicación se puede editar, truncar o perder sin que nadie lo note; no distingue una manipulación de la operación normal.
Un recibo firmado delata cualquier alteración: la verificación falla si cambió un solo byte.Saber qué agente actuó no dice qué entrada recibió, qué salida generó ni bajo qué política se decidió.
Cada recibo referencia el hash canónico de la entrada y la salida exactas de esa operación.Un proveedor de pagos, un tribunal y un auditor no consumen el mismo formato ni aplican el mismo criterio.
La postura legal de v1.1 está implementada, pero sigue detrás de bandera y pendiente de revisión jurídica externa.El recibo firma los hashes y el contexto capturados en una superficie cubierta. Refuerza la trazabilidad; no garantiza una defensa ni sustituye el resto del expediente.
Los cuerpos completos de entrada y salida nunca salen del almacén cifrado del comercio; el recibo sólo referencia su hash. Lo que se firma y se comparte es esto.
{ "id": "tr_01JY7E4M8XN3QF7A92F", "callId": "call_01JY7E4M79QK", "agentId": "urn:agent:demo-buyer-01", "merchantId": "demo-store", "bucket": "checkout", "tool": "complete_checkout", "inputHash": "sha256:4b8d…21f0", "outputHash": "sha256:9a11…77c2", "signingKeyKid": "trusteed-ed25519-2026-06", "jws": "eyJhbGciOiJFZERTQSJ9…", "jwksSnapshotUrl": ".well-known/jwks/2026-06.json", "schemaVersion": "1.0", "createdAt": "2026-07-27T10:14:32Z"}Para v1.0, obtén la clave pública de confianza del emisor en su JWKS y conserva el material de verificación. Verifica el JWS con la clave seleccionada por kid. Compara los hashes canónicos de entrada/salida sólo si dispones de los datos originales. El JWKS histórico embebido y la evidencia temporal adicional corresponden al hardening v1.1, aún condicionado por bandera; un recibo v1.0 no los garantiza.
La prueba sólo vale si le ahorra trabajo a alguien concreto en el momento en que la necesita.
Reduce la reconstrucción manual entre sistemas cuando la superficie ha emitido el recibo.
JWS compact Ed25519 estándar: criptografía pura, sin depender de un proveedor.
La clave que firmó viaja con el propio recibo, no sólo en un sistema de terceros.
Esta sección describe orientación técnica, no una certificación ni una opinión jurídica. La política de afirmaciones sigue pendiente de aprobación externa.
Aviso: un TrustReceipt es evidencia técnica verificable criptográficamente. No determina por sí mismo la responsabilidad legal. Su admisibilidad o su fuerza dependen de la legislación aplicable, de los acuerdos entre las partes y de otros hechos ajenos al formato.
Estas son las piezas implementadas o previstas. Su estado indica si pueden usarse hoy o siguen detrás de una condición de despliegue.
Sin una pieza así, cada disputa empieza reconstruyendo a mano qué pasó, cruzando los registros del agente, la tienda y el proveedor de pagos, y confiando en que nadie los tocó.
Cualquiera que lo reciba: tu proveedor de pagos, un auditor o tú mismo. La firma se comprueba con librerías JOSE estándar y la clave pública del emisor, sin pedir permiso a Trusteed. Verificar la firma acredita que el registro es auténtico, no que el pago se liquidara.
La verificación falla: basta cambiar un solo dato para que la firma deje de coincidir con el contenido. Funciona como un precinto: no impide tocar el registro, pero delata que alguien lo tocó.
No puede afirmarse de forma universal. Su admisibilidad y su fuerza dependen de la jurisdicción, el procedimiento, los acuerdos entre las partes y el resto de la evidencia.
No para verificar una firma JWS. Sí para cualquier afirmación de sello cualificado; esa capacidad no está disponible.
El corpus actual persiste el JWS y sus referencias. El encadenado por hash y los puntos de control están ARMADOS en producción (`TRUST_RECEIPT_CHAIN_ENABLED` puesta, con génesis declarada el 2026-08-06), pero no se presentan como capacidad operativa por una razón distinta a la de antes: los recibos anteriores a esa génesis no van encadenados, y no se ha contado cuántos posteriores sí. Se declara armado, no medido, y no se ofrece inmutabilidad de secuencia sobre todo el corpus.
La arquitectura contempla snapshots históricos y una lista de revocación firmada. El código está terminado, pero el despliegue y la sonda productiva deben confirmarse antes de depender de ellos.
Este recibo permite verificar fuera de Trusteed el contenido firmado que se conserva; no sustituye tu checkout, la evidencia del proveedor de pagos ni tu sistema de registro.