zkTLS für KI-Agenten: Webdaten beweisen, Secrets schützen

Mit zkTLS kann ein KI-Agent beweisen, woher private Webdaten stammen, und nur die Felder offenlegen, die ein Verifier braucht. Aus einer authentifizierten HTTPS-Antwort wird etwa der Nachweis „Dieses Konto ist aktiv“ oder „Dieser Kauf wurde abgeschlossen“, ohne Session-Cookie, vollständigen Datensatz oder irrelevante Antwortfelder zu zeigen.

Das Versprechen ist enger als „trustless Agents“, und genau das macht es brauchbar. Die grundlegende DECO-Forschung zeigte, wie sich die Herkunft von TLS-Daten ohne Trusted Hardware und ohne Änderungen an der Quellwebsite beweisen lässt (ACM CCS, 2020). 2026 lautet die kommerzielle Frage nicht mehr, ob Web Proofs möglich sind. Entscheidend ist, ob Restvertrauen, Latenz, Source Drift und Betriebskosten zum Agenten-Workflow passen.

Dieser Guide deckt genau diese Entscheidungsabsicht ab. Den breiteren Stand der Technik erklärt unser Production Guide zu Zero-Knowledge-Proofs 2026. Identität, KYC und Lieferketten behandeln wir separat in den Zero-Knowledge-Anwendungsfällen außerhalb von Krypto.

Du prüfst einen Agenten-Workflow mit privaten Daten?

zkTLS-Architektur scopen

Was ist zkTLS für einen KI-Agenten?

zkTLS bezeichnet eine Familie von Protokollen, die ausgewählte Fakten aus einer HTTPS-Session für eine andere Partei verifizierbar machen. Die Website sieht normalerweise eine gewöhnliche TLS-Verbindung und muss keine neue Attestation API einbauen. TLSNotary, ein Open-Source-Projekt der Privacy Stewards of Ethereum der Ethereum Foundation, beschreibt den Ablauf als Datenabruf durch einen Prover unter Beteiligung eines Verifiers, gefolgt von selektiver Offenlegung und Prüfung (TLSNotary-Dokumentation).

Request: Das Gerät des Nutzers oder der Agent greift auf eine benannte HTTPS-Quelle zu. Authentifizierungsdaten bleiben im privaten Teil des Requests.
Witness: Ein Verifier nimmt per MPC-TLS teil oder beobachtet im Proxy-Modus den verschlüsselten Netzwerkpfad.
Commit: Das Protokoll bindet ausgewählte Request- und Response-Felder an die beobachtete Session.
Disclose: Der Prover zeigt einen Wert, einen redigierten Ausschnitt oder ein abgeleitetes Prädikat und verbirgt den Rest.
Decide: Die Anwendung prüft den Proof oder die Attestierung eines vertrauenswürdigen Notarys, bevor der Agent fortfahren darf.

Die Privacy Boundary muss präzise beschrieben werden: Wenn die Beweiserzeugung auf dem Gerät bleibt, kann zkTLS Credentials vor dem nachgelagerten Verifier verbergen. Vor der lokalen Agent Runtime, Browser Extension oder einer TEE, die den Request ausführt, sind sie nicht automatisch verborgen. Zeichne zuerst ein, wo Plaintext existiert, bevor du die Architektur als privat bezeichnest.

Was kann ein KI-Agent tatsächlich beweisen?

Ein nützlicher zkTLS-Claim bindet eine benannte Quelle, ein konkretes Antwortfeld, ein Subjekt und ein Freshness Window. „Der Agent hat eine Website geprüft“ ist zu ungenau, um Geld oder Datenzugriff freizugeben.

Agenten-Workflow	Nützlicher Proof-Claim	Was unbewiesen bleibt
Berechtigungsprüfung	Ein benanntes Konto lieferte zu einem begrenzten Zeitpunkt den Status aktiv	Ob die Policy der Quelle fair oder rechtlich ausreichend ist
Kauf oder Buchung	Die Händlerantwort enthält die erwartete Order-ID und den Status abgeschlossen	Lieferqualität, Refunds oder ob der Agent das beste Angebot gewählt hat
Finanzsignal	Ein Saldo- oder Einkommensfeld erfüllt einen Grenzwert, ohne den Rohwert zu zeigen	Ob der Datensatz nach dem Proof-Zeitpunkt noch aktuell ist
Agent Tool Result	Ein Tool erhielt eine bestimmte Antwort von einem bestimmten HTTPS-Origin	Ob das Modell die Antwort richtig interpretiert hat
Action Receipt	Ein Remote Service bestätigte die angeforderte Zustandsänderung	Ob der Nutzer sie autorisiert hat oder alle Side Effects abgeschlossen sind

