La prueba después de un incidente: cómo respondemos «quién autorizó esto»

Una situación hipotética, el problema detrás y lo que construimos para que no se repita

La situación

Un cliente llega a nosotros — no una startup, sino una empresa con un proceso: solicitudes, aprobaciones, pagos. Desplegamos un agente que conduce parte de ese proceso. Dos meses después hay un incidente: el agente envió un pago que nadie aprobó.

La revisión empieza con una pregunta simple: «muéstrenos con qué base lo hizo». Y resulta que no hay nada que mostrar.

Hay registros. Hay un hilo de conversación. Hay una exportación del CRM. Pero ninguno de esos artefactos responde si el agente tenía derecho a esa acción en ese segundo y quién se lo concedió. La autorización está en un sitio, la decisión en otro, el envío en un tercero y el hecho de la ejecución en el receptor — y nadie los comprobó nunca juntos.

El problema

Lo formulamos así: hay una brecha entre autorización, decisión, envío y efecto, y la industria la cierra con promesas en lugar de pruebas.

La atestación y los estándares de identidad responden «quién está al otro lado»: qué workload, qué clave. Es necesario, pero no responde «con qué derecho actuaste». Un servidor correctamente atestado puede aceptar una acción fuera del ámbito delegado sin que se viole ninguna propiedad de atestación.

Los registros responden «qué ocurrió», no «estaba permitido». Un registro puede ser completo y describir una acción que nadie autorizó.

Tras un incidente, el cliente queda con muchos datos y sin respuesta. Y el proveedor con «todo queda registrado», que no resiste una revisión.

Lo que construimos

No construimos otra implementación de agente. Construimos un instrumento que permite verificar afirmaciones sobre autorizaciones — las nuestras y las de otros — bajo un mismo reglamento.

Un contrato de comparación. Cuatro escenarios que rompen casi cualquier diseño: rechazo en el punto de decisión, decisión sobre evidencia obsoleta, instancia aprobadora inaccesible, revocación después del envío. Catorce campos obligatorios — de la autorización y la decisión hasta el efecto real, el recibo, el digest de la acción, el plazo y el número de reintentos. Cuatro estados de evidencia: medido, no aplicable, no emitido, no medido.

Este último es la clave. Prohíbe la manipulación principal de los informes: presentar «no lo medimos» como «no aplica».

Un verificador offline con controles negativos. La comprobación debe rechazar un paquete en el que se eliminó un caso, se duplicó, se invirtió un veredicto, se retiró un registro citado o dos filas intercambiaron sus recibos. Y debe aceptar el paquete sin alterar. Suena a formalidad hasta que se dispara: en un paquete publicado, un registro afirmaba que el ejecutor había rechazado en su propia frontera, mientras el registro del job mostraba un intento bloqueado y un rechazo posterior, al reintentar. Ningún control de integridad lo detecta — solo contrastar la afirmación con el registro.

Apertura. El contrato, los casos y las reglas de rechazo están publicados; el trabajo ocurre en un grupo abierto sobre identidad y confianza, con resultados en un repositorio público y un artículo en revisión. No pedimos que nos crean: cualquiera puede tomar un paquete y ejecutar la comprobación.

Qué le da al cliente

Después de un incidente — no un «log», sino un análisis: qué autorización aplicaba, qué decisión se tomó, qué se envió, qué ocurrió en el lado receptor y dónde faltan pruebas. Antes de un incidente — la posibilidad de acordar de antemano qué es normal y qué es un incidente.

Y, sobre todo, la posibilidad de verificarnos mediante un tercero. Eso es justo lo que falta en «confíe en nosotros, todo está bajo control».

Lo que no afirmamos

No emitimos certificados ni reclamamos conformidad con un estándar. No hemos probado que un agente sea seguro en general. Decimos con claridad que parte de la garantía vive en quien ejecuta y en el destino: podemos mostrar que una decisión se tomó dentro de la autorización concedida, pero no podemos probar por nuestra cuenta que el receptor ejecutó exactamente esa acción.

Y enunciamos los límites de nuestro método: la comparación es offline, sobre registros conservados; no establece aplicación en vivo ni efectos en el lado destino.

Cómo se ve en la práctica

Un piloto: revisamos los registros de su agente, los pasamos por el contrato y mostramos qué prueban y qué no. Después, o se mejora el registro, o se cambian los límites de la autorización, o la parte no cubierta se escribe honestamente en el contrato.

Si tiene un agente en producción y la pregunta «qué mostraremos si algo sale mal» — ahí empezamos.