AuthProof SDK

AuthProof es un protocolo de delegación criptográfica para IA agentiva. La mayoría de los protocolos en este espacio se aplican contra una política definida por el operador, otorgándole autoridad para expandir o reinterpretar la intención original del usuario después del hecho. AuthProof está construido alrededor de un modelo de confianza diferente: la clave privada del propio usuario firma el objeto de autorización que controla la ejecución, y el estado del modelo en vivo se verifica tanto en el momento de la autorización como inmediatamente antes de la ejecución. La combinación de autoridad firmada por el usuario y control del estado del modelo en vivo es la afirmación específica, no una historia de aplicación amplia.

Qué lo hace diferente:

• El usuario es la autoridad firmante. Todos los protocolos competidores (AIP, AITH, OAP, SAGA, AgentSpec) se aplican contra una política que el operador define. En AuthProof, la clave privada del usuario firma el objeto de autorización directamente. El operador no puede ampliar el alcance después de que el usuario haya firmado.

• Compromiso de estado del modelo en dos fases. El modelo se mide en el momento de la autorización y se vuelve a medir inmediatamente antes de la ejecución. Si el modelo se ha desviado entre esos dos puntos, la ejecución se bloquea en la verificación previa a la ejecución.

• Actualización del proveedor versus sustitución maliciosa, distinguidos. El protocolo clasifica los cambios de estado del modelo en dos categorías: actualizaciones legítimas del proveedor (PROVIDER_UPDATE_REQUIRES_REAUTH) e intercambios no autorizados (MALICIOUS_MODEL_SUBSTITUTION). Cada una produce un código de motivo de denegación legible por máquina que identifica qué componentes cambiaron.

Verificador de Pre-Ejecución

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

El PreExecutionVerifier se encuentra fuera del runtime del agente. El runtime nunca obtiene el control hasta que el verificador pasa. Un agente comprometido o malicioso no puede omitirlo — se ejecuta antes de que el runtime comience.

Por qué es importante

Las comprobaciones de autorización tradicionales ocurren dentro del runtime del agente. Si el runtime está comprometido, esas comprobaciones pueden omitirse, reordenarse o eludirse. PreExecutionVerifier elimina esta superficie de ataque al mover la autorización completamente fuera del runtime. El agente solo ejecuta si — y solo si — las seis comprobaciones secuenciales pasan primero.

Inicio rápido```js

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 six checks pass

### Seis verificaciones secuenciales (se detiene ante el primer fallo)

| # | Verificación | Bloquea cuando |
|---|-------|-------------|
| 1 | Firma del recibo | Firma ECDSA P-256 inválida o recibo alterado |
| 2 | Revocación | El recibo ha sido revocado mediante `RevocationRegistry` |
| 3 | Ventana temporal | Recibo caducado o aún no válido (oráculo de marca de tiempo del registro, no reloj del cliente) |
| 4 | Alcance | La acción no está en `ScopeSchema.allowedActions` o falla la coincidencia de alcance basada en texto |
| 5 | Instrucciones del operador | Las instrucciones actuales no coinciden con el hash bloqueado en el recibo en el momento de la emisión |
| 6 | Hash del programa | El `programHash` proporcionado no coincide con el hash de `executes` comprometido (prevención de sustitución de código) |

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

### Integraciones de middleware

Wrappers de integración directa para frameworks comunes. Cada wrapper controla cada llamada a través de `PreExecutionVerifier` antes de que se ejecute el código envuelto.

- **[LangChain](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/langchain.js)** — envuelve cualquier agente con un método `invoke()`
- **[Express/HTTP](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/express.js)** — middleware de solicitud para cualquier framework compatible con Express
- **[Generic function wrapper](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/generic.js)** — envuelve cualquier función asíncrona```js
// LangChain
import { authproofMiddleware } from 'authproof-sdk/middleware/langchain'
const guardedAgent = authproofMiddleware(agent, { receiptHash, verifier })

// Express
import { authproofMiddleware } from 'authproof-sdk/middleware/express'
app.use(authproofMiddleware({ verifier, getReceiptHash: (req) => req.headers['x-receipt-hash'] }))

// Any function
import { guardFunction } from 'authproof-sdk/middleware/generic'
const guardedExecute = guardFunction(executeAction, { receiptHash, verifier, action })

---

The Problem

Cada marco existente del IETF para identidad de agentes — AIP, draft-klrc-aiagent-auth, WIMSE — aborda la confianza servicio-a-agente: cómo un servicio posterior verifica que un agente está autorizado para llamarlo. Ninguno de ellos aborda la confianza usuario-a-operador. La cadena de delegación en los sistemas agentivos actuales es:

-``` User → Operator → Agent → Services

El usuario instruye al operador. El operador instruye al agente. Pero no existe ningún registro criptográfico de la intención original del usuario en el momento de la delegación. El operador se convierte en un tercero de confianza con autoridad sin control para ampliar, distorsionar u omitir las instrucciones del usuario antes de que lleguen al agente.

Las consecuencias:

- Los usuarios no pueden probar lo que autorizaron.
- Los reguladores no tienen una pista de auditoría.
- Los tribunales no tienen una cadena de pruebas.
- Los agentes no pueden distinguir las instrucciones legítimas del operador de las comprometidas o maliciosas.

AuthProof llena este vacío.

---

## El Primitivo Central: Recibo de Delegación

Un **Recibo de Delegación** es un Objeto de Autorización firmado anclado a un registro descentralizado de solo añadido antes de que comience cualquier acción del agente. Contiene cuatro campos requeridos:

### Alcance

Una lista de permisos explícita de operaciones permitidas. Todo lo que no está listado está denegado por defecto. Expresado en formato estructurado — no en lenguaje natural. Clases de operación:

| Class | Description |
|---|---|
| `reads` | Acceso de lectura a recursos especificados |
| `writes` | Acceso de escritura a recursos especificados |
| `deletes` | Eliminación de recursos especificados |
| `executes` | Ejecución de un programa específico, referenciado por su **hash de firma de capacidad estática** |