Die letzte Spalte ist die Produktgrenze. zkTLS beweist Transcript Provenance und korrekte Offenlegung. Es macht eine schlechte Quelle nicht wahr, eine alte Seite nicht frisch, einen Prompt nicht sicher und eine Agentenentscheidung nicht richtig.

Ist zkTLS trustless oder öffentlich verifizierbar?

Kein portabler zkTLS-Claim kommt ganz ohne Vertrauen aus. Ein Verifier muss während der TLS-Session beteiligt sein. Sonst kennt der Client die symmetrischen Session Keys und könnte ein Transcript erfinden. Ist dein Backend online und übernimmt selbst diese Rolle, kann es das Ergebnis direkt akzeptieren. Brauchen ein Smart Contract, ein späterer Prüfer oder viele Empfänger das Ergebnis, signiert ein delegierter Verifier eine Attestierung. Diese Empfänger vertrauen dem Notary.

Die TLSNotary-Erklärung vom Juni 2026 nennt das eine Designated-Verifier-Grenze: Zero Knowledge schützt die selektive Offenlegung und verhindert manipulierte Ausschnitte. Ein Nichtteilnehmer verlässt sich trotzdem auf die Partei, die die Live-Session beobachtet hat (TLSNotary, Juni 2026). Notary Key, Quorum, Widerruf und Audit Trail sind Production Infrastructure, keine belanglosen SDK-Defaults.

Warum ist zkTLS gerade jetzt relevant?

Drei Veränderungen machen das Thema 2026 für Agenten-Teams aktuell:

Aus Identity Proofs werden Action Receipts. Agenten lesen authentifizierte Dashboards, rufen bezahlte APIs ab, buchen Services und ändern externen Zustand. Eine verifizierbare Antwort kann Settlement oder Freigabe auslösen.
Browser- und Proxy-Pfade senken die Integrationshürde. Proofs entstehen nahe an der authentifizierten Nutzer-Session, statt Credentials in einen zentralen Scraper zu verschieben.
Die Trade-offs sind messbar. TLSNotary veröffentlicht reproduzierbare Harness-Daten und bietet MPC- und Proxy-Modus.

Momentum ist nicht Reife. Zum Review am 11. August 2026 ist das aktuelle GitHub-Release von TLSNotary v0.1.0-alpha.15 und ausdrücklich als Pre-Release markiert (offizielle Release Notes). Pinne Versionen, führe ein eigenes Security Review durch und isoliere die Migrationsgrenzen für Prover, Verifier, Parser und Attestierungsformat.

Welche zkTLS-Architektur solltest du wählen?

Pattern	Beste Eignung	Hauptkosten oder Vertrauen
Direkter MPC-TLS-Verifier	Dein Backend ist online, der Claim ist kritisch und die Quelle könnte Datacenter-IPs blockieren	Mehr Runden und Bandbreite; der Verifier muss live teilnehmen
Delegierter MPC-Notary	Der Proof muss für Offline-Systeme oder mehrere Empfänger portabel sein	Jeder Empfänger vertraut der Notary-Signatur; bei hohem Risiko ist ein Quorum sinnvoll
Proxy-Modus	Browser UX und Latenz zählen, und du kontrollierst den Verifier	Zusätzliche Annahme über den Netzwerkpfad; die IP des Verifiers erreicht die Quelle
TEE-Attestor	Subsekunden-UX dominiert und Hardware Trust ist akzeptabel	Credentials und Plaintext können in der Enclave existieren; Privacy hängt an Attestation
Signierte First-Party-API	Die Quelle kooperiert und kann stabile, begrenzte Antworten signieren	Meist einfacher als zkTLS; abhängig von Key und Verfügbarkeit der Quelle

