AuthProof SDK

AuthProof ist eine Audit- und Attributionsschicht für KI-Agenten. Sie ermöglicht es dir zu beweisen, was ein Benutzer autorisiert hat, bevor der Agent gehandelt hat, und sie zeichnet auf, was der Agent tatsächlich gegen diese Autorisierung ausgeführt hat.

Der Mechanismus ist einfach. Der Benutzer signiert eine Delegationsquittung mit seinem eigenen privaten Schlüssel. Die Quittung enthält Umfang, Grenzen, Betreiberanweisungen (gehasht) und ein Zeitfenster. Ein Verifizierer vor der Ausführung prüft jede vorgeschlagene Aktion gegen die Quittung, und ein append-only Aktionsprotokoll zeichnet auf, was ausgeführt wurde. Das Ergebnis sind Beweise: was autorisiert wurde, abgeglichen mit dem, was passiert ist.

Dies ist keine Sicherheitskontrolle gegen einen böswilligen Betreiber. Der Verifizierer läuft im selben Prozess wie der Agent, und ein unehrlicher Betreiber kann ihn einfach nicht aufrufen. Keine kryptografische Eigenschaft kann das von innerhalb derselben Laufzeitumgebung beheben. AuthProof beweist die Autorisierung für Bereitstellungen, die das Gate ausführen, und es gibt Auditoren, Regulierungsbehörden und Benutzern eine Aufzeichnung, die sie im Nachhinein überprüfen können.

Was es anders macht:

• Der Benutzer ist die signierende Autorität. Das Autorisierungsobjekt wird mit dem privaten Schlüssel des Benutzers signiert, nicht in eine vom Betreiber verwaltete Richtlinie geschrieben. Der signierte Umfang und der Programm-Hash in der Quittung gewinnen immer über die Betreiber-Log-Metadaten. Wenn Betreiber-Metadaten mit der signierten Quittung in Konflikt stehen, verweigert das Gate die Aktion, anstatt den Metadaten zu folgen.

• Zweiphasige Modellzustands-Commitment. Das Modell wird zum Autorisierungszeitpunkt gemessen und vor der Ausführung erneut gemessen. Diese Messungen werden softwarebasiert berechnet und selbst-attestiert, nicht hardware-verankert. Sie sind Manipulationsnachweis für ehrliche Bereitstellungen, kein Beweis gegen einen feindseligen Host.

• Anbieter-Update versus böswillige Substitution, unterschieden. Modellzustandsänderungen klassifizieren sich in legitime Anbieter-Updates (PROVIDER_UPDATE_REQUIRES_REAUTH) und unbefugte Austausche (MALICIOUS_MODEL_SUBSTITUTION). Jede erzeugt einen maschinenlesbaren Ablehnungsgrundcode, der angibt, welche Komponenten sich geändert haben.

Pre-Execution Verifier

Das Gate, das vor der Ausführung jeder Agentenaktion läuft.

PreExecutionVerifier.check() verifiziert jede vorgeschlagene Aktion gegen die signierte Delegationsquittung. Leite jede Aktion durch ihn im Prozess deines Agenten, bevor die Aktion ausgeführt wird. Der Verifizierer signiert seine eigenen Erlauben/Verweigern-Entscheidungen in ein Audit-Log, sodass jedes Ergebnis Teil der Aufzeichnung ist.

Eine harte Wahrheit, um die herum man bauen muss: Der Verifizierer läuft im selben Prozess. Er verifiziert Beweise; er kann einen Betreiber nicht stoppen, der sich weigert, ihn aufzurufen. Verwende ihn dort, wo du Beweise willst, nicht dort, wo du Durchsetzung gegen den Betreiber benötigst, der den Code ausführt.

Warum es wichtig ist

Die meiste Agentenautorisierung heute ist das Wort des Betreibers: eine Richtlinie, die der Betreiber geschrieben hat, durchgesetzt durch Code, den der Betreiber kontrolliert. Wenn etwas schiefgeht, gibt es keine Aufzeichnung darüber, was der Benutzer tatsächlich autorisiert hat, nur die Rekonstruktion des Betreibers davon. AuthProof dreht das um. Die signierte Quittung des Benutzers datiert vor der Ausführung, und das Aktionsprotokoll zeichnet auf, was dagegen ausgeführt wurde. Die Frage „Hat der Benutzer dies autorisiert?“ wird überprüfbar statt diskutierbar.

Quickstart

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

Dreizehn aufeinanderfolgende Prüfungen (stoppt beim ersten Fehler)

#	Prüfung	Blockiert, wenn
1	Receipt-Signatur	ECDSA-P-256-Signatur ungültig oder Receipt manipuliert
2	Widerruf	Receipt wurde über RevocationRegistry widerrufen (Kaskade: ein widerrufener Vorfahre verweigert seinen Nachkommen)
3	Zeitfenster	Receipt abgelaufen oder noch nicht gültig (Log-Zeitstempel-Orakel, nicht Client-Uhr)
4	Geltungsbereich	Aktion nicht in ScopeSchema.allowedActions; ohne strukturiertes Schema ist Keyword-Matching nur beratend und blockiert nie
5	Operator-Anweisungen	Bereitgestellte Anweisungen stimmen nicht mit dem bei der Ausstellung im Receipt verankerten Hash überein; wird mit einer Warnung übersprungen, wenn der Aufrufer sie weglässt
6	Programm-Hash	Bereitgestellter programHash stimmt nicht mit dem festgeschriebenen executes-Hash überein (optional)
7	Sitzungsrisiko	Trust-/Risk-Schwellenwerte überschritten (optional)
8	Tool-Schema-Integrität	toolSchemaHash stimmt nicht mit dem Receipt überein (optional)
9	Modellzustand	Modelldrift erkannt (optional; softwareberechnete, selbstbestätigte Messung)
10	Tool-Output-Hash-Bindung	Output-Hash stimmt nicht mit dem Receipt überein (optional)
11	Instruktions-Herkunft	Instruktionsquelle nicht in den trustedSources des Receipts (optional)
14	Übergeordnete Scope-Eingrenzung	Sub-Receipt überschreitet den Scope des übergeordneten Receipts (nur Sub-Receipts); das Widerrufen eines beliebigen Vorfahren verweigert dem Kind zum Prüfzeitpunkt
15	Authority-State-Drift	authorityStateCommitment hat sich seit der Ausstellung verändert (optional)

Die Slots 12 und 13 wurden nie implementiert; die Nummerierungslücke ist historisch. Das Gate stoppt bei der ersten fehlgeschlagenen Prüfung. Die Einmalverbrauchs-Abrechnung läuft zuletzt, nachdem alle Prüfungen bestanden wurden, sodass ein Verbrauchsslot nie für ein Receipt verbraucht wird, das aus einem anderen Grund verweigert würde.

Jedes Prüfergebnis, ob bestanden oder fehlgeschlagen, wird automatisch in einem unveränderlichen ActionLog protokolliert, das mit dem eigenen Schlüssel des Verifiers signiert ist.

Signierte Daten gewinnen. Der Scope und der Programm-Hash des signierten Receipts gewinnen immer über Operator-Log-Metadaten. Wenn unsignierte DelegationLog-Metadaten nicht mit dem signierten Receipt übereinstimmen, verweigert das Gate die Aktion (SCOPE_METADATA_MISMATCH / PROGRAM_METADATA_MISMATCH). Log-Metadaten sind nur ein Fallback, wenn das Receipt keinen strukturierten Scope oder signierten executes-Wert enthält.

Geführte Delegation wird durch Beobachtung geführt. ScopeDiscovery.guided() und AuthProofClient.delegateGuided() führen observe → generateScope → approve → finalize in einem Aufruf aus, und der vollständige beobachtete Entwurfs-Scope wird automatisch ohne menschliche Prüfung genehmigt. Für einen echten Moment menschlicher Autorisierung übergeben Sie den reviewDraft-Hook (den Entwurf vor der Ausstellung genehmigen, ändern oder ablehnen) oder führen Sie die Schritte separat mit einem expliziten approve() aus.