### 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/HEAD/src/middleware/langchain.js)** — umschließt jeden Agenten mit einer `invoke()`-Methode
- **[Express/HTTP](https://github.com/commonguy25/authproof-sdk/blob/HEAD/src/middleware/express.js)** — Anfrage-Middleware für jedes Express-kompatible Framework
- **[Generischer Funktionswrapper](https://github.com/commonguy25/authproof-sdk/blob/HEAD/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 })

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** |

`executes` ist die gefährlichste Klasse. Sie muss den kryptografischen Hash des statischen Capability-DAG eines Safescript-Programms referenzieren – nicht einen Namen, URI oder eine Beschreibung. Kein Hash-Match bedeutet keine Ausführung.

### Grenzen (Boundaries)

Explizite Verbote, die unter keinen Umständen durch Operatoranweisungen außer Kraft gesetzt werden können. Vom Benutzer definierte harte Grenzen, die jede nachfolgende Operatoranweisung überdauern.

### Zeitfenster (Time Window)

Gültigkeitsdauer der Autorisierung. Der **Log-Zeitstempel** ist die Zeitquelle – nicht die Client-Uhr. Client-Uhren werden explizit von der Zeitvalidierung ausgeschlossen.

### Operator-Anweisungs-Hash (Operator Instruction Hash)

Ein kryptografischer Hash der vom Operator zum Zeitpunkt der Delegation angegebenen Anweisungen. Wenn der Operator den Agenten anschließend anders anweist, ist die Abweichung aus dem Log erkennbar, ohne dass zusätzliche Vertrauensannahmen erforderlich sind.

Der Benutzer signiert dieses Objekt mit seinem privaten Schlüssel über **WebAuthn/FIDO2 unter Verwendung der sicheren Enklave des Geräts**. Die Signatur wird vor jeder Agentenaktion im Log veröffentlicht. Jede nachfolgende Agentenaktion referenziert den Beleg-Hash. Aktionen außerhalb des Umfangs sind kryptografisch ungültig.

---

## Vertrauensstapel-Architektur (Trust Stack Architecture)

Drei Protokollschichten eliminieren drei vertrauenswürdige Dritte:

### Schicht 1 – Signiertes Capability-Manifest *(entfernt Vertrauen in die Registrierung)*

Im aktuellen MCP-Ökosystem gibt es keine kryptografische Bestätigung, dass die Beschreibungen eines Tool-Servers mit dem übereinstimmen, was er tatsächlich tut. Ein Operator kann ein beliebiges Schema präsentieren.

Die Lösung: Tool-Server veröffentlichen ein **kryptografisch signiertes Capability-Manifest**, bevor eine Benutzerautorisierung erfolgt. Das Feld `scope` des Delegationsbelegs referenziert den **Hash dieses Manifests** – nicht das selbstberichtete Schema des Operators. Abweichungen zwischen Serververhalten und Manifest sind auf der Log-Ebene erkennbar.

### Schicht 2 – Delegationsbeleg *(entfernt Vertrauen in den Operator)*

Die ursprüngliche Absicht des Benutzers wird unveränderlich aufgezeichnet, bevor Operatoranweisungen den Agenten erreichen. Abweichungen des Operators sind nachweisbar.

### Schicht 3 – Safescript-Ausführung *(entfernt Vertrauen in den Code)*

[Safescript](https://github.com/safescript) ist eine quelloffene, sandboxed Sprache für die Ausführung von KI-Agenten. Ihre statische DAG-Struktur bedeutet, dass die vollständige Capability-Signatur jedes Programms berechnet werden kann, bevor es ausgeführt wird – keine dynamische Dispatch, keine Laufzeit-Capability-Erweiterung.

Die `executes`-Umfangsklasse referenziert einen bestimmten Safescript-Capability-Signatur-Hash. Wenn das vom Operator bereitgestellte Programm nicht dem festgelegten Hash entspricht, wird die Ausführung blockiert. Der Agent kann nach der Delegation nicht durch ein anderes Programm ersetzt werden.

---

## Schnellstart (Quick Start)

---```js
import { AuthProof, Scope, KeyCustody } from 'authproof-sdk';

// Initialize with hardware-backed key custody (recommended)
const authproof = new AuthProof({
  custody: KeyCustody.HARDWARE, // WebAuthn/FIDO2 via device secure enclave
  log: 'https://log.authproof.dev',
});

// Define permitted operations — explicit allowlist, deny-by-default
const scope = new Scope()
  .allow('reads',  ['resource://calendar/events', 'resource://email/inbox'])
  .allow('writes', ['resource://calendar/events'])
  .deny('deletes', '*')
  .execute('sha256:a3f1c9d8...', { program: 'scheduler-v1.sg' }); // Safescript hash

// Hard limits that survive any operator instruction
const boundaries = {
  never: ['external-network', 'credential-store', 'payment-methods'],
};

// Issue the Delegation Receipt — anchored to log before any agent action
const receipt = await authproof.delegate({
  scope,
  boundaries,
  window: { duration: '8h' },           // validated against log timestamp
  operatorInstructions: instructionText, // hashed and committed
});

// receipt.id    — unique receipt identifier
// receipt.hash  — reference in every agent action
// receipt.log   — append-only log anchor

// Agent-side: validate an action against the receipt
const check = await authproof.validate({
  receiptHash: receipt.hash,
  action: { class: 'writes', resource: 'resource://calendar/events' },
});

if (!check.authorized) {
  // Out-of-scope action: surface a micro-receipt request to the user
  const microReceipt = await authproof.requestMicroReceipt({
    action: check.requestedAction,
    parent: receipt.hash,
  });
}

### Action Log API

| Methode | Beschreibung |
|---|---|
| `new ActionLog()` | Erstellt eine neue Log-Instanz. Der Zustand befindet sich im Arbeitsspeicher. |
| `log.init({ privateKey, publicJwk })` | Initialisiert mit dem ECDSA P-256-Schlüssel des Agenten. Erforderlich vor `record()`. |
| `log.registerReceipt(receiptHash, receipt)` | Registriert eine Quittung für den Bereichsvergleich. Erforderlich vor `diff()`. |
| `log.record(receiptHash, action)` | Hängt einen signierten, verketteten Eintrag an. Gibt den versiegelten Eintrag zurück. |
| `log.verify(entryId)` | Überprüft die Signatur und Kettenposition eines Eintrags. Gibt `{ valid, reason }` zurück. |
| `log.getEntries(receiptHash)` | Alle Einträge für eine Quittung in chronologischer Reihenfolge. |
| `log.diff(receiptHash)` | Vergleicht alle Einträge mit dem Bereich der Quittung. Gibt `{ compliant, violations, clean }` zurück. |

### Produktionswarnung

Zeitstempel in v1 verwenden die Client-Uhr. Für Compliance- oder rechtliche Kontexte, in denen Zeitstempel unabhängig überprüfbar sein müssen, ersetzen Sie diese vor dem Einsatz in der Produktion durch eine vertrauenswürdige RFC-3161-Zeitstempelbehörde.

### Wichtig

Definieren Sie den Bereich immer mit expliziten `allowedActions`-Arrays. Die textbasierte Bereichsübereinstimmung ist nur für die Entwicklung verfügbar und für Produktions- oder Compliance-Kontexte nicht geeignet.

---

## Vertrauliche Bereitstellung

Führen Sie AuthProof-Agenten in hardware-attestierten Trusted Execution Environments (TEEs) aus. Die Klasse `ConfidentialRuntime` bindet Delegationsbelege an Enklavenmessungen, sodass jede Substitution von Modellgewichten, Verifiziercode oder Plattform vor der Ausführung erkennbar ist.

### Hardwareanforderungen

- **Intel TDX** – Intel Ice Lake Xeon oder neuer (4. Generation Xeon Scalable). Azure DCdsv3-Serie, GCP C3 Confidential VMs.
- **AMD SEV-SNP** – AMD EPYC der 3. Generation (Milan) oder neuer. Azure DCasv5-Serie, AWS m6a mit Nitro Enclaves.

### Erstellen eines Belegs mit TEE-Messungsbindung```javascript
import { AuthProofClient } from 'authproof-sdk';

const client = new AuthProofClient();
const { receipt } = await client.delegate({
  scope: 'Summarize calendar events',
  operatorInstructions: 'Stay within scope.',
  expiresIn: '2h',
  privateKey,
  publicJwk,
  teeConfig: {
    platform:     'intel-tdx',
    verifierHash: verifierCodeHash,   // SHA-256 of your verifier binary
    modelHash:    modelWeightsHash,   // SHA-256 of model weights
  },
});
// receipt.teeMeasurement.expectedMrenclave is now bound to the receipt

Azure SKU-Anforderungen: `Standard_DC4ds_v3` oder größer aus der DCdsv3-Serie. Aktivieren Sie die vertrauliche OS-Datenträgerverschlüsselung. Verwenden Sie den gemeinsamen Endpunkt von Microsoft Azure Attestation (MAA) zur Zitatüberprüfung.

### Bereitstellen auf AWS Nitro Enclaves```javascript
const config = ConfidentialRuntime.awsNitroConfig({
  receiptHash,
  verifierHash,
  modelHash,
  region: 'us-east-1',
});
// config.instanceType === 'c6a.xlarge'
// config.enclaveOptions.enabled === true
// config.pcr0 is the combined receipt+verifier+model measurement

Anwenden mit `kubectl apply -f` nach der Serialisierung in YAML. Der Node-Selektor `intel.feature.node.kubernetes.io/tdx: "true"` erfordert das Intel Device Plugin für Kubernetes.

### eBPF-Kernelmodul — Hilfe gesucht

Die TEE-Durchsetzungsschicht ist auf der Userspace-Seite vollständig (`ConfidentialRuntime`, `TokenPreparer`). Der letzte Durchsetzungsschritt – das Validieren des signierten Fähigkeitstokens bei jedem Syscall über einen eBPF-LSM-Hook – erfordert ein Kernelmodul, das für Beiträge offen ist.

Ingenieure mit eBPF-LSM-Erfahrung (Isovalent, Red Canary oder ähnlich) sind besonders willkommen. Eröffnen Sie ein Issue oder einen PR unter https://github.com/Commonguy25/authproof-sdk/issues

---

## Beispiele

Zwei ausführbare Beispiele befinden sich im Verzeichnis `examples/`.

**[`examples/langchain-example.js`](https://github.com/commonguy25/authproof-sdk/blob/HEAD/examples/langchain-example.js)** – Zeigt den vollständigen LangChain-Integrationspfad: Erzeuge ein Schlüsselpaar, stelle eine Delegationsquittung aus, initialisiere `PreExecutionVerifier` und umschließe jeden Agenten mit `authproofMiddleware`, sodass jeder `invoke()`-Aufruf blockiert wird, bevor die Agentenlaufzeit die Kontrolle erhält. Enthält einen Mock-Agenten, den Sie sofort ausführen können, und das exakte Code-Muster für einen echten `AgentExecutor`. Führen Sie es mit `npm run example:langchain` aus.

**[`examples/webauthn-example.html`](https://github.com/commonguy25/authproof-sdk/blob/HEAD/examples/webauthn-example.html)** – Eine eigenständige Drei-Karten-Browser-Demo des vollständigen Delegationsablaufs. Karte 1 ermöglicht die Definition von Umfang, Grenzen und Bedieneranweisungen und signiert dann eine Quittung mit einem lokalen Schlüssel (ersetzen Sie `navigator.credentials` für echtes WebAuthn). Karte 2 zeigt die Quittungs-ID, das Ablaufdatum, den Systemprompt und das rohe JSON an. Karte 3 ermöglicht es Ihnen, eine beliebige vorgeschlagene Aktion einzugeben und in Echtzeit gegen die Quittung zu überprüfen, wobei jedes Prüfergebnis angezeigt wird. Direkt im Browser öffnen – kein Build-Schritt erforderlich.

---

## Installation```bash
npm install authproof-sdk