Offizielle TLSNotary-Benchmarks vom Mai 2026 maßen für einen kleinen Request mit 1 KB und eine Response mit 2 KB im Proxy-Modus 1,0 bis 2,0 Sekunden. Im MPC-Modus waren es über die getesteten nativen und Browser-Netzwerkprofile 3,6 bis 15,5 Sekunden (TLSNotary Benchmark Harness). Das sind vom Projekt gepflegte Referenzwerte, nicht dein SLA. Response-Größe, Redaction Logic, Gerät, Netzwerk, Source Behaviour und Proof Statement verändern das Ergebnis.

Was bricht in Produktion?

Source Drift: Ein anderer JSON Path, Redirect, Kompressionsmodus, Anti-Bot-Rule oder A/B-Test kann die Extraktion brechen, obwohl die fachliche Bedeutung gleich bleibt.
Replay: Ein alter gültiger Proof ist gefährlich, wenn der Verifier keine passende Nonce, Zeit, Audience, Subject und Expiry prüft.
Parser Ambiguity: Kryptografie authentifiziert Bytes, auch wenn zwei Komponenten deren Bedeutung unterschiedlich auslegen. Request, Response, Zahlen, Encoding und Fehlerzustände müssen kanonisch sein.
Credential Exposure: Browser Tooling braucht mächtigen Zugriff auf authentifizierten Traffic. Das Plugin-Design von TLSNotary nutzt eine capability-basierte QuickJS-Sandbox. Production Teams brauchen trotzdem enge Permissions, bewusste Zustimmung, signierte Plugins und eine Update Policy (TLSNotary Plugin-Dokumentation).
Verifier Concentration: Ein einzelner delegierter Notary bleibt eine einzelne Policy- und Signing-Key-Abhängigkeit, auch wenn er nie Plaintext sieht.
Falsche Autorisierung: Der Proof „Die Website antwortete mit Erfolg“ beweist nicht, dass der Nutzer den Request wollte.

SDK-Komfort kann diese Grenzen verstecken. Die zkFetch-Dokumentation von Reclaim trennt zum Beispiel öffentliche und private Request Options, Response Matching, Redaction, Proof Verification und On-Chain Transformation (Reclaim Developer Documentation). Prüfe unabhängig vom Provider jede Schicht einzeln und deaktiviere nie Content Validation, nur damit eine Demo funktioniert.

Solltest du zkTLS bauen, kaufen oder vermeiden?

Kaufe oder nutze ein Managed SDK, wenn du einen reversiblen Pilot brauchst, die Quelle bereits ein gepflegtes Template hat, das Proof-Volumen moderat ist und der Claim keine katastrophalen Aktionen freigibt. Verlange vertraglich Stabilität des Proof-Formats, Notary Policy, Data Retention, Incident Notice und einen Exit-Pfad.

Betreibe Verifier und Integration selbst, wenn die Quelle proprietär ist, der Claim Geld oder regulierte Daten freigibt, Latenz und Verfügbarkeit Produktanforderungen sind oder dein Risk Team die Notary Policy nicht delegieren kann. Auch mit einem Open-Source-Protokoll besitzt dein Team Parser, Replay Defence, Subject Binding, Observability und Recovery.

Vermeide zkTLS, wenn eine kooperierende Quelle einen signierten First-Party-Receipt liefern kann, für öffentliche Daten bereits ein etablierter Oracle aggregiert oder gewöhnliches OAuth plus Server-to-Server-Autorisierung das Problem löst. TLSNotary nennt für den aktuellen Referenzpfad TLS 1.2, TLS 1.3 bleibt auf der Roadmap, und MPC verursacht erheblichen Bandbreiten-Overhead (TLSNotary FAQ). Source Compatibility ist ein Gate, keine Fußnote.

Was muss ein Production Pilot beweisen?

Nutze sieben Gates, bevor du dich an eine Plattform bindest:

