Identität, Event, Ledger.
Organisations- und Agenten-Credentials, hybrid signierte Event-Cores, lückenlose Sequenzen, kausale Verkettung und transaktionale Seals.
Audit-Infrastruktur · Pilotbetrieb
Wenn KI handelt, muss der Beleg außerhalb ihrer Aussage liegen.
KIShieldWitness erzeugt kryptografisch prüfbare Audit-Trails für KI-Agenten – hybrid signiert, kausal verkettet, mit externer Trust-Policy und einem außerhalb des Agenten kontrollierten Kill-Layer.
Trust-GrenzeEin gültiger Trail beweist Integrität und Signatur, nicht automatisch die Wahrheit oder Vollständigkeit eines gemeldeten Ereignisses.
Evidence file / schematic
verified
01Intent erfasstsigniert
02Result verkettetgebunden
03Merkle-Sealintakt
04Trust-Policyextern
05Anchor-Statusseparat
sha256:f31a…9ce2
ed25519 + ml-dsa-65
chain: valid · identity: pinned
ed25519 + ml-dsa-65
chain: valid · identity: pinned
Schematische Darstellung. Kein Live-Transaktionsnachweis. Anchor-Verfügbarkeit und Finalität werden unabhängig vom Trail-Status bewertet.
Gebaut für den Moment, in dem ein Agent nicht nur antwortet.
Buchungen, Freigaben, Bestellungen und API-Aufrufe brauchen mehr als ein veränderbares Log. KIShieldWitness bindet gemeldete Ereignisse an Identitäten, Signaturen, Reihenfolge und eine explizite Trust-Policy.
Vertrauen wird gepinnt, nicht eingebettet.
Offline-Verifier verlangen externe Org-, Source- und Controller-Pins. Integrität, Identität, Provenienz, Zeit und Anker bleiben getrennte Statusdimensionen.
Beweise behalten. Offenlegung kontrollieren.
PII-verdächtige Metadaten werden minimiert. Bestätigte Löschung vernichtet Disclosure-Schlüssel; signierte Ciphertexte, Hashes und Merkle-Beweise bleiben prüfbar.
Ein Agent kontrolliert nicht seinen eigenen Not-Aus.
Controller-signierte Suspend-/Revoke-Belege, Dead-Man-v2, Broker-Trennung, WORM-Nachzug und ein verzögertes, separat autorisiertes Re-Arm.
Fünf Zustände. Keine vermischten Versprechen.
Die Prüfung beantwortet mehrere engere Fragen nacheinander. Ein grüner Signaturstatus macht einen externen Anchor nicht automatisch sichtbar oder final.
Erfassen
Absicht, Ergebnis, Ausgang und Provenienzklasse werden als kanonischer Event-Core gebunden.
Signieren
Ed25519 und ML-DSA-65 schützen denselben kanonischen Inhalt als hybride Signatur.
Verketten
Sequenz und Vorgänger-Hash machen nachträgliche Lücken oder Änderungen prüfbar.
Versiegeln
Ein Merkle-Root fasst den Trail zusammen; der Seal-Schreibweg ist idempotent und transaktional.
Verifizieren
Externe Pins und getrennte Anchor-/Zeitstatus verhindern Vertrauen in ein selbstbehauptetes Bundle.
Drei Wege hinein. Drei klar benannte Vertrauensmodelle.
Die richtige Integration hängt davon ab, wo der Agent läuft, wer Klartext sehen darf und wer die Signierschlüssel kontrolliert.
Confidential MCP
Für lokale Agenten- und Desktop-Setups. Der Witness-Client und die Schlüssel bleiben beim Nutzer; der Cloud-Core erhält keine Payload im Klartext.
- Läuftlokal beim Nutzer
- Schlüsselbeim Nutzer
- Klartextlokale Vertrauensgrenze
- GeeignetClaude Desktop, eigene lokale Tools
Connect
Custodial-Hinweis: Der Connect-Betreiber sieht die Remote-MCP-Argumente im Klartext und verwahrt die pro Tenant getrennten Signierschlüssel verschlüsselt.
Für Agenten bei Fremdanbietern. Freie Berichte sind K1; automatisch brokered Request/Response kann als K2 erfasst werden. Connect ist ausdrücklich kein Zero-Knowledge-System.
- Läuftserverseitig
- Schlüsselcustodial, at rest verschlüsselt
- Klartextfür Betreiber sichtbar
- GeeignetChatGPT und Remote-MCP
SDK & Core
Für eigene Agenten, Backends und kontrollierte Broker-Pfade. Python- und JavaScript-SDKs erzeugen kompatible Belege und exportieren offline prüfbare Bundles.
- Läuftin eigener Integration
- Schlüsselnach Betriebsmodell
- Verifieroffline, mit externen Pins
- Geeigneteigene Agenten und API-Workflows
Kontrolle außerhalb des Agenten.
Der Kill-Layer dokumentiert nicht nur die Entscheidung zum Stoppen. Er trennt Entscheidung, Ausführungseffekt und externen Nachweis – und meldet unvollständige Wirkung als Fehler.
Stand 22.07.2026: Der synthetische KD1–KD8-Produktionsdrill gegen die laufende Instanz ist durchgeführt: acht Kriterien bestanden. KD3 trennte die offene Broker-Operation in 280,5 ms; KD2 blockierte nach 58 s bei 60 s Token-TTL.
Aussagegrenze: KD4 belegt den ausgelieferten Referenz-Broker, nicht jede Kunden-Firewall. KD8 prüfte die Offline-Signatur ohne Hardware-Attestation; der Alarmnachweis blieb auf Security-Log und Kill-Record begrenzt.
Default-Deny-Broker
Kein offener Proxy: Ziele, Methoden, Capabilities und optionale Budgets kommen aus administrativer Policy. Unklare Ergebnisse bleiben fail-closed.
Server-Nonce statt Client-Uhr
Challenge, Signatur, Ablaufzeit, Action-Hash und Key-Generation sind gebunden. Ein verspätetes Keepalive belebt einen abgelaufenen Agenten nicht wieder.
Beleg und Effekt getrennt
Controller-signierter Kill-Record, Broker-Trennung, WORM und externer Nachzug besitzen eigene Statuswerte. Teilwirkung liefert keinen bestätigten Erfolg.
Verzögertes Re-Arm
Ein getrenntes Recovery-Signal öffnet nur ein kurzes Fenster. Derselbe Akteur muss die serverseitige Wartezeit einhalten; Freigaben sind einmalig und idempotent gebunden.
Signiert heißt nicht automatisch unabhängig beobachtet.
Deshalb zeigt KIShieldWitness nicht nur „gültig“, sondern auch, wer den Inhalt behauptet oder signiert hat.
Gemeldetes Ereignis
Eine signierte Selbstauskunft des integrierten Clients. Integrität ist prüfbar; die inhaltliche Wahrheit folgt daraus nicht.
Brokered Beobachtung
Connect kann den exakten ausgehenden Request und die Antwort automatisch erfassen. Außerhalb dieses Brokerpfads ist ein K2-Label allein nicht stärker als K1.
Quellsignatur
Eine externe Quelle signiert source_id und content_hash. Der Verifier verlangt dafür einen extern gepinnten Quellschlüssel.
Pilotpartner gesucht
Welcher Agent muss bei Ihnen beweisbar handeln?
Wir klären Trust-Grenze, Betriebsart, Provenienzklasse und Kill-Policy vor der Integration – und sagen ebenso klar, was KIShieldWitness nicht beweist.