--- title: "zkTLS für KI-Agenten: Production Guide 2026" canonical: https://wavect.io/de/blog/zktls-ai-agents/ language: de description: "Wie zkTLS private Webdaten und Agentenaktionen verifiziert, wo Vertrauen bleibt und wie du 2026 eine Production-Integration planst." image: "https://wavect.io/img/blog/headers/header_zktls-ai-agents.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min Lesezeit · 11. August 2026 Zuletzt geprüft 11. August 2026 [**Weiter**](/de/blog/zero-knowledge-proofs-production-2026/) # zkTLS für KI-Agenten: Webdaten beweisen, Secrets schützen TL;DR zkTLS macht aus einem authentifizierten HTTPS-Request und der Antwort einen verifizierbaren Claim. Credentials und irrelevante Felder bleiben für den nachgelagerten Verifier verborgen. Bewiesen werden Datenherkunft und selektive Offenlegung, nicht die Wahrheit der Quelle, die Qualität der Agentenentscheidung oder die Autorisierung durch den Nutzer. 2026 entwickelt sich der Stack schnell: TLSNotary misst für kleine Attestierungen im Proxy-Modus 1 bis 2 Sekunden. Das aktuelle Referenz-Release ist dennoch Alpha und TLS 1.3 bleibt auf der Roadmap. Nutze zkTLS, wenn dein Produkt kryptografische Evidenz aus privaten Webdaten braucht und keine signierte First-Party-Antwort erhält. Entscheide zuerst über Verifier und Notary, danach über das SDK. **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)](https://dl.acm.org/doi/10.1145/3372297.3417239). 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](/de/blog/zero-knowledge-proofs-production-2026/). Identität, KYC und Lieferketten behandeln wir separat in den [Zero-Knowledge-Anwendungsfällen außerhalb von Krypto](/de/blog/zero-knowledge-use-cases-outside-crypto/). ## 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)](https://tlsnotary.org/docs/intro/). 1. **Request:** Das Gerät des Nutzers oder der Agent greift auf eine benannte HTTPS-Quelle zu. Authentifizierungsdaten bleiben im privaten Teil des Requests. 2. **Witness:** Ein Verifier nimmt per MPC-TLS teil oder beobachtet im Proxy-Modus den verschlüsselten Netzwerkpfad. 3. **Commit:** Das Protokoll bindet ausgewählte Request- und Response-Felder an die beobachtete Session. 4. **Disclose:** Der Prover zeigt einen Wert, einen redigierten Ausschnitt oder ein abgeleitetes Prädikat und verbirgt den Rest. 5. **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)](https://tlsnotary.org/blog/2026/06/17/public-verifiability/). 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)](https://github.com/tlsnotary/tlsn/releases). 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)](https://tlsnotary.org/blog/2026/05/10/blog-proxy-mode/). 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)](https://tlsnotary.org/docs/extension/plugins/). - **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)](https://docs.reclaimprotocol.org/zkfetch/usage). 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)](https://tlsnotary.org/docs/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: 1. **Statement:** Schreibe den exakten Claim in einen Satz, inklusive Origin, Feld, Grenzwert, Subject, Audience und Freshness. 2. **Threat Model:** Benenne, was bösartige Nutzer, Agenten, Quellen, Verifier, Extensions und Notarys tun könnten. 3. **Compatibility:** Teste echte authentifizierte Sessions, Redirects, Payload-Größen, Browser-Versionen und Fehlerantworten. 4. **Privacy:** Verfolge jeden Ort mit Credentials oder Plaintext, inklusive Logs, Crash Reports, Queues und Enclaves. 5. **Reliability:** Miss Erfolgsrate, p50- und p95-Latenz, Bandbreite, Proof-Größe, Source-Drift-Fehler und Recovery Time. 6. **Verification:** Lehne falsche Origins, alte Proofs, wiederverwendete Nonces, falsche Subjects, falsche Audiences, fehlerhaften Content und widerrufene Notarys ab. 7. **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](/de/blog/zk-vs-fhe-vs-mpc-vs-tee/) ordnet jede Garantie der richtigen Schicht zu. Wavects [Zero-Knowledge-Engineering](/de/services/zero-knowledge/) 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. ## Das könnte dich auch interessieren.. [**Zero-Knowledge-Proofs 2026: Was wirklich production-ready ist** Die breitere Production-Landschaft: zkVMs, Mobile Proving, Sicherheitsfehler, Kosten und Toolchains.](/de/blog/zero-knowledge-proofs-production-2026/) [**Wavect vs Alpine Blockchain** Vergleiche einen produktorientierten ZK- und Web3-Engineering-Partner mit einer Blockchain-Spezialagentur.](/de/compare/wavect-vs-alpine-blockchain/) Datenschutz und Kryptografie ## In diesem Cluster weiterlesen [Mit dem Grundlagenartikel starten**Zero-Knowledge-Proofs 2026: Was wirklich production-ready ist**](/de/blog/zero-knowledge-proofs-production-2026/) - [Echte Anwendungen mit ZK und FHE bauen 2026: Ein pragmatischer Guide](/de/blog/building-real-applications-zero-knowledge-fhe-2026/) - [Zero-Knowledge-Proofs 2026: Was wirklich production-ready ist](/de/blog/zero-knowledge-proofs-production-2026/) - [Fully Homomorphic Encryption 2026: Was shipped und was noch Hype ist](/de/blog/fully-homomorphic-encryption-practical-2026/) - [ZK vs FHE vs MPC vs TEE: Wie du 2026 wählst](/de/blog/zk-vs-fhe-vs-mpc-vs-tee/) - [Zero-Knowledge außerhalb von Crypto](/de/blog/zero-knowledge-use-cases-outside-crypto/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min Lesezeit · 11. August 2026 Zuletzt geprüft 11. August 2026 [**Weiter**](/de/blog/zero-knowledge-proofs-production-2026/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/zktls-ai-agents/#webpage", "@type": "WebPage", "dateModified": "2026-08-11", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-11", "url": "https://wavect.io/de/blog/zktls-ai-agents/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "zkTLS macht aus einem authentifizierten HTTPS-Request und der Antwort einen verifizierbaren Claim. Credentials und irrelevante Felder bleiben für den nachgelagerten Verifier verborgen. Bewiesen werden Datenherkunft und selektive Offenlegung, nicht die Wahrheit der Quelle, die Qualität der Agentenentscheidung oder die Autorisierung durch den Nutzer. 2026 entwickelt sich der Stack schnell: TLSNotary misst für kleine Attestierungen im Proxy-Modus 1 bis 2 Sekunden. Das aktuelle Referenz-Release ist dennoch Alpha und TLS 1.3 bleibt auf der Roadmap. Nutze zkTLS, wenn dein Produkt kryptografische Evidenz aus privaten Webdaten braucht und keine signierte First-Party-Antwort erhält. Entscheide zuerst über Verifier und Notary, danach über das SDK.", "articleBody": " Blog-Übersicht/Web3 und Datenschutz/Datenschutz und Kryptografie zkTLS für KI-Agenten: Webdaten beweisen, Secrets schützen TL;DR zkTLS macht aus einem authentifizierten HTTPS-Request und der Antwort einen verifizierbaren Claim. Credentials und irrelevante Felder bleiben für den nachgelagerten Verifier verborgen. Bewiesen werden Datenherkunft und selektive Offenlegung, nicht die Wahrheit der Quelle, die Qualität der Agentenentscheidung oder die Autorisierung durch den Nutzer. 2026 entwickelt sich der Stack schnell: TLSNotary misst für kleine Attestierungen im Proxy-Modus 1 bis 2 Sekunden. Das aktuelle Referenz-Release ist dennoch Alpha und TLS 1.3 bleibt auf der Roadmap. Nutze zkTLS, wenn dein Produkt kryptografische Evidenz aus privaten Webdaten braucht und keine signierte First-Party-Antwort erhält. Entscheide zuerst über Verifier und Notary, danach über das SDK. 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. 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-WorkflowNützlicher Proof-ClaimWas unbewiesen bleibt BerechtigungsprüfungEin benanntes Konto lieferte zu einem begrenzten Zeitpunkt den Status aktivOb die Policy der Quelle fair oder rechtlich ausreichend ist Kauf oder BuchungDie Händlerantwort enthält die erwartete Order-ID und den Status abgeschlossenLieferqualität, Refunds oder ob der Agent das beste Angebot gewählt hat FinanzsignalEin Saldo- oder Einkommensfeld erfüllt einen Grenzwert, ohne den Rohwert zu zeigenOb der Datensatz nach dem Proof-Zeitpunkt noch aktuell ist Agent Tool ResultEin Tool erhielt eine bestimmte Antwort von einem bestimmten HTTPS-OriginOb das Modell die Antwort richtig interpretiert hat Action ReceiptEin Remote Service bestätigte die angeforderte ZustandsänderungOb 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", "articleSection": "Zero Knowledge", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "(ACM CCS, 2020)", "url": "https://dl.acm.org/doi/10.1145/3372297.3417239" }, { "@type": "WebPage", "name": "(TLSNotary-Dokumentation)", "url": "https://tlsnotary.org/docs/intro/" }, { "@type": "WebPage", "name": "(TLSNotary, Juni 2026)", "url": "https://tlsnotary.org/blog/2026/06/17/public-verifiability/" }, { "@type": "WebPage", "name": "(offizielle Release Notes)", "url": "https://github.com/tlsnotary/tlsn/releases" }, { "@type": "WebPage", "name": "(TLSNotary Benchmark Harness)", "url": "https://tlsnotary.org/blog/2026/05/10/blog-proxy-mode/" }, { "@type": "WebPage", "name": "(TLSNotary Plugin-Dokumentation)", "url": "https://tlsnotary.org/docs/extension/plugins/" }, { "@type": "WebPage", "name": "(Reclaim Developer Documentation)", "url": "https://docs.reclaimprotocol.org/zkfetch/usage" }, { "@type": "WebPage", "name": "(TLSNotary FAQ)", "url": "https://tlsnotary.org/docs/faq/" } ], "dateModified": "2026-08-11", "datePublished": "2026-08-11", "description": "zkTLS macht aus einem authentifizierten HTTPS-Request und der Antwort einen verifizierbaren Claim. Credentials und irrelevante Felder bleiben für den nachgelagerten Verifier verborgen. Bewiesen werden Datenherkunft und selektive Offenlegung, nicht die Wahrheit der Quelle, die Qualität der Agentenentscheidung oder die Autorisierung durch den Nutzer. 2026 entwickelt sich der Stack schnell: TLSNotary misst für kleine Attestierungen im Proxy-Modus 1 bis 2 Sekunden. Das aktuelle Referenz-Release ist dennoch Alpha und TLS 1.3 bleibt auf der Roadmap. Nutze zkTLS, wenn dein Produkt kryptografische Evidenz aus privaten Webdaten braucht und keine signierte First-Party-Antwort erhält. Entscheide zuerst über Verifier und Notary, danach über das SDK.", "headline": "zkTLS für KI-Agenten: Webdaten beweisen, Secrets schützen", "image": "https://wavect.io/img/blog/headers/header_zktls-ai-agents.svg", "inLanguage": "de", "keywords": "Zero Knowledge, KI-Agenten", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/zktls-ai-agents/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/zktls-ai-agents/", "wordCount": 2115 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/web3-privacy/", "name": "Web3 und Datenschutz", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/privacy-cryptography/", "name": "Datenschutz und Kryptografie", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/zktls-ai-agents/", "name": "zkTLS für KI-Agenten: Production Guide 2026 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Ist zkTLS dasselbe wie TLSNotary?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Kann zkTLS beweisen, dass ein KI-Agent eine Aktion abgeschlossen hat?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Verbirgt zkTLS Login-Credentials vor dem KI-Agenten?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Ist zkTLS 2026 production-ready?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "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." }, "name": "Ersetzt zkTLS APIs oder Data Oracles?" } ] } ```