Statement: Schreibe den exakten Claim in einen Satz, inklusive Origin, Feld, Grenzwert, Subject, Audience und Freshness.
Threat Model: Benenne, was bösartige Nutzer, Agenten, Quellen, Verifier, Extensions und Notarys tun könnten.
Compatibility: Teste echte authentifizierte Sessions, Redirects, Payload-Größen, Browser-Versionen und Fehlerantworten.
Privacy: Verfolge jeden Ort mit Credentials oder Plaintext, inklusive Logs, Crash Reports, Queues und Enclaves.
Reliability: Miss Erfolgsrate, p50- und p95-Latenz, Bandbreite, Proof-Größe, Source-Drift-Fehler und Recovery Time.
Verification: Lehne falsche Origins, alte Proofs, wiederverwendete Nonces, falsche Subjects, falsche Audiences, fehlerhaften Content und widerrufene Notarys ab.
Exit: Beweise, dass du Source Adapter, Verifier oder Provider wechseln kannst, ohne den Authorization Core neu zu schreiben.

Wenn der Agent zusätzlich privat rechnen soll, zwinge zkTLS nicht in diese zweite Rolle. Unser Entscheidungsframework für ZK, FHE, MPC und TEE ordnet jede Garantie der richtigen Schicht zu. Wavects Zero-Knowledge-Engineering hilft, Proof Statement, Threat Model und Pilot-Gates in eine auditierbare Architektur zu übersetzen, bevor die SDK-Wahl teuer wird.

Häufig gestellte Fragen

Ist zkTLS dasselbe wie TLSNotary?

Nein. zkTLS ist eine breite Protokollkategorie für Beweise über TLS-Sessions. TLSNotary ist eine Open-Source-Implementierung und ein Forschungsprojekt. Andere Produkte kombinieren MPC, Proxies, Zero-Knowledge-Systeme, Witnesses, Notarys und Trusted Hardware anders.

Kann zkTLS beweisen, dass ein KI-Agent eine Aktion abgeschlossen hat?

Es kann beweisen, dass eine benannte HTTPS-Quelle eine Antwort passend zum offengelegten Action Receipt geliefert hat. Es beweist nicht automatisch alle nachgelagerten Side Effects, die richtige Entscheidung des Agenten oder die Autorisierung durch den Nutzer. Binde Receipt, Request, Subject, Nonce, Audience und Zeitfenster zusammen.

Verbirgt zkTLS Login-Credentials vor dem KI-Agenten?

Nicht automatisch. Es kann Credentials vor dem Verifier verbergen, wenn das Gerät des Nutzers Session und Proof erzeugt. Lokale Browser Extension, Agent Runtime oder TEE können trotzdem auf Plaintext zugreifen. Diese lokale Grenze muss explizit entworfen und auditiert werden.

Ist zkTLS 2026 production-ready?

Es eignet sich für begrenzte Piloten und ausgewählte Production Flows mit explizitem Threat Model, Version Pinning, Source Monitoring, Replay Protection und Incident Recovery. Das für diesen Artikel geprüfte TLSNotary-Referenz-Release ist noch Alpha und sollte nicht als fertige Compliance-Kontrolle behandelt werden.

Ersetzt zkTLS APIs oder Data Oracles?

Nein. Eine signierte First-Party-API ist bei kooperierender Quelle meist einfacher. Ein etablierter Oracle ist für aggregierte öffentliche Daten meist besser. zkTLS ist stark, wenn Nutzer oder Agenten ausgewählte Fakten aus privaten authentifizierten Webdaten beweisen müssen, ohne die vollständige Antwort zu zeigen.

Fazit

zkTLS gibt KI-Agenten etwas, das Logs und Screenshots nicht liefern: verifizierbare Herkunft ausgewählter privater Webdaten. Sein Nutzen ist zugleich seine Grenze. Das Protokoll authentifiziert ein beobachtetes Transcript und steuert die Offenlegung, macht aber die Quelle nicht wahr, das Modell nicht korrekt und die Aktion nicht autorisiert.

Die Production-Entscheidung beginnt beim Claim und beim Witness. Definiere exakt, was bewiesen werden muss, wer überzeugt werden soll, wann geprüft werden kann und welche Partei Plaintext sehen darf. Benchmarke danach reale Quelle und Endgerät, greife Replay- und Parser-Grenzen an und halte den Authorization Core vom Proof-Provider unabhängig. Wenn eine einfachere signierte API oder ein Oracle genügt, nutze sie. Wenn nicht, ist zkTLS eine glaubwürdige Architekturentscheidung, solange das verbleibende Vertrauen benannt und bewusst konstruiert wird.