AuthProof SDK

AuthProof es una capa de auditoría y atribución para agentes de IA. Permite demostrar qué autorizó un usuario antes de que el agente actuara, y registra lo que el agente realmente hizo en relación con esa autorización.

El mecanismo es simple. El usuario firma un recibo de delegación con su propia clave privada. El recibo contiene el alcance, los límites, las instrucciones del operador (con hash) y una ventana temporal. Un verificador previo a la ejecución comprueba cada acción propuesta contra el recibo, y un registro de acciones de solo anexado registra lo que se ejecutó. El resultado son evidencias: lo que se autorizó, comparado con lo que ocurrió.

Esto no es un control de seguridad contra un operador malicioso. El verificador se ejecuta en el mismo proceso que el agente, y un operador deshonesto puede simplemente no invocarlo. Ninguna propiedad criptográfica puede solucionar eso desde dentro del mismo runtime. AuthProof demuestra la autorización para despliegues que ejecutan la puerta de control, y ofrece a auditores, reguladores y usuarios un registro que pueden comprobar a posteriori.

Qué lo hace diferente:

• El usuario es la autoridad firmante. El objeto de autorización se firma con la clave privada del usuario, no se escribe en una política gestionada por el operador. El alcance firmado y el hash del programa en el recibo siempre prevalecen sobre los metadatos del registro del operador. Si los metadatos del operador entran en conflicto con el recibo firmado, la puerta de control deniega la acción en lugar de seguir los metadatos.

• Compromiso del estado del modelo en dos fases. El modelo se mide en el momento de la autorización y se vuelve a medir antes de la ejecución. Estas mediciones son calculadas por software y auto-atestiguadas, no están ancladas en hardware. Son evidencia de manipulación para despliegues honestos, no una prueba contra un host hostil.

• Actualización del proveedor versus sustitución maliciosa, diferenciadas. Los cambios en el estado del modelo se clasifican en actualizaciones legítimas del proveedor (PROVIDER_UPDATE_REQUIRES_REAUTH) y sustituciones no autorizadas (MALICIOUS_MODEL_SUBSTITUTION). Cada una produce un código de motivo de denegación legible por máquina que identifica qué componentes cambiaron.

Verificador previo a la ejecución

La puerta de control que se ejecuta antes de que se ejecute cualquier acción del agente.

PreExecutionVerifier.check() verifica cada acción propuesta contra el recibo de delegación firmado. Enruta cada acción a través de él en el proceso de tu agente, antes de que la acción se ejecute. El verificador firma sus propias decisiones de permitir/denegar en un registro de auditoría, de modo que cada resultado forma parte del registro.

Una verdad incómoda sobre la que construir: el verificador está en el mismo proceso. Verifica pruebas; no puede detener a un operador que se niega a invocarlo. Úsalo donde quieras evidencias, no donde necesites hacer cumplir la norma contra el operador que ejecuta el código.

Por qué importa

La mayor parte de la autorización de agentes hoy en día es la palabra del operador: una política que el operador escribió, aplicada por código que el operador controla. Cuando algo sale mal, no hay registro de lo que el usuario autorizó realmente, solo la reconstrucción que hace el operador. AuthProof le da la vuelta a eso. El recibo firmado del usuario es anterior a la ejecución, y el registro de acciones registra lo que se ejecutó en relación con él. La pregunta "¿autorizó el usuario esto?" pasa a ser comprobable en lugar de discutible.

Inicio rápido

import { PreExecutionVerifier, DelegationLog } from 'authproof-sdk/pre-execution-verifier'
import { RevocationRegistry } from 'authproof-sdk'

// 1. Set up the gate
const delegationLog      = new DelegationLog()
const revocationRegistry = new RevocationRegistry()
await revocationRegistry.init({ privateKey, publicJwk })

const verifier = new PreExecutionVerifier({ delegationLog, revocationRegistry })
await verifier.init({ privateKey: verifierKey, publicJwk: verifierPub })

// 2. Register your delegation receipt
delegationLog.add(receiptHash, receipt)

// 3. Gate every action — before the agent runs
const result = await verifier.check({
  receiptHash,
  action:               { operation: 'read', resource: 'calendar' },
  operatorInstructions: 'Summarize meetings. Stay within scope.',
  programHash,          // optional: prevents code substitution attacks
})

if (!result.allowed) {
  throw new Error(`Blocked: ${result.blockedReason}`)
}
// Agent runtime only reaches here after all thirteen checks pass

Trece comprobaciones secuenciales (se detiene en el primer fallo)

#	Comprobación	Bloquea cuando
1	Firma del recibo	La firma ECDSA P-256 no es válida o el recibo ha sido manipulado
2	Revocación	El recibo ha sido revocado mediante RevocationRegistry (en cascada: un ancestro revocado deniega a sus descendientes)
3	Ventana temporal	El recibo ha expirado o aún no es válido (oráculo de marca de tiempo del log, no el reloj del cliente)
4	Alcance	La acción no está en ScopeSchema.allowedActions; sin un esquema estructurado, la coincidencia por palabras clave es solo orientativa y nunca bloquea
5	Instrucciones del operador	Las instrucciones proporcionadas no coinciden con el hash fijado en el recibo en el momento de la emisión; se omite con una advertencia cuando el llamador no las proporciona
6	Hash del programa	El programHash proporcionado no coincide con el hash executes comprometido (opcional)
7	Riesgo de sesión	Se superan los umbrales de confianza/riesgo (opcional)
8	Integridad del esquema de la herramienta	toolSchemaHash no coincide con el recibo (opcional)
9	Estado del modelo	Se detecta deriva del modelo (opcional; medición calculada por software y auto-atestiguada)
10	Vinculación del hash de salida de la herramienta	El hash de salida no coincide con el recibo (opcional)
11	Procedencia de la instrucción	La fuente de la instrucción no está en las trustedSources del recibo (opcional)
14	Contención del alcance del padre	El sub-recibo excede el alcance del padre (solo sub-recibos); revocar cualquier ancestro deniega al hijo en el momento de la comprobación
15	Deriva del estado de autoridad	authorityStateCommitment ha derivado desde la emisión (opcional)

Las posiciones 12 y 13 nunca se implementaron; el hueco en la numeración es histórico. La puerta se detiene en la primera comprobación fallida. El consumo de un solo uso se ejecuta al final, después de que todas las comprobaciones pasen, de modo que una ranura de consumo nunca se quema en un recibo que sería denegado por otro motivo.

Cada resultado de comprobación, pase o falle, se registra automáticamente en un ActionLog inmutable firmado con la propia clave del verificador.

Los datos firmados prevalecen. El alcance y el hash del programa del recibo firmado siempre prevalecen sobre los metadatos del log del operador. Si los metadatos no firmados de DelegationLog no coinciden con el recibo firmado, la puerta deniega la acción (SCOPE_METADATA_MISMATCH / PROGRAM_METADATA_MISMATCH). Los metadatos del log son solo un respaldo cuando el recibo no lleva un alcance estructurado ni un valor executes firmado.

La delegación guiada se guía por observación. ScopeDiscovery.guided() y AuthProofClient.delegateGuided() ejecutan observe → generateScope → approve → finalize en una sola llamada, y el borrador de alcance observado completo se auto-aprueba sin revisión humana. Para un momento de autorización humana genuino, pase el hook reviewDraft (aprobar, modificar o rechazar el borrador antes de la emisión) o ejecute los pasos por separado con un approve() explícito.

Integraciones de middleware