SDK AuthProof

AuthProof est une couche d'audit et d'attribution pour les agents IA. Il vous permet de prouver ce qu'un utilisateur a autorisé avant que l'agent n'agisse, et il enregistre ce que l'agent a réellement fait par rapport à cette autorisation.

Le mécanisme est simple. L'utilisateur signe un reçu de délégation avec sa propre clé privée. Le reçu porte la portée, les limites, les instructions de l'opérateur (hachées) et une fenêtre temporelle. Un vérificateur pré-exécution contrôle chaque action proposée par rapport au reçu, et un journal d'actions en ajout seul enregistre ce qui a été exécuté. Le résultat est une preuve : ce qui a été autorisé, comparé à ce qui s'est produit.

Ce n'est pas un contrôle de sécurité contre un opérateur malveillant. Le vérificateur s'exécute dans le même processus que l'agent, et un opérateur malhonnête peut simplement ne pas l'appeler. Aucune propriété cryptographique ne peut corriger cela depuis l'intérieur du même runtime. AuthProof prouve l'autorisation pour les déploiements qui exécutent le portail, et il donne aux auditeurs, aux régulateurs et aux utilisateurs un enregistrement qu'ils peuvent vérifier après coup.

Ce qui le rend différent :

• L'utilisateur est l'autorité de signature. L'objet d'autorisation est signé avec la clé privée de l'utilisateur, et non écrit dans une politique gérée par l'opérateur. La portée signée et le hachage du programme dans le reçu l'emportent toujours sur les métadonnées du journal de l'opérateur. Si les métadonnées de l'opérateur entrent en conflit avec le reçu signé, le portail refuse l'action au lieu de suivre les métadonnées.

• Engagement d'état du modèle en deux phases. Le modèle est mesuré au moment de l'autorisation et re-mesuré avant l'exécution. Ces mesures sont calculées par logiciel et auto-attestées, non ancrées dans le matériel. Elles constituent une preuve d'altération pour les déploiements honnêtes, pas une preuve contre un hôte hostile.

• Mise à jour du fournisseur versus substitution malveillante, distinguées. Les changements d'état du modèle se classent en mises à jour légitimes du fournisseur (PROVIDER_UPDATE_REQUIRES_REAUTH) et en substitutions non autorisées (MALICIOUS_MODEL_SUBSTITUTION). Chacune produit un code de motif de refus lisible par machine identifiant les composants qui ont changé.

Vérificateur pré-exécution

Le portail qui s'exécute avant toute action de l'agent.

PreExecutionVerifier.check() vérifie chaque action proposée par rapport au reçu de délégation signé. Faites passer chaque action par celui-ci dans le processus de votre agent, avant que l'action ne s'exécute. Le vérificateur signe ses propres décisions d'autorisation/refus dans un journal d'audit, de sorte que chaque résultat fait partie de l'enregistrement.

Une vérité difficile à intégrer : le vérificateur est dans le même processus. Il vérifie la preuve ; il ne peut pas arrêter un opérateur qui refuse de l'appeler. Utilisez-le là où vous voulez des preuves, pas là où vous avez besoin d'une application contre l'opérateur qui exécute le code.

Pourquoi c'est important

La plupart des autorisations d'agents aujourd'hui reposent sur la parole de l'opérateur : une politique que l'opérateur a écrite, appliquée par du code que l'opérateur contrôle. Quand quelque chose tourne mal, il n'y a aucun enregistrement de ce que l'utilisateur a réellement autorisé, seulement la reconstruction qu'en fait l'opérateur. AuthProof inverse cela. Le reçu signé de l'utilisateur précède l'exécution, et le journal d'actions enregistre ce qui a été exécuté par rapport à celui-ci. La question « l'utilisateur a-t-il autorisé ceci ? » devient vérifiable au lieu d'être discutable.

Démarrage rapide

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

Treize vérifications séquentielles (s'arrête à la première défaillance)

#	Vérification	Bloque lorsque
1	Signature du reçu	Signature ECDSA P-256 invalide ou reçu altéré
2	Révocation	Le reçu a été révoqué via RevocationRegistry (cascade : un ancêtre révoqué invalide ses descendants)
3	Fenêtre temporelle	Reçu expiré ou pas encore valide (oracle d'horodatage du journal, pas l'horloge du client)
4	Portée	Action absente de ScopeSchema.allowedActions ; sans schéma structuré, la correspondance par mots-clés est purement indicative et ne bloque jamais
5	Instructions de l'opérateur	Les instructions fournies ne correspondent pas au hachage verrouillé dans le reçu à l'émission ; ignoré avec un avertissement lorsque l'appelant les omet
6	Hachage du programme	Le programHash fourni ne correspond pas au hachage executes engagé (optionnel)
7	Risque de session	Seuils de confiance/risque dépassés (optionnel)
8	Intégrité du schéma d'outil	toolSchemaHash ne correspond pas au reçu (optionnel)
9	État du modèle	Dérive du modèle détectée (optionnel ; mesure calculée par logiciel, auto-attestée)
10	Liaison du hachage de sortie d'outil	Le hachage de sortie ne correspond pas au reçu (optionnel)
11	Provenance des instructions	Source d'instruction absente des trustedSources du reçu (optionnel)
14	Confinement de portée parente	Le sous-reçu dépasse la portée du parent (sous-reçus uniquement) ; révoquer un ancêtre quelconque invalide l'enfant au moment de la vérification
15	Dérive de l'état d'autorité	authorityStateCommitment a dérivé depuis l'émission (optionnel)

Les emplacements 12 et 13 n'ont jamais été implémentés ; l'écart de numérotation est historique. Le portail s'arrête à la première vérification échouée. La consommation à usage unique s'exécute en dernier, après que toutes les vérifications ont réussi, de sorte qu'un emplacement de consommation n'est jamais brûlé sur un reçu qui serait refusé pour une autre raison.

Chaque résultat de vérification, réussi ou échoué, est automatiquement journalisé dans un ActionLog immuable signé avec la propre clé du vérificateur.

Les données signées prévalent. La portée et le hachage du programme du reçu signé prévalent toujours sur les métadonnées du journal de l'opérateur. Si les métadonnées non signées de DelegationLog sont en désaccord avec le reçu signé, le portail refuse l'action (SCOPE_METADATA_MISMATCH / PROGRAM_METADATA_MISMATCH). Les métadonnées du journal ne servent de repli que lorsque le reçu ne porte aucune portée structurée ni valeur executes signée.

La délégation guidée est guidée par l'observation. ScopeDiscovery.guided() et AuthProofClient.delegateGuided() exécutent observe → generateScope → approve → finalize en un seul appel, et l'intégralité de la portée brouillon observée est auto-approuvée sans revue humaine. Pour un véritable moment d'autorisation humaine, passez le hook reviewDraft (approuver, modifier ou refuser le brouillon avant l'émission) ou exécutez les étapes séparément avec un approve() explicite.

Intégrations de middleware