commonguy25/authproof-sdkKryptografisch signierte Delegationsbelege für KI-Agenten. Legen Sie genau fest, was eine KI darf und nicht darf — signiert, überprüfbar, manipulationssicher.
AuthProof ist ein kryptografisches Delegationsprotokoll für agentische KI. Die meisten Protokolle in diesem Bereich setzen gegen eine vom Betreiber definierte Richtlinie durch – was dem Betreiber die Befugnis gibt, die ursprüngliche Absicht des Benutzers nachträglich zu erweitern oder neu zu interpretieren. AuthProof basiert auf einem anderen Vertrauensmodell: Der private Schlüssel des Benutzers signiert das Autorisierungsobjekt, das die Ausführung steuert, und der Live-Modellzustand wird sowohl zum Zeitpunkt der Autorisierung als auch unmittelbar vor der Ausführung verifiziert. Die Kombination aus benutzersignierter Autorisierung und Live-Modellzustandssteuerung ist die spezifische Behauptung – nicht eine breite Durchsetzungsgeschichte.
Was es anders macht:
Der Benutzer ist die signierende Instanz. Jedes konkurrierende Protokoll (AIP, AITH, OAP, SAGA, AgentSpec) setzt gegen eine vom Betreiber definierte Richtlinie durch. Bei AuthProof signiert der private Schlüssel des Benutzers direkt das Autorisierungsobjekt. Der Betreiber kann den Umfang nach der Signierung durch den Benutzer nicht erweitern.
Zweiphasige Modellzustandsbindung. Das Modell wird zum Zeitpunkt der Autorisierung gemessen und unmittelbar vor der Ausführung erneut gemessen. Wenn das Modell zwischen diesen beiden Zeitpunkten abgedriftet ist, wird die Ausführung bei der Vorausführungsprüfung blockiert.
Anbieteraktualisierung vs. böswillige Ersetzung, unterschieden. Das Protokoll klassifiziert Änderungen des Modellzustands in zwei Kategorien: legitime Anbieteraktualisierungen (PROVIDER_UPDATE_REQUIRES_REAUTH) und nicht autorisierte Austausche (MALICIOUS_MODEL_SUBSTITUTION). Jede erzeugt einen maschinenlesbaren Ablehnungsgrundcode, der angibt, welche Komponenten geändert wurden.
Das deterministische Tor, das vor der Ausführung einer Agentenaktion läuft.
Der PreExecutionVerifier sitzt außerhalb der Agenten-Laufzeitumgebung. Die Laufzeitumgebung erhält erst die Kontrolle, wenn der Prüfer bestanden wurde. Ein kompromittierter oder bösartiger Agent kann ihn nicht umgehen – er läuft, bevor die Laufzeitumgebung startet.
Traditionelle Autorisierungsprüfungen finden innerhalb der Agenten-Laufzeitumgebung statt. Wenn die Laufzeitumgebung kompromittiert ist, können diese Prüfungen übersprungen, neu angeordnet oder umgangen werden. PreExecutionVerifier eliminiert diese Angriffsfläche, indem er die Autorisierung vollständig außerhalb der Laufzeitumgebung durchführt. Der Agent führt nur aus, wenn – und nur wenn – alle sechs aufeinanderfolgenden Prüfungen zuerst bestanden werden.
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
### Sechs sequentielle Prüfungen (stoppt bei erstem Fehler)
| # | Prüfung | Blockiert wenn |
|---|---------|---------------|
| 1 | Quittungssignatur | ECDSA P-256-Signatur ungültig oder Quittung manipuliert |
| 2 | Widerruf | Quittung wurde über `RevocationRegistry` widerrufen |
| 3 | Zeitfenster | Quittung abgelaufen oder noch nicht gültig (Log-Zeitstempel-Orakel, nicht Client-Uhr) |
| 4 | Umfang | Aktion nicht in `ScopeSchema.allowedActions` oder scheitert an textbasierter Bereichsabstimmung |
| 5 | Anweisungen des Betreibers | Aktuelle Anweisungen stimmen nicht mit dem bei Ausstellung in der Quittung gesperrten Hash überein |
| 6 | Programm-Hash | Bereitgestellter `programHash` stimmt nicht mit dem festgelegten `executes`-Hash überein (Code-Ersetzungsprävention) |
Jedes Prüfergebnis – bestanden oder nicht bestanden – wird automatisch in einem unveränderlichen `ActionLog` protokolliert, der mit dem eigenen Schlüssel des Prüfers signiert ist.
### Middleware-Integrationen
Einsatzbereite Wrapper für gängige Frameworks. Jeder Wrapper leitet jeden Aufruf durch `PreExecutionVerifier`, bevor der umschlossene Code ausgeführt wird.
- **[LangChain](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/langchain.js)** — umschließt jeden Agenten mit einer `invoke()`-Methode
- **[Express/HTTP](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/express.js)** — Anfrage-Middleware für jedes Express-kompatible Framework
- **[Generischer Funktionswrapper](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/generic.js)** — umschließt jede asynchrone Funktion```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 })
Jedes bestehende IETF-Framework für Agentenidentität â AIP, draft-klrc-aiagent-auth, WIMSE â befasst sich mit Service-zu-Agenten-Vertrauen: wie ein nachgelagerter Dienst überprüft, ob ein Agent berechtigt ist, ihn aufzurufen. Keines von ihnen adressiert Benutzer-zu-Betreiber-Vertrauen.
Die Delegationskette in aktuellen agentischen Systemen ist:``` User â Operator â Agent â Services
Der Benutzer weist den Operator an. Der Operator weist den Agenten an. Aber es existiert zum Zeitpunkt der Delegation kein kryptografischer Nachweis über die ursprüngliche Absicht des Benutzers. Der Operator wird zu einem vertrauenswürdigen Dritten mit unkontrollierter Befugnis, die Anweisungen des Benutzers zu erweitern, zu verzerren oder zu unterlassen, bevor sie den Agenten erreichen.
Die Konsequenzen:
- Benutzer können nicht beweisen, was sie autorisiert haben.
- Aufsichtsbehörden haben keine Prüfpfad.
- Gerichte haben keine Beweiskette.
- Agenten können legitime Operatoranweisungen nicht von kompromittierten oder böswilligen unterscheiden.
AuthProof schließt diese Lücke.
---
## Das Kern-Primitiv: Delegationsbeleg
Ein **Delegationsbeleg** ist ein signiertes Autorisierungsobjekt, das in einem dezentralen Append-Only-Log verankert wird, bevor eine Agentenaktion beginnt. Es enthält vier erforderliche Felder:
### Umfang (Scope)
Eine explizite Positivliste erlaubter Operationen. Alles, was nicht aufgeführt ist, ist standardmäßig verweigert. Ausgedrückt in strukturiertem Format – nicht in natürlicher Sprache. Operationsklassen:
| Klasse | Beschreibung |
|---|---|
| `reads` | Lesezugriff auf bestimmte Ressourcen |
| `writes` | Schreibzugriff auf bestimmte Ressourcen |
| `deletes` | Löschen bestimmter Ressourcen |
| `executes` | Ausführung eines bestimmten Programms, referenziert durch seinen **statischen Capability-Signatur-Hash** |