Piloto gobernado de 4 semanas: lleve un flujo de trabajo real a producción controlada
KLA Control Plane
KLA
Investigación

Suite de pruebas de capacidades de gobernanza de agentes de IA en tiempo de ejecución

Las afirmaciones de los proveedores sobre la gobernanza en tiempo de ejecución son fáciles de escribir y costosas de comprobar. Esta página publica la suite que KLA utiliza contra su propio plano de control: nueve pruebas que un banco puede ejecutar contra cualquier plataforma candidata, el comportamiento del código publicado de KLA, las pruebas automatizadas que lo fijan y las limitaciones restantes. Cada resultado observado cita la prueba o el archivo fuente que lo demuestra.

Descargar la suite de pruebas Ejecutarla en un piloto gobernado

v1.0 · Publicada el 2026-08-24 · Resultados verificados contra el código base de KLA en la publicación

Referencia rápida

Casos de prueba
Nueve pruebas de capacidades: ruta de aplicación, comportamiento ante interrupciones, vinculación y vencimiento de aprobaciones, replay, reintentos, custodia de credenciales, alteración de registros y verificación offline.
Resultados de decisión
Cuatro resultados de política con precedencia del peor resultado: allow, warn, require_approval, block. Una denegación de derechos prevalece sobre cualquier resultado de regla.
Comprobaciones offline
Cinco comprobaciones independientes de verificación ejecutadas por el verificador de evidencia abierto sobre un paquete exportado, sin acceso a la red.
Regla de honestidad
Cada resultado tiene un estado: fijado por pruebas automatizadas, válido con condiciones identificadas o declarado como objetivo. Las limitaciones se publican en esta página.

01

Alcance y método

Qué prueba la suite, qué excluye deliberadamente y cómo reproducir cada resultado durante una evaluación de compras.

La suite prueba una propiedad: cuando un agente de IA propone una acción consecuente, la capa gobernante decide el resultado antes de que el sistema empresarial cambie de estado y el registro de esa decisión resiste el examen. Las nueve pruebas examinan esa propiedad desde el punto de vista del atacante, del operador y del auditor.

Método: cada prueba está escrita como un procedimiento de caja negra que un banco puede ejecutar sobre un candidato desplegado con su propio flujo y sus propios revisores. En KLA, el comportamiento observado describe lo que hace la implementación publicada en la ruta de pasarela gobernada y cita la prueba automatizada o el módulo fuente que lo fija. Las citas nombran archivos reales del código base de KLA.

Exclusiones: la suite no prueba la calidad del modelo, la robustez de los prompts ni el rendimiento de las tareas del agente. Tampoco prueba la clasificación legal. Prueba la ruta de control y la evidencia.

  • •Reproducible: cada procedimiento se puede ejecutar contra un despliegue activo y cada resultado de KLA cita su prueba de referencia.
  • •Primero las rutas negativas: siete de las nueve pruebas tratan de fallos, cambios o replay.
  • •Honesta con la cobertura: los resultados se declaran para la ruta de acción gobernada. La cobertura de un entorno concreto depende del despliegue y debe probarse por integración.

02

Modelo de amenazas

Vectores de fallo que una capa de gobernanza en tiempo de ejecución debe superar antes de que un banco confíe en ella para acciones consecuentes.

VectorPreguntaCubierto por
Bypass de ruta¿Puede la acción llegar al sistema empresarial sin una decisión de política?RT-01
Caída de dependencia¿Qué sucede cuando el motor de políticas no está disponible o falla?RT-02
Del momento de comprobación al uso¿Pueden cambiar los parámetros entre la aprobación y la ejecución?RT-03
Autoridad vencida¿Puede una aprobación antigua autorizar una acción nueva?RT-04
Replay¿Puede reutilizarse una aprobación entre ejecuciones, herramientas o tenants?RT-05
Entrega duplicada¿Un reintento ejecuta dos veces el efecto?RT-06
Exposición de credenciales¿Puede el agente, el modelo o una herramienta observar credenciales almacenadas?RT-07
Alteración de registros¿Se detecta un registro modificado de decisión, aprobación o evidencia?RT-08
Exportador no confiable¿Puede un tercero verificar el registro sin confiar en la plataforma que lo produjo?RT-09

03

Las nueve pruebas de capacidades

Cada prueba plantea la pregunta del comprador, un procedimiento de caja negra, el comportamiento esperado de cualquier plataforma gobernada y el comportamiento observado de KLA con su evidencia.

RT-01

Ruta de aplicación y bypass

Válido con condiciones identificadas

¿Una decisión de bloqueo detiene la acción en todas las rutas previstas?

Procedimiento

  1. 01Invoque la llamada consecuente por la ruta gobernada con una política que la bloquee y confirme que el sistema empresarial no cambió.
  2. 02Intente la misma acción por cada ruta alternativa admitida por la arquitectura: API directa, integraciones secundarias y consolas de operador.
  3. 03Pida al proveedor el componente exacto que aplica cada ruta y el equipo que posee su configuración.

Esperado de cualquier plataforma gobernada

Un resultado block o require_approval impide el efecto en la ruta gobernada y el proveedor puede enumerar las rutas gobernadas y desprotegidas.

Comportamiento observado de KLA

En la ruta de pasarela, esta sella el recibo de decisión en el ledger de evidencia antes de ejecutar la herramienta; block y require_approval terminan la llamada. La política de herramienta también se comprueba en el hub en cada invocación MCP.

Evidencia

  • services/governance-pep/src/gateway.ts: decision sealed before the side effect; block and require_approval short-circuit
  • governance-gateway.test.ts: 15 cases on the gateway decision path
  • cmb-aml-governance-gateway.test.ts: 16 end-to-end cases on a banking workflow
  • scripts/check-production-governance-gateway.mjs: deployment guard that the gateway is enabled in production

Condiciones

  • La pasarela depende de la configuración de despliegue y el operador self-hosted debe habilitarla.
  • El endpoint interno de ejecución de conectores confía en que la compuerta de herramientas se ejecutó antes.
RT-02

Caída del motor de políticas

Fijado por pruebas automatizadas

¿Qué resultado produce la plataforma cuando la evaluación de políticas no está disponible?

Procedimiento

  1. 01Desconecte el servicio de decisión de políticas o inyecte un fallo de transporte mientras el agente propone una acción.
  2. 02Repita con un fallo interno del motor de políticas y registre cada resultado.
  3. 03Registre el resultado, el código de motivo y si alguna configuración puede convertir el fallo en autorización.

Esperado de cualquier plataforma gobernada

Cada fallo produce block o require_approval con un motivo legible por máquina. Ningún valor de configuración convierte un fallo de evaluación en allow.

Comportamiento observado de KLA

La revisión muestra cierre por defecto en todas las capas: los fallos de transporte, de política, de firma, de dependencias, del juez de IA y del almacén de evidencia deniegan.

Evidencia

  • services/governance-pep/src/decisions.ts + environment.ts: fail-closed decision builder; override cannot be allow
  • policy-evaluation-service.test.ts: 12+ fail-closed cases including pack-verification failure and “must not fail open” regression
  • services/policy-engine/src/policy-pack/lint.ts: allow/warn default decision is a publish-time error
  • transition-gate-decision.test.ts: errored policy outcome blocks and is excluded from human-recoverable reasons

Condiciones

  • Los entornos distintos de producción cierran con require_approval y una caída llena la cola.
  • El valor por defecto depende de la variable de entorno de ejecución.
RT-03

Vinculación de aprobación a parámetros

Fijado por pruebas automatizadas

¿Puede una aprobación autorizar parámetros distintos de los revisados?

Procedimiento

  1. 01Solicite aprobación para una llamada con parámetros concretos.
  2. 02Cambie un parámetro material después de la aprobación y reanude.
  3. 03Compruebe que el parámetro original se conserva y que el cambio se rechaza o exige una nueva decisión.

Esperado de cualquier plataforma gobernada

La aprobación se vincula a los parámetros exactos y cualquier cambio material requiere una nueva decisión.

Comportamiento observado de KLA

La reanudación recalcula el hash de argumentos y rechaza una mutación, mientras que el binding de salida incluye el hash del resultado.

Evidencia

  • services/governance-pep/src/gateway.ts: TOCTOU re-verification against the ledger-sealed hash only
  • governance-gateway.test.ts: “TOCTOU: Phase-2 resume with mutated arguments fails closed and never executes”
  • cmb-aml-governance-gateway.test.ts: “fails closed when the decision input changes after approval”

Condiciones

  • La reverificación criptográfica se ejecuta en la ruta del gateway. Las herramientas de conector gobernadas reanudan a través del objeto de estado del runtime del agente, que fija los argumentos estructuralmente sin una segunda comparación de hash.
RT-04

Aprobaciones vencidas

Válido con condiciones identificadas

¿Puede una aprobación vencida autorizar una acción?

Procedimiento

  1. 01Cree una aprobación con una hora límite, deje que venza e intente aprobarla a través de cada superficie de decisión que exponga la plataforma.
  2. 02Confirme qué autoridad conserva una aprobación vencida y qué superficies aplican el vencimiento.

Esperado de cualquier plataforma gobernada

Una aprobación vencida no autoriza la acción y una decisión propia no puede comprobarla.

Comportamiento observado de KLA

Las aprobaciones tienen una hora límite, una hora por defecto. Ambas superficies de decisión rechazan una decisión vencida: la superficie del plano de control, utilizada por el Decision Desk, calcula el estado de vencimiento y solo permite escalar, y la actualización de decisiones de la API de ejecución exige que la hora límite siga en el futuro, por lo que devuelve un conflicto después del plazo. La separación maker-checker se aplica en el servidor en ambas rutas.

Evidencia

  • services/api/src/routers/approvals.ts: overdue approvals accept escalate only; maker cannot check
  • services/execution-api/src/routes/approvals.ts: decision update requires due_at in the future
  • approval-decision-self-approval.test.ts: post-deadline decision returns 409 without signaling the workflow
  • approvals.maker-checker.test.ts: 10 cases

Condiciones

  • Las aprobaciones de compuerta de herramientas esperan indefinidamente por diseño; el tiempo de espera configurable se aplica a los nodos explícitos de flujo de aprobación humana.
RT-05

Replay entre límites

Fijado por pruebas automatizadas

¿Puede una aprobación autorizar una segunda acción en otro lugar?

Procedimiento

  1. 01Capture una decisión aprobada y reprodúzcala contra otra ejecución, herramienta, tenant y salida.
  2. 02Confirme la clave de alcance de la decisión almacenada.

Esperado de cualquier plataforma gobernada

Las decisiones se limitan a tenant, ejecución y llamada de herramienta; ningún replay cruza esos límites.

Comportamiento observado de KLA

La clave de idempotencia es tenant:execution:gate y una llamada reproducida devuelve el resultado almacenado sin autorizar otro tenant o ejecución.

Evidencia

  • services/governance-pep/src/idempotency.ts: key structure
  • cmb-aml-governance-gateway.test.ts: “does not replay an approval across execution or tenant ledger keys”
RT-06

Reintento y entrega duplicada

Fijado por pruebas automatizadas

¿Un fallo, reintento o entrega duplicada ejecuta dos veces el efecto?

Procedimiento

  1. 01Entregue dos veces la misma llamada gobernada y repítala después de completar la ejecución.
  2. 02Cuente los efectos e inspeccione la relación entre decisiones, ejecuciones y evidencia.

Esperado de cualquier plataforma gobernada

Un efecto por acción aprobada en reintentos concurrentes y secuenciales, con el comportamiento de la ventana de fallo declarado.

Comportamiento observado de KLA

El ledger duradero registra la intención antes de ejecutar y el resultado después; una llamada confirmada reproducida devuelve el resultado almacenado sin volver a ejecutar.

Evidencia

  • services/governance-pep/src/gateway.ts: write-ahead intent, committed short-circuit, one-shot output release
  • governance-gateway.test.ts: “exactly-once: a replayed committed call returns the cached result without re-executing”; concurrent-loser case
  • cmb-aml-governance-gateway.test.ts: re-drive across an orchestrator retry without a second side effect

Condiciones

  • En la ventana de fallo, exactly-once depende de que el sistema descendente respete la clave de idempotencia.
  • La tabla del ledger no tiene todavía una política de seguridad a nivel de fila.
RT-07

Custodia de credenciales

Válido con condiciones identificadas

¿Puede el agente, el modelo o una herramienta observar credenciales almacenadas?

Procedimiento

  1. 01Rastree dónde se resuelven las credenciales y en qué memoria entran.
  2. 02Pruebe falsificación de solicitudes del lado del servidor mediante una URL de conector.
  3. 03Envíe escrituras a través de un conector de base de datos de solo lectura.

Esperado de cualquier plataforma gobernada

Las credenciales solo se resuelven en el plano de control, la salida se fija a direcciones validadas y los conectores de solo lectura rechazan escrituras.

Comportamiento observado de KLA

Las credenciales se resuelven en el plano de control; la salida valida y fija la IP, rechaza redirecciones y las transacciones de base de datos son de solo lectura.

Evidencia

  • services/api/src/services/connector-execution.ts: control-plane custody; DNS-pinned egress; BEGIN READ ONLY
  • connector-network-safety.ts: metadata, link-local, multicast, and documentation ranges blocked; private ranges gated by explicit configuration
  • mcp-installation-secret-safety.ts: secret-pattern rejection at the API boundary

Condiciones

  • Los servidores MCP iniciados localmente heredan el entorno del proceso worker.
  • No hay una prueba negativa automatizada que garantice que un prompt nunca contiene credenciales.
  • Un conector puede omitir la verificación TLS; el revisor debe comprobar ese registro.
RT-08

Alteración de registros

Fijado por pruebas automatizadas

Si alguien altera un registro almacenado, ¿qué lo detecta?

Procedimiento

  1. 01Altere un byte de un registro de decisión, auditoría de aprobación y recibo de evidencia.
  2. 02Lea cada registro alterado y expórtelo; registre dónde aparece la detección.

Esperado de cualquier plataforma gobernada

La alteración se detecta al leer o exportar mediante mecanismos independientes del almacén modificado.

Comportamiento observado de KLA

Las lecturas del registro de auditoría y de las compuertas de políticas pasan por lecturas verificadas que recomputan el hash de contenido del registro y su prueba de inclusión; una discrepancia impide servir el registro. Los recibos firmados forman una cadena y las alteraciones, eliminaciones y reordenaciones rompen la cadena.

Evidencia

  • services/api/src/services/immudb-multi-tenant.ts: hash recomputation and trusted-read verification on audit and policy-gate reads
  • services/governance-pep/src/receipt-chain.ts + signing.ts: signed hash chain; 28 test cases including tamper, reorder, truncation
  • export-api.receipt-ledger-bundle.test.ts: tampered receipt and tampered ledger record turn the export red

Condiciones

  • Algunas lecturas de decisiones de políticas comprueban un hash de contenido almacenado junto al registro sin recomputar una prueba de inclusión del servidor, y los modelos de lectura visibles, como la tabla de decisiones de control, son filas mutables; la alteración en esas rutas se establece mediante comparación con el ledger sellado y durante la exportación.
  • La detección ocurre al leer o exportar; no existe una reverificación continua.
  • La truncación final requiere un hash terminal almacenado de forma independiente.
RT-09

Verificación offline de evidencia

Fijado por pruebas automatizadas

¿Puede un auditor verificar un paquete exportado sin acceso a la red y sin una cuenta de KLA?

Procedimiento

  1. 01Exporte un Sealed Evidence Bundle, llévelo a una máquina aislada y ejecute el verificador.
  2. 02Cambie un byte de cada clase de artefacto y repita; cada cambio debe marcar una comprobación concreta.

Esperado de cualquier plataforma gobernada

Un verificador autónomo prueba firmas, cadenas hash y pruebas de inclusión a partir del paquete, explica lo que no puede demostrar offline y falla ante la manipulación.

Comportamiento observado de KLA

El verificador ejecuta cinco comprobaciones sin acceso a la red, usando el conjunto de claves incluido en el paquete: firma del manifiesto, cadenas de firmas de recibos, recomputación de la cadena hash del ledger, inclusión Merkle y consistencia del ancla temporal.

Evidencia

  • packages/evidence-verifier: five checks, command-line verifier, ~55 automated cases
  • verifier.test.ts: one-byte tamper per artifact class; revoked key; path escape; malformed key set

Condiciones

  • El conjunto de claves del verificador viaja dentro del paquete, por lo que una ejecución correcta demuestra la coherencia interna del paquete tal como se exportó; detectar un paquete vuelto a firmar por un exportador no confiable requiere comparar sus claves con material de claves recibido de forma independiente, y la fijación de claves integrada está en la hoja de ruta.
  • La inclusión Merkle se comprueba contra la prueba de transacción conservada en el paquete; verificarla contra el estado firmado de forma independiente por el ledger está en la hoja de ruta, y confirmar el ancla temporal en la cadena pública requiere un paso conectado.
  • Un paquete con recibos no firmados puede pasar con cero cadenas verificadas; el auditor debe leer el recuento.

04

Verificación offline de evidencia

Qué puede verificar un auditor sobre un paquete exportado en una máquina aislada y qué requiere todavía una comprobación conectada o del servidor.

La aplicación en tiempo de ejecución y la evidencia de auditoría son afirmaciones distintas. La tabla muestra qué prueba el verificador offline solo con el paquete; la diferencia importa en compras.

ComprobaciónQué demuestra offline
manifest-signatureEl manifiesto está firmado por una clave de servicio y una clave de tenant presentes en el conjunto del paquete; las firmas malformadas o de algoritmo incorrecto fallan.
receipt-signaturesCada recibo firmado se verifica con Ed25519 y los recibos de cada ejecución forman una cadena hash íntegra desde el origen; una clave revocada falla.
ledger-hash-chainSe recomputa el hash de cada registro del ledger y los registros forman un único linaje conectado con una sola raíz.
merkle-inclusionSe recomputa la raíz Merkle del paquete y cada prueba de inclusión se verifica contra su raíz de transacción.
ots-anchorLa prueba temporal se analiza estrictamente, vincula el digest recomputado del manifiesto y contiene al menos una atestación compatible.

El verificador es una herramienta de línea de comandos autónoma: el código de salida 0 indica que todas las comprobaciones pasaron, 1 que falló una comprobación y 2 que la invocación no es válida. Hay paquetes de muestra en la muestra de Evidence Room.

05

Limitaciones publicadas

Límites conocidos de la implementación actual que el banco debe ponderar frente a la lista equivalente no publicada de cualquier otro candidato.

Estos son los límites actuales que KLA publica con la suite. Cada uno aparece en el código fuente o en la documentación de la que procede.

  1. 01La cobertura depende del despliegue. Los resultados corresponden a la ruta de pasarela gobernada; las rutas no rastreadas siguen sin gobernar hasta probarlas.
  2. 02Las herramientas de conectores gobernados usan la aplicación dentro del adaptador: la evaluación fail-closed, la comprobación del hash de argumentos y el ledger exactly-once se aplican en la ruta de pasarela.
  3. 03El conjunto de claves del verificador offline viaja dentro del paquete; una ejecución correcta demuestra la coherencia interna del paquete tal como se exportó, y detectar un paquete vuelto a firmar por un exportador no confiable requiere material de claves recibido de forma independiente.
  4. 04El resultado warn queda registrado y visible para operadores; en el límite de la herramienta se ejecuta igual que allow.
  5. 05La verificación offline todavía no comprueba la inclusión contra el estado firmado independiente del ledger y las anclas temporales solo se confirman on-chain mediante un paso conectado.
  6. 06El ledger de idempotencia no tiene política de seguridad a nivel de fila; el aislamiento depende de claves con prefijo de tenant.
  7. 07No se publican cifras de latencia medida porque no hay una ejecución de benchmark comprometida en el repositorio.

06

Latencia y carga

Objetivos de nivel de servicio declarados y método de medición que los respalda.

Los objetivos de latencia son umbrales aplicados en la suite de carga comprometida: las comprobaciones de política apuntan a un percentil 95 inferior a 50 ms y un percentil 99 inferior a 100 ms; la ingesta de trazas apunta a un percentil 95 inferior a 100 ms.

KLA no publica cifras de latencia de producción medidas en esta página. Hasta que exista un benchmark con hardware, datos y configuración, la afirmación honesta es el objetivo y el mecanismo de aplicación.

07

Lista de comprobación de compras

Preguntas para cada candidato de gobernanza en tiempo de ejecución y el artefacto que responde a cada una.

Plantee estas preguntas a cada candidato, incluido KLA. Cada una nombra el artefacto que la resuelve; una presentación no lo hace.

  1. 01¿Qué componente decide cada ruta gobernada y qué impide físicamente una denegación? Artefacto: recorrido de arquitectura y RT-01.
  2. 02¿Cuál es el resultado documentado ante cada fallo de dependencia y puede alguna configuración permitir ante un fallo? Artefacto: transcripción RT-02 y esquema de configuración.
  3. 03¿Dónde se almacena la vinculación entre aprobación y argumentos y quién la verifica al reanudar? Artefacto: RT-03 con parámetro mutado.
  4. 04¿Cuáles son las reglas de alcance y vencimiento de las aprobaciones? Artefactos: transcripciones RT-04 y RT-05.
  5. 05¿Cuál es la garantía exactly-once ante fallo y reintento, con su condición de ventana de fallo? Artefacto: RT-06 con detención del worker.
  6. 06¿Qué memoria contiene credenciales empresariales y qué fija la salida? Artefacto: RT-07.
  7. 07¿Qué detecta la alteración de cada clase de registro y cuándo? Artefacto: RT-08.
  8. 08¿Puede un tercero verificar el registro sin cuenta del proveedor ni red? Artefacto: RT-09 en una máquina aislada.
  9. 09¿Qué limitaciones publicadas afectarían al primer flujo gobernado? Artefacto: lista de limitaciones del proveedor.

08

Trabajo relacionado

Esquemas, guías y muestras que acompañan esta suite durante una evaluación.

Esquema de decisión de políticas de agentes de IA

Formato del registro de decisión que sellan los recibos de esta suite, con ejemplos por resultado.

Esquema de eventos de aprobación de agentes de IA

Registro de aprobación que ejercitan las pruebas de vinculación, incluidos los campos maker-checker.

Muestra de Evidence Room

Sealed Evidence Bundle descargable para ejecutar el verificador offline.

Guía de selección de plataformas de gobernanza

Guía bancaria de selección que usa esta suite como etapa de prueba de capacidades.

Gobernanza de IA en banca: guía 2026

Mapa de regulación a control y paquete de aprobación del comité de riesgos.

Esquema de registro de auditoría de agentes de IA

Formato de registro que examinan las pruebas de alteración.

Ejecute la suite

Pruébela en uno de sus flujos

Una evaluación acotada ejecuta las nueve pruebas sobre un flujo consecuente con sus revisores y políticas y termina con el paquete exportado verificado en su máquina.

Solicitar un piloto gobernado Solución para servicios financieros
Suite de pruebas de capacidades de gobernanza de agentes de IA en tiempo de ejecución