AuthProof SDK

AuthProof è un livello di audit e attribuzione per agenti AI. Consente di dimostrare cosa un utente ha autorizzato prima che l'agente agisse, e registra ciò che l'agente ha effettivamente fatto rispetto a tale autorizzazione.

Il meccanismo è semplice. L'utente firma una ricevuta di delega con la propria chiave privata. La ricevuta contiene ambito, limiti, istruzioni dell'operatore (con hash) e una finestra temporale. Un verificatore pre-esecuzione controlla ogni azione proposta rispetto alla ricevuta, e un registro delle azioni in sola aggiunta registra ciò che è stato eseguito. Il risultato è una prova: ciò che è stato autorizzato, confrontato con ciò che è accaduto.

Questo non è un controllo di sicurezza contro un operatore malevolo. Il verificatore viene eseguito nello stesso processo dell'agente, e un operatore disonesto può semplicemente non chiamarlo. Nessuna proprietà crittografica può risolvere questo problema dall'interno dello stesso runtime. AuthProof dimostra l'autorizzazione per le distribuzioni che eseguono il gate, e fornisce ad auditor, autorità di regolamentazione e utenti un registro che possono verificare a posteriori.

Cosa lo rende diverso:

• L'utente è l'autorità di firma. L'oggetto di autorizzazione è firmato con la chiave privata dell'utente, non scritto in una policy gestita dall'operatore. L'ambito firmato e l'hash del programma nella ricevuta prevalgono sempre sui metadati del registro dell'operatore. Se i metadati dell'operatore sono in conflitto con la ricevuta firmata, il gate nega l'azione invece di seguire i metadati.

• Commitment dello stato del modello in due fasi. Il modello viene misurato al momento dell'autorizzazione e rimisurato prima dell'esecuzione. Queste misurazioni sono calcolate via software e auto-attestate, non radicate nell'hardware. Sono prove di manomissione per distribuzioni oneste, non prove contro un host ostile.

• Aggiornamento del provider versus sostituzione malevola, distinti. Le modifiche allo stato del modello si classificano in aggiornamenti legittimi del provider (PROVIDER_UPDATE_REQUIRES_REAUTH) e sostituzioni non autorizzate (MALICIOUS_MODEL_SUBSTITUTION). Ciascuna produce un codice di motivo di diniego leggibile dalla macchina che identifica quali componenti sono cambiati.

Verificatore Pre-Esecuzione

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

PreExecutionVerifier.check() verifica ogni azione proposta rispetto alla ricevuta di delega firmata. Instrada ogni azione attraverso di esso nel processo del tuo agente, prima che l'azione venga eseguita. Il verificatore firma le proprie decisioni di autorizzazione/rifiuto in un registro di audit, così ogni risultato fa parte del registro.

Una verità difficile da accettare su cui costruire: il verificatore è nello stesso processo. Verifica la prova; non può fermare un operatore che si rifiuta di chiamarlo. Usalo dove vuoi prove, non dove hai bisogno di applicazione contro l'operatore che esegue il codice.

Perché è importante

La maggior parte dell'autorizzazione degli agenti oggi si basa sulla parola dell'operatore: una policy che l'operatore ha scritto, applicata da codice che l'operatore controlla. Quando qualcosa va storto, non c'è alcun registro di ciò che l'utente ha effettivamente autorizzato, solo la ricostruzione dell'operatore. AuthProof ribalta questo. La ricevuta firmata dall'utente precede l'esecuzione, e il registro delle azioni registra ciò che è stato eseguito rispetto ad essa. La domanda "l'utente ha autorizzato questo?" diventa verificabile invece che discutibile.

Avvio rapido

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

Tredici controlli sequenziali (si ferma al primo fallimento)

#	Controllo	Blocca quando
1	Firma della ricevuta	Firma ECDSA P-256 non valida o ricevuta manomessa
2	Revoca	La ricevuta è stata revocata tramite RevocationRegistry (cascata: un antenato revocato nega i suoi discendenti)
3	Finestra temporale	Ricevuta scaduta o non ancora valida (oracolo del timestamp di log, non l'orologio del client)
4	Ambito	Azione non presente in ScopeSchema.allowedActions; senza uno schema strutturato, la corrispondenza per parole chiave è solo consultiva e non funge mai da gate
5	Istruzioni dell'operatore	Le istruzioni fornite non corrispondono all'hash bloccato nella ricevuta al momento dell'emissione; saltato con un avviso quando il chiamante le omette
6	Hash del programma	Il programHash fornito non corrisponde all'hash executes impegnato (opzionale)
7	Rischio di sessione	Soglie di fiducia/rischio superate (opzionale)
8	Integrità dello schema dello strumento	toolSchemaHash non corrisponde alla ricevuta (opzionale)
9	Stato del modello	Rilevato drift del modello (opzionale; misurazione calcolata via software, auto-attestata)
10	Binding dell'hash dell'output dello strumento	L'hash dell'output non corrisponde alla ricevuta (opzionale)
11	Provenienza dell'istruzione	Sorgente dell'istruzione non presente nei trustedSources della ricevuta (opzionale)
14	Contenimento dell'ambito genitore	La sotto-ricevuta supera l'ambito del genitore (solo sotto-ricevute); revocare qualsiasi antenato nega il figlio al momento del controllo
15	Drift dello stato di autorità	authorityStateCommitment è cambiato dall'emissione (opzionale)

Gli slot 12 e 13 non sono mai stati implementati; il salto nella numerazione è storico. Il gate si ferma al primo controllo fallito. Il consumo monouso viene eseguito per ultimo, dopo che ogni controllo è passato, così uno slot di consumo non viene mai bruciato su una ricevuta che verrebbe negata per un altro motivo.

Ogni risultato di controllo, superato o fallito, viene registrato automaticamente in un ActionLog immutabile firmato con la chiave del verificatore stesso.

I dati firmati prevalgono. L'ambito e l'hash del programma della ricevuta firmata prevalgono sempre sui metadati del log dell'operatore. Se i metadati non firmati di DelegationLog sono in disaccordo con la ricevuta firmata, il gate nega l'azione (SCOPE_METADATA_MISMATCH / PROGRAM_METADATA_MISMATCH). I metadati del log sono un fallback solo quando la ricevuta non contiene alcun ambito strutturato o valore executes firmato.

La delega guidata è guidata dall'osservazione. ScopeDiscovery.guided() e AuthProofClient.delegateGuided() eseguono observe → generateScope → approve → finalize in una sola chiamata, e l'intera bozza di ambito osservata viene auto-approvata senza revisione umana. Per un autentico momento di autorizzazione umana, passa l'hook reviewDraft (approva, modifica o rifiuta la bozza prima dell'emissione) oppure esegui i passaggi separatamente con un approve() esplicito.

Integrazioni middleware