commonguy25/authproof-sdkReçus de délégation signés cryptographiquement pour les agents IA. Définissez exactement ce qu'une IA peut et ne peut pas faire — signé, vérifiable, inviolable.
AuthProof est un protocole de délégation cryptographique pour l'IA agentique. La plupart des protocoles dans ce domaine appliquent une politique définie par l'opérateur — donnant à l'opérateur l'autorité d'élargir ou de réinterpréter l'intention originale de l'utilisateur après coup. AuthProof est construit autour d'un modèle de confiance différent : la propre clé privée de l'utilisateur signe l'objet d'autorisation qui contrôle l'exécution, et l'état actif du modèle est vérifié à la fois au moment de l'autorisation et immédiatement avant l'exécution. La combinaison de l'autorité signée par l'utilisateur et du contrôle de l'état actif du modèle est la revendication spécifique — et non une vaste histoire d'application.
Ce qui le rend différent :
L'utilisateur est l'autorité de signature. Chaque protocole concurrent (AIP, AITH, OAP, SAGA, AgentSpec) applique une politique définie par l'opérateur. Dans AuthProof, la clé privée de l'utilisateur signe directement l'objet d'autorisation. L'opérateur ne peut pas élargir le périmètre après que l'utilisateur a signé.
Engagement de l'état du modèle en deux phases. Le modèle est mesuré au moment de l'autorisation et remesuré immédiatement avant l'exécution. Si le modèle a dérivé entre ces deux points, l'exécution est bloquée lors de la vérification pré-exécution.
Mise à jour du fournisseur versus substitution malveillante, distinguées. Le protocole classe les changements d'état du modèle en deux catégories : les mises à jour légitimes du fournisseur (PROVIDER_UPDATE_REQUIRES_REAUTH) et les substitutions non autorisées (MALICIOUS_MODEL_SUBSTITUTION). Chacun produit un code de raison de refus lisible par machine identifiant les composants modifiés.
La porte déterministe qui s'exécute avant toute action de l'agent.
Le PreExecutionVerifier se trouve en dehors de l'environnement d'exécution de l'agent. L'environnement d'exécution n'obtient jamais le contrôle tant que le vérificateur n'a pas validé. Un agent compromis ou malveillant ne peut pas le contourner — il s'exécute avant le démarrage de l'environnement d'exécution.
Les vérifications d'autorisation traditionnelles se produisent à l'intérieur de l'environnement d'exécution de l'agent. Si l'environnement d'exécution est compromis, ces vérifications peuvent être ignorées, réordonnées ou contournées. PreExecutionVerifier élimine cette surface d'attaque en déplaçant l'autorisation complètement en dehors de l'environnement d'exécution. L'agent ne s'exécute que si — et seulement si — les six vérifications séquentielles réussissent d'abord.
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
### Six vérifications séquentielles (s'arrête au premier échec)
| # | Vérification | Bloc si |
|---|--------------|---------|
| 1 | Signature du reçu | Signature ECDSA P-256 invalide ou reçu falsifié |
| 2 | Révocation | Le reçu a été révoqué via `RevocationRegistry` |
| 3 | Fenêtre temporelle | Reçu expiré ou pas encore valide (oracle temporel du journal, pas l'horloge client) |
| 4 | Portée | Action non dans `ScopeSchema.allowedActions` ou échoue à la correspondance textuelle de portée |
| 5 | Instructions de l'opérateur | Les instructions actuelles ne correspondent pas au hachage verrouillé dans le reçu lors de l'émission |
| 6 | Hash du programme | Le `programHash` fourni ne correspond pas au hachage `executes` engagé (prévention de substitution de code) |
Chaque résultat de vérification — réussi ou échoué — est automatiquement enregistré dans un `ActionLog` immuable signé avec la propre clé du vérificateur.
### Intégrations middleware
Wrappers prêts à l'emploi pour les frameworks courants. Chaque wrapper protège chaque appel via `PreExecutionVerifier` avant que le code encapsulé ne s'exécute.
- **[LangChain](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/langchain.js)** — encapsule tout agent avec une méthode `invoke()`
- **[Express/HTTP](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/express.js)** — middleware de requête pour tout framework compatible Express
- **[Wrapper de fonction générique](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/generic.js)** — encapsule toute fonction asynchrone```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 })
Chaque framework IETF existant pour l'identité des agents — AIP, draft-klrc-aiagent-auth, WIMSE — traite de la confiance service-agent : comment un service en aval vérifie qu'un agent est autorisé à l'appeler. Aucun d'entre eux ne traite de la confiance utilisateur-opérateur.
La chaîne de délégation dans les systèmes agentiques actuels est :``` User â Operator â Agent â Services
L'utilisateur donne des instructions à l'opérateur. L'opérateur donne des instructions à l'agent. Mais aucun enregistrement cryptographique de l'intention originale de l'utilisateur n'existe au moment de la délégation. L'opérateur devient un tiers de confiance doté d'une autorité sans contrôle pour étendre, déformer ou omettre les instructions de l'utilisateur avant qu'elles n'atteignent l'agent.
Les conséquences :
- Les utilisateurs ne peuvent pas prouver ce qu'ils ont autorisé.
- Les régulateurs n'ont pas de piste d'audit.
- Les tribunaux n'ont pas de chaîne de preuves.
- Les agents ne peuvent pas distinguer les instructions légitimes de l'opérateur de celles compromises ou malveillantes.
AuthProof comble cette lacune.
---
## La primitive fondamentale : Reçu de Délégation
Un **Reçu de Délégation** est un Objet d'Autorisation signé ancré dans un journal décentralisé à ajout seul avant que toute action d'agent ne commence. Il contient quatre champs obligatoires :
### Périmètre
Une liste d'autorisation explicite des opérations permises. Tout ce qui n'est pas listé est refusé par défaut. Exprimé en format structuré — pas en langage naturel. Classes d'opérations :
| Classe | Description |
|---|---|
| `reads` | Accès en lecture aux ressources spécifiées |
| `writes` | Accès en écriture aux ressources spécifiées |
| `deletes` | Suppression des ressources spécifiées |
| `executes` | Exécution d'un programme spécifique, référencé par son **hash de signature de capacité statique** |