AuthProof SDK

AuthProof è un protocollo di delegazione crittografica per l'IA agentica. La maggior parte dei protocolli in questo campo impongono l'applicazione di una policy definita dall'operatore, dando all'operatore l'autorità di espandere o reinterpretare l'intento originale dell'utente dopo il fatto. AuthProof è costruito su un modello di fiducia diverso: la chiave privata dell'utente firma l'oggetto di autorizzazione che controlla l'esecuzione, e lo stato live del modello viene verificato sia al momento dell'autorizzazione che immediatamente prima dell'esecuzione. La combinazione di autorità firmata dall'utente e gating dello stato live del modello è la rivendicazione specifica, non una storia di enforcement generica.

Cosa lo rende diverso:

• L'utente è l'autorità firmataria. Ogni protocollo concorrente (AIP, AITH, OAP, SAGA, AgentSpec) impone l'applicazione di una policy definita dall'operatore. In AuthProof, la chiave privata dell'utente firma direttamente l'oggetto di autorizzazione. L'operatore non può ampliare l'ambito dopo che l'utente ha firmato.

• Commitment dello stato del modello in due fasi. Il modello viene misurato al momento dell'autorizzazione e rimisurato immediatamente prima dell'esecuzione. Se il modello è cambiato tra questi due punti, l'esecuzione viene bloccata nella verifica pre-esecuzione.

• Distinzione tra aggiornamento del provider e sostituzione malevola. Il protocollo classifica le modifiche dello stato del modello in due categorie: aggiornamenti legittimi del provider (PROVIDER_UPDATE_REQUIRES_REAUTH) e sostituzioni non autorizzate (MALICIOUS_MODEL_SUBSTITUTION). Ciascuna produce un codice di motivazione di rifiuto leggibile dalla macchina che identifica quali componenti sono cambiati.

Verificatore Pre-Esecuzione

Il gate deterministico che viene eseguito prima che qualsiasi azione dell'agente venga eseguita.

Il PreExecutionVerifier si trova al di fuori del runtime dell'agente. Il runtime non ottiene mai il controllo finché il verificatore non supera. Un agente compromesso o malevolo non può saltarlo — viene eseguito prima che il runtime parta.

Perché è importante

I controlli di autorizzazione tradizionali avvengono all'interno del runtime dell'agente. Se il runtime è compromesso, questi controlli possono essere saltati, riordinati o bypassati. PreExecutionVerifier elimina questa superficie d'attacco spostando l'autorizzazione completamente al di fuori del runtime. L'agente esegue solo se — e solo se — tutti e sei i controlli sequenziali vengono prima superati.

Avvio rapido```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

### Sei controlli sequenziali (si ferma al primo fallimento)

| # | Controllo | Blocca quando |
|---|-----------|---------------|
| 1 | Firma del ricevuta | Firma ECDSA P-256 non valida o ricevuta manomessa |
| 2 | Revoca | Il ricevuta è stata revocata tramite `RevocationRegistry` |
| 3 | Finestra temporale | Ricevuta scaduta o non ancora valida (oracolo timestamp del log, non orologio client) |
| 4 | Ambito | Azione non in `ScopeSchema.allowedActions` o fallisce corrispondenza ambito basata su testo |
| 5 | Istruzioni operatore | Le istruzioni attuali non corrispondono all'hash bloccato nella ricevuta al momento dell'emissione |
| 6 | Hash del programma | Il `programHash` fornito non corrisponde all'hash `executes` impegnato (prevenzione sostituzione codice) |

Ogni risultato del controllo — superato o fallito — viene automaticamente registrato in un `ActionLog` immutabile firmato con la propria chiave del verificatore.

### Integrazioni middleware

Wrapper plug-and-play per framework comuni. Ogni wrapper filtra ogni chiamata attraverso `PreExecutionVerifier` prima che il codice avvolto venga eseguito.

- **[LangChain](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/langchain.js)** — avvolge qualsiasi agente con un metodo `invoke()`
- **[Express/HTTP](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/express.js)** — middleware per richieste per qualsiasi framework compatibile con Express
- **[Generic function wrapper](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/generic.js)** — avvolge qualsiasi funzione asincrona```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 })

Il Problema

Tutti i framework IETF esistenti per l'identità degli agenti -- AIP, draft-klrc-aiagent-auth, WIMSE -- affrontano la fiducia servizio-agente: come un servizio a valle verifica che un agente sia autorizzato a chiamarlo. Nessuno di essi affronta la fiducia utente-operatore.

La catena di delega negli attuali sistemi agentici è:``` User → Operator → Agent → Services

L'utente istruisce l'operatore. L'operatore istruisce l'agente. Ma nessuna registrazione crittografica dell'intento originale dell'utente esiste al momento della delega. L'operatore diventa un terzo fidato con autorità incontrollata di espandere, distorcere o omettere le istruzioni dell'utente prima che raggiungano l'agente.

Le conseguenze:

- Gli utenti non possono dimostrare cosa hanno autorizzato.
- I regolatori non hanno una pista di audit.
- I tribunali non hanno una catena di prove.
- Gli agenti non possono distinguere le istruzioni legittime dell'operatore da quelle compromesse o maligne.

AuthProof colma questa lacuna.

---

## Il Primitivo Fondamentale: Ricevuta di Delega

Una **Ricevuta di Delega** è un Oggetto di Autorizzazione firmato ancorato a un registro decentralizzato append-only prima che inizi qualsiasi azione dell'agente. Contiene quattro campi obbligatori:

### Ambito

Un elenco esplicito di operazioni consentite. Tutto ciò che non è elencato è negato per impostazione predefinita. Espresso in formato strutturato — non in linguaggio naturale. Classi di operazioni:

| Class | Description |
|---|---|
| `reads` | Accesso in lettura a risorse specificate |
| `writes` | Accesso in scrittura a risorse specificate |
| `deletes` | Cancellazione di risorse specificate |
| `executes` | Esecuzione di un programma specifico, referenziato dal suo **static capability signature hash** |

`executes` è la classe più pericolosa. Deve referenziare l'hash crittografico del DAG di capacità statica di un programma Safescript — non un nome, URI o descrizione. Nessuna corrispondenza hash significa nessuna esecuzione.

### Limiti