La evidencia de manipulación a escala significa tres garantías separables. Integridad: cada artefacto en una exportación tiene un valor hash al valor con el que se comprometió un manifiesto firmado. Integridad: la colección que produjo la exportación cubría su población declarada o se negaba a sellar. Verificabilidad independiente: un revisor externo puede volver a ejecutar las comprobaciones de integridad del paquete solo, sin conexión, y ver el límite exacto de lo que prueban esas comprobaciones. Esta publicación explica cómo el canal de evidencia enviado por KLA implementa cada garantía, desde la recopilación paginada de un libro mayor de solo anexo hasta el sellado, el anclaje y la verificación fuera de línea.
Pistas de auditoría del agente de IA explica por qué los registros de ejecución necesitan esta capa de evidencia y qué contiene conceptualmente un paquete de evidencia. Este compañero permanece en la sala de máquinas: construcción de hash, formatos de firma, invariantes de paginación y los modos de falla que cierra cada uno.
Qué significa estar listo para auditoría una vez que el libro mayor es grande
Cada acción gobernada en KLA aterriza en un libro de contabilidad immudb por inquilino y de solo anexos: entradas de auditoría, decisiones de políticas, evaluaciones de puertas, instantáneas de paquetes de políticas y recibos de gobernanza firmados. En un inquilino ocupado, ese libro crece sin límites y llega una solicitud de exportación con un alcance: una ejecución, una decisión, una política o una ventana de auditoría completa.
En volúmenes pequeños, una exportación es una consulta más un archivo. A gran volumen, aparecen tres modos de falla silenciosos. Un límite de escaneo del lado del servidor trunca un conjunto de resultados sin error. En una colección de larga duración, las escrituras pasan rápidamente por su cursor. Una exportación parcial parece idéntica a una completa, porque la ausencia no deja ningún artefacto.
La respuesta de diseño es tratar la integridad como una propiedad de primera clase y comprobable de la colección, y la integridad como una propiedad de primera clase y comprobable de la salida sellada. Los dos se aplican mediante mecanismos diferentes y se verifican mediante controles diferentes, y el resto de esta publicación los mantiene separados.
| Garantizar | Pregunta que responde | Aplicado por | Comprobado por |
|---|---|---|---|
| Integridad | ¿Son estos bytes los bytes que fueron sellados? | Resúmenes SHA-256, raíz de Merkle, firmas duales ES256 sobre un manifiesto canónico | Verificador fuera de línea: firma de manifiesto, inclusión de merkle |
| Lo completo | ¿La recaudación cubrió a la población declarada? | Paginación verificada por el cursor que no se cierra ante cualquier infracción de cobertura | Errores en el momento de la recolección; conectividad de gráfico hash; eslabones de la cadena de recibos |
| Verificabilidad independiente | ¿Puede un revisor confirmar esto sin confiar en la infraestructura de KLA? | Material de verificación incluido en el paquete: claves, pruebas, anclajes. | La CLI @kla/evidence-verifier se ejecuta sin conexión en el directorio del paquete |
El paquete en disco
Un paquete de pruebas selladas es un archivo zip con un diseño fijo. Todo lo que un verificador necesita viaja en su interior: el manifiesto, la firma separada, las claves públicas, ambas pruebas de anclaje y los propios artefactos.
El manifiesto registra la identidad y el alcance de la exportación, el principal solicitante, las instantáneas de la política con sus hashes de paquete, la lista completa de artefactos con resúmenes y tamaños SHA-256 por archivo, la raíz de Merkle sobre esa lista, el perfil de redacción, las omisiones declaradas y un bloque de integridad que nombra los algoritmos de hash y firma y el conjunto de anclajes.
<bundle-dir>/
bundle.json seal summary: digests, signer set, anchor references
manifest.json full manifest: population, artifacts, integrity block
manifest.jws.json detached ES256 JWS over the manifest digest
keys/jwks.json public verification keys embedded for offline use
timestamp.ots OpenTimestamps proof over the manifest digest
ledger_anchor.json immudb anchor record for the sealed digest
artifacts/
exports/... exported evidence files
index/artifact_index.jsonSellado: bytes canónicos, un resumen, dos firmas
Firmar JSON de forma segura requiere una representación estable en bytes. El exportador canonicaliza el manifiesto con JSON canónico estilo JCS (RFC 8785): claves ordenadas por punto de código, sin valores indefinidos, sin números no finitos. Los campos que solo se pueden completar después de la firma, como el hash del manifiesto en sí y el hash del valor del ancla del libro mayor, se borran antes de la digestión para que los bytes confirmados estén bien definidos. El SHA-256 de esos bytes canónicos es el resumen manifiesto y cada compromiso posterior se vincula a él.
Se requieren dos firmas sobre ese resumen, producidas como un JWS ES256 independiente. La clave del entorno de servicio (SEK) afirma qué entorno KLA selló el paquete. La clave de evidencia del inquilino (TEK) vincula el sello a un inquilino; su ID de clave lleva el identificador del inquilino. El exportador exige que las dos claves sean distintas y, en producción, ambas residen en HashiCorp Vault Transit como claves ECDSA P-256 no exportables, por lo que la firma se realiza dentro de Vault y el material privado nunca llega al proceso del exportador.
La integridad del artefacto utiliza una construcción Merkle dedicada, kla-merkle-v1. Cada hoja codifica un byte de separación de dominio, la ruta del artefacto y el resumen del artefacto; la lista de hojas está ordenada por bytes de ruta; los nodos internos tienen un prefijo distinto sobre sus hijos. El manifiesto sella la raíz y el paquete incluye una prueba de inclusión por artefacto, por lo que un revisor puede confirmar que un solo archivo pertenece al conjunto sellado sin tener que repetir todo el archivo.
Los recibos de gobierno llegan en el paquete ya firmado. Durante una ejecución regulada, cada paso sella un recibo firmado con ed25519 cuyo contenido incluye prevReceiptHash, la dirección de contenido del recibo anterior. El hash vive dentro de la carga útil firmada, por lo que la firma cubre el eslabón de la cadena. Las entradas de auditoría llevan una segunda cadena de hash a nivel de aplicación: cada registro almacena el hash de su predecesor, calculado en el momento de la escritura con el último hash del libro mayor del inquilino.
{
"bundleSpec": "evidence-room-bundle-v1",
"manifestDigestSha256": "4b7f0e0d2b9a51c6f3e8d1a07c5b2e94a6d803f1c2e75b09d4a1f6c8e3b25a70",
"merkleRootSha256": "a1c9f2d84e07b6531f8c0d2ae95b47c6d310e8f2a7c54b90e6d1a3f8c2b7e415",
"artifactCount": 214,
"requiredSigners": [
"sek",
"tek"
],
"timestamping": {
"type": "opentimestamps-bitcoin-mainnet",
"receiptPath": "timestamp.ots"
},
"ledger": {
"type": "immudb",
"anchorPath": "ledger_anchor.json"
}
}Anclaje del sello fuera del sistema
Una firma prueba quién selló el manifiesto. Anclajes atados cuando, y registrar el sello en sistemas que el exportador no controla a posteriori.
El primer ancla es una prueba de OpenTimestamps sobre el resumen del manifiesto, comprometido con la cadena de bloques de Bitcoin. El sellado de tiempo está cerrado a prueba de fallas: una exportación con el sello de tiempo deshabilitado o un sello fallido se niega a sellar, y una implementación puede requerir además que la prueba esté certificada por Bitcoin antes de que se complete la exportación.
El segundo ancla vuelve a escribir el resumen del manifiesto en el libro mayor de immudb con una clave derivada del inquilino y los ID de exportación, mediante una escritura verificable. El registro ancla en el paquete lleva el ID de la transacción y la prueba de la transacción del servidor, y el verificador fuera de línea luego verifica que la prueba realmente vincule esa clave y valor a esa transacción. Si la escritura del ancla falla, la exportación falla.
Los fallos de anclaje y de evidencia nunca enmascaran una acción ejecutada. Una ruta de escritura degradada se registra como degradada y un paquete sellado que no pudo obtener un anclaje requerido es un estado de error con un motivo determinado.
Colección bajo carga: paginación como protocolo verificado
El servidor immudb limita el escaneo de prefijos a 1000 entradas por página. Un ingenuo escaneo sin paginar de un gran libro de contabilidad de inquilinos se trunca silenciosamente, lo que constituye el peor fallo posible para la evidencia: un paquete plausible al que le falta la cola. Por lo tanto, el recopilador trata la paginación como un protocolo con invariantes y cada violación de invariantes cancela la exportación con un IncompleteLedgerCoverageError.
Cada página se solicita con una clave de búsqueda explícita, la última clave entregada por la página anterior. Las páginas pasan por un controlador a medida que llegan; nada se acumula ilimitadamente en la memoria. Un escaneo finaliza solo cuando una página no alcanza el límite o se pasa el final del rango configurado, y cada página se verifica antes de que sus filas cuenten como cubiertas.
Para escaneos amplios y de gran volumen, los cuerpos de registros candidatos se transfieren al disco como JSON delimitado por nuevas líneas durante el escaneo y se rehidratan más tarde en lotes limitados bajo un presupuesto ponderado por bytes, manteniendo como máximo una página de cuerpos de tamaño máximo en la memoria a la vez. Presupuestos fijos de lecturas limitadas, bytes, simultaneidad y tiempo de reloj de pared, incluida una fecha límite inactiva que se restablece una página en progreso verificada y una fecha límite absoluta que no se restablece nada. Llegar a un presupuesto es negarse a sellar, y el presupuesto se menciona en el error.
- Página de gran tamaño: una página con más filas de las solicitadas cancela el escaneo.
- Fila sin clave: cada fila debe llevar la clave de la que depende la paginación.
- Clave fuera del prefijo: una clave devuelta fuera del prefijo escaneado se cancela.
- Clave regresiva: las claves deben avanzar estrictamente en orden de bytes entre las páginas.
- Clave duplicada: una clave vista dos veces en un escaneo se cancela.
- Cursor que no avanza: una página incompleta cuya última tecla no logra mover la posición de búsqueda se cancela, cerrando los casos de bucle infinito y truncamiento silencioso a la vez.
Afirmar que está completo al final
Sobrevivir a la exploración es necesario e insuficiente. Cuando finaliza una colección de alcance, el recopilador afirma que cada selector solicitado (ID de ejecución, ID de registro de linaje, ID de solicitud de decisión, ID de política, marcos, controles) fue realmente satisfecho por las entradas recopiladas y aborta con los selectores faltantes enumerados si alguno no lo fue.
Cada entrada recopilada también debe llevar una certificación de confianza: proviene de la fuente immudb, la respuesta del servidor se verifica con el estado de confianza mantenido localmente y la prueba de inclusión se verifica con la raíz de la respuesta. Las entradas que no cumplen con ese predicado se excluyen y se registran como omisiones con un código de motivo estable en lugar de exportarse como si fueran confiables. Luego, el manifiesto informa la cobertura por sección como completa, parcial, faltante o no aplicable, con razones para cualquier cosa que no esté completa.
Dos controles estructurales cierran los casos que la paginación no puede ver. El gráfico hash de auditoría debe estar conectado: debido a que los escritores concurrentes pueden competir con el último puntero hash, el libro de contabilidad forma un gráfico acíclico dirigido en lugar de una línea estricta, y el verificador requiere exactamente una raíz; una segunda raíz significa que falta un miembro en la exportación o que existe una segunda génesis. Las cadenas de recibos verifican sus enlaces prevReceiptHash desde el origen hasta el final; una cadena no puede detectar el truncamiento en su extremo solo a partir de los enlaces, por lo que la integridad está en el contrato de la persona que llama, y el verificador acepta un hash de terminal esperado para cerrar esa brecha final cuando la persona que llama tiene uno.
| Mecanismo | Modo de falla cerrado | Resultado de la infracción |
|---|---|---|
| Paginación verificada por cursor | Truncamiento del lado del servidor, páginas omitidas o repetidas | Error de cobertura del libro mayor incompleto; la exportación se cancela |
| Aserción del selector de fin de escaneo | Un registro solicitado silenciosamente ausente del escaneo del libro mayor | Error al enumerar todos los selectores insatisfechos |
| Predicado de confianza de certificación | Una respuesta del servidor falsificada o no verificada que ingresa al paquete | Entrada omitida con un código de motivo estable |
| Conectividad de gráfico hash (raíz única) | Un miembro eliminado de la mitad del libro mayor exportado | La comprobación de la cadena de hash del libro mayor falla sin conexión |
| Enlaces de cadena de recibos + hash de terminal esperado | Una ejecución gobernada truncada a mitad de camino o al final | la verificación de firmas de recibos falla sin conexión |
Verificación independiente: lo que realmente ejecuta un auditor
El paquete @kla/evidence-verifier incluye una CLI que toma un directorio de paquete y vuelve a ejecutar las comprobaciones de integridad sin conexión, solo desde el contenido del paquete, sin ningún servicio KLA en el bucle. Cada verificación informa que se aprueba o falla con sus propios errores, y el proceso sale de un valor distinto de cero en caso de falla, por lo que la ejecución cae directamente en un script o un trabajo de CI. Un modo JSON emite el resultado completo legible por máquina. Una verificación opcional barre el paquete en busca de marcadores prohibidos proporcionados por la persona que llama, reportando coincidencias solo como prefijos hash.
$ evidence-verifier ./export-2026-08 --json > result.json
$ evidence-verifier ./export-2026-08
Evidence bundle: ./export-2026-08
PASS manifest-signature SEK and TEK ES256 signatures verify over the manifest digest
PASS receipt-signatures 41 receipt chains verify from genesis to last
PASS ledger-hash-chain 1,842 ledger records recompute; hash graph resolves to one root
PASS merkle-inclusion 214 artifacts match their digests and inclusion proofs
PASS ots-anchor timestamp.ots commits to the manifest digest
Result: PASS (5/5 checks passed)| Controlar | lo que recalcula | lo que establece un pase |
|---|---|---|
| firma-manifiesto | Resumen manifiesto canónico; Firmas SEK y TEK ES256; Identidad del ancla del libro mayor, hash de valor y prueba de transacción. | Los bytes de manifiesto son los bytes firmados por ambas claves y la prueba de anclaje vincula el resumen sellado a una transacción del libro mayor. |
| firmas de recibos | Cada firma de recibo ed25519 sobre bytes de recibo canónicos; prevReceiptEnlaces Hash, génesis para durar | El recibo de cada paso gobernado es auténtico y el orden de ejecución es el orden firmado. |
| cadena-hash-del-libro mayor | El hash almacenado de cada registro del libro mayor; Conectividad gráfica en todo el conjunto exportado. | No se modificó ningún registro de auditoría exportado y no falta ningún miembro dentro del gráfico. |
| inclusión-merkle | Cada resumen y tamaño de artefacto; cada prueba de inclusión hasta la raíz de Merkle sellada | Cada archivo en el archivo es el archivo al que se comprometió el manifiesto, sin agregar ni sustituir ninguno. |
| ancla ots | El resumen comprometido de la prueba de OpenTimestamps contra el resumen del manifiesto recalculado | La prueba de marca de tiempo se compromete con este manifiesto exacto. |
Los límites establecidos de la prueba fuera de línea
Una historia de verificación honesta nombra sus límites, y los límites del verificador se establecen en su documentación y en la página [evidencia a prueba de manipulaciones] publicada (/tamper-proof-evidence).
La verificación fuera de línea demuestra la coherencia interna. Las claves públicas viajan dentro del paquete, por lo que vincularlas a KLA requiere fijarlas fuera de banda contra un conjunto de claves publicadas por KLA; sin ese paso, una falsificación desde cero con claves nuevas se autoverificaría. La certificación de Bitcoin dentro de la prueba de marca de tiempo tiene una altura de bloque que la verificación fuera de línea acepta como reclamo; confirmarlo o actualizar un recibo de calendario pendiente necesita la cadena en vivo. La prueba ancla de immudb vincula el resumen sellado a una transacción del libro mayor, y para confirmar la inclusión de esa transacción con el estado firmado del libro mayor se necesita una verificación en red.
Estos límites tienen forma de verificación en lugar de ser vagos: cada uno corresponde a una verificación específica que un auditor motivado puede realizar con la infraestructura pública, y ninguno de ellos debilita lo que la ejecución fuera de línea demuestra sobre los bytes en mano.
Caminos negativos: la suite de manipulación
El conjunto de pruebas del verificador construye un paquete de elementos válido y luego lo divide un byte a la vez, afirmando que cada superficie se vuelve roja exactamente como la marca correcta: un byte volteado en un archivo de evidencia falla en la inclusión de merkle; en una firma de recibo o cuerpo de recibo, firmas de recibo; en un registro del libro mayor o su hash almacenado, cadena-hash-libro mayor; en la raíz de Merkle sellada o en el resumen indicado, el control de precinto correspondiente; en la prueba de marca de tiempo, ots-anchor.
Los ataques con forma de firma están cubiertos junto con la manipulación de contenido: se rechaza una variante maleable de alta S de una firma ECDSA válida, al igual que una firma RSA válida presentada bajo un encabezado ES256 y cualquier firma que no sea exactamente la codificación P-1363 de 64 bytes. El comportamiento de cierre fallido tiene su propio conjunto: falta una prueba de marca de tiempo, faltan claves, falta un ancla del libro mayor, un recibo firmado por una clave revocada y una ruta de artefacto que escapa del directorio del paquete, y la ruta de escape se rechaza sin leer el archivo externo.
En el lado de la colección, las pruebas del exportador llevan el buscapersonas más allá del límite de escaneo del servidor, reproducen claves duplicadas y regresivas, fuerzan los presupuestos de bytes por encima de sus límites y afirman que las colecciones con alcance no se cierran cuando un rango no puede establecer una paginación completa. La maquinaria de completitud se ejerce como comportamiento bajo prueba, en las mismas rutas de código que recorren las exportaciones de producción.
Preguntas frecuentes
¿Qué contiene un paquete de pruebas sellado?
Un manifiesto que enumera el alcance de la exportación, las instantáneas de políticas y cada artefacto con su resumen SHA-256; un JWS ES256 independiente con firmas de servicio y de inquilinos sobre el resumen del manifiesto canónico; las claves públicas de verificación; una prueba de OpenTimestamps y un ancla del libro mayor de immudb sobre el mismo resumen; y los artefactos con una prueba de inclusión de Merkle cada uno.
¿Cómo demuestra la exportación integridad y no sólo integridad?
La integridad se aplica durante la recopilación: la paginación verificada por el cursor se cancela en cualquier página truncada, duplicada, de regresión o que no avanza; las afirmaciones de fin de escaneo requieren que se cumplan todos los selectores solicitados; y la salida sellada incluye controles estructurales (un gráfico hash de raíz única y cadenas de recibos firmadas) que fallan fuera de línea si se elimina a un miembro.
¿Puede un auditor verificar un paquete sin acceso a los sistemas KLA?
Sí. La CLI @kla/evidence-verifier vuelve a ejecutar las comprobaciones de la firma del manifiesto, la firma del recibo, la cadena de hash del libro mayor, la inclusión de Merkle y las comprobaciones del anclaje de la marca de tiempo fuera de línea solo desde el directorio del paquete y sale de un valor distinto de cero en caso de falla. Vincular las claves integradas a KLA requiere un paso fuera de banda: fijarlas en un conjunto de claves publicadas por KLA.
¿Qué pasa cuando la recaudación no puede cubrir a la población solicitada?
La exportación se niega a sellar. Las infracciones de cobertura generan un error al nombrar la invariante violada o los selectores insatisfechos, el agotamiento del presupuesto genera un error al nombrar el presupuesto y las entradas que carecen de una certificación confiable se omiten con un código de motivo estable registrado en el manifiesto.
¿Qué no puede establecer la verificación fuera de línea?
Tres cosas, cada una de las cuales se puede cerrar con un paso en red: procedencia de la clave (fijar las claves incrustadas en un conjunto publicado), la altura del bloque de atestación de Bitcoin (confirmar contra la cadena) y la inclusión del ancla immudb en el estado firmado del libro mayor (una verificación del libro mayor en red).
¿Por qué el libro de auditoría se verifica como un gráfico en lugar de una línea recta?
Los escritores simultáneos pueden competir con el último puntero hash, por lo que dos registros pueden hacer referencia legítimamente al mismo predecesor. Por lo tanto, el verificador verifica la conectividad: el hash predecesor de cada registro que no sea de génesis debe resolverse dentro de la exportación y el gráfico debe tener exactamente una raíz. Una segunda raíz significa que falta un miembro o que hay una segunda génesis.
Conclusiones clave
La auditoría lista a escala se descompone en mecanismos que fallan estrepitosamente: bytes canónicos bajo dos firmas, una raíz Merkle sobre cada artefacto, dos anclas independientes en el resumen sellado, paginación que trata cada violación de cobertura como una negativa a sellar y un verificador fuera de línea que vuelve a ejecutar las comprobaciones y nombra sus propios límites. Para la capa conceptual por encima de este canal, comience con pistas de auditoría del agente de IA y la definición del paquete de evidencia; Para evaluar un proceso de evidencia con respecto a estas propiedades, utilice la referencia lista de verificación del paquete de evidencia y registro de ejecución del agente de IA.