Im ersten Teil dieser Serie ging es um das Problem: KI-Assistenten bekommen vollen Zugriff auf Ihren Computer. Im zweiten Teil um die Lösung: schrittweise Freigaben statt Generalschlüssel.
Dieser dritte Teil geht unter die Haube. Eine dokumentierte Studie, keine Bauanleitung. Was genau steckt in einem KI-Assistenten, der nach dem Käfig-Prinzip gebaut ist? Welche Angriffe kann er abwehren? Wo sind seine Grenzen? Und wie findet man Schwachstellen, die man selbst nicht sieht?
Die Architektur in einem Bild
Drei Bereiche, strikt getrennt:
Links: Telegram auf dem Handy. Hier schicken Sie Nachrichten, hier kommen Antworten. Nicht Ende-zu-Ende verschlüsselt. Warum das ein Problem ist, folgt später.
Mitte: Der Käfig. Ein abgeschotteter Bereich auf dem Rechner (technisch: ein Docker-Container mit Nur-Lese-Dateisystem). Der Assistent lebt hier. Er sieht nur, was man ihm zeigt. Er kann nur, was man ihm erlaubt.
Rechts: Der Mac. Kalender, Notizsystem, Dateien. Der Assistent kann nicht direkt darauf zugreifen. Stattdessen gibt es einen Vermittler: einen Bridge-Server, der auf dem Mac läuft und genau kontrolliert, welche Anfragen er beantwortet.
Der entscheidende Punkt: Der Assistent weiß nicht einmal, dass es den Rest des Rechners gibt. Sein Aufzug fährt nur den dritten Stock an. Dass es weitere Stockwerke gibt, ist ihm nicht bekannt.
Was der Käfig leistet
Wenn Sicherheitsexperten einen Container härten, gibt es eine Checkliste: den CIS Docker Benchmark, den Standard der Branche.¹ Die meisten Unternehmen arbeiten drei oder vier Punkte davon ab. Unser Käfig implementiert alle:
Nur-Lese-Dateisystem. Der Assistent kann nichts auf seiner eigenen Festplatte ändern. Sein Code, seine Konfiguration, seine Identität: alles unveränderlich. Selbst wenn jemand ihn durch eine manipulierte Webseite dazu bringen würde, Schadcode zu schreiben — er hätte keinen Ort, an dem er ihn ablegen könnte. Eine erfolgreiche Manipulation hinterlässt keine Spuren im System.
Keine Berechtigungen. Ein normales Programm kann andere Programme starten, Verbindungen ins Netz aufbauen, Benutzerrechte verändern. Unser Assistent kann das alles nicht. Jede dieser Fähigkeiten wurde einzeln entfernt. Was er nicht hat, kann er nicht einsetzen — und kein Angreifer kann es durch ihn einsetzen.
Kein Shell-Zugriff. Die meisten KI-Assistenten können Befehle direkt auf Ihrem Computer ausführen — die Befehlsebene, über die sich ein System von innen vollständig steuern lässt. Es ist ihr mächtigstes und gefährlichstes Werkzeug. Unser Assistent hat dieses Werkzeug nicht. Er kann im Internet suchen und Webseiten abrufen. Mehr nicht. Kein Script, keine Aktion auf Ihrem Rechner außer dem, was der Vermittler explizit erlaubt.
Ressourcen begrenzt. Maximal 2 Gigabyte Arbeitsspeicher, maximal 256 Prozesse gleichzeitig. Keine Endlosschleifen, keine Ressourcenerschöpfung. Nach 10 Durchläufen pro Anfrage ist Schluss. Das Kostenbudget ist konfigurierbar, in der Praxis reichen wenige Dollar pro Tag. Ein fehlerhafter Befehl lähmt nicht den gesamten Rechner.
Kein Entkommen. Der Assistent läuft als eingeschränkter Benutzer, der sich nicht einmal anmelden kann. Selbst wenn jemand in den Container eindringen würde: ohne Kommandozeile, ohne Benutzer-Account, ohne Weg nach draußen. Ein Angreifer, der in den Käfig einbricht, findet darin nichts Verwertbares — und keinen Weg weiter.
Das sind keine theoretischen Versprechen. Das sind Schalter, die man einmal umlegt. Durchgesetzt vom Betriebssystem, nicht vom Assistenten.
Der Vermittler: Wie der Assistent nach draußen kommt
Irgendwann soll der Assistent auch etwas tun. Dafür gibt es den Vermittler: einen kleinen Server, der auf dem Mac läuft und genau definierte Anfragen entgegennimmt.
Der Assistent hat 22 Werkzeuge: drei eigene und 19 über den Vermittler. Was wie ein Widerspruch zum Käfig-Prinzip klingt, ist keiner: Jedes Werkzeug läuft durch denselben Kontrollpunkt. Authentifiziert, auf Häufigkeit begrenzt, protokolliert.
Notizsystem (7 Werkzeuge). Zwei Obsidian-Vaults durchsuchen, Notizen lesen, in einem geteilten Bereich schreiben, umbenennen, löschen, Statistiken abfragen. Schreibzugriff nur in einem definierten Ordner, der Rest ist tabu.
Kalender (5 Werkzeuge). Termine anzeigen, vorschlagen, löschen. Aber nie direkt. Jede Änderung landet in einer Warteschlange. Erst wenn der Nutzer bestätigt, wird sie ausgeführt. Zehn Minuten Frist, danach verfällt der Vorschlag.
E-Mail (4 Werkzeuge). Posteingang lesen, durchsuchen, einzelne Mails abrufen, Ordner auflisten. Nur lesen: kein Senden, kein Löschen, kein Archivieren. Die Zusammenfassung erstellt ein kleines, kostengünstiges Sprachmodell direkt auf dem Vermittler, bevor sie den Assistenten erreicht. Der Assistent sieht die Essenz, nicht die Rohdaten.
Sonstiges (3 Werkzeuge). Bild-Metadaten auslesen (Auflösung, Format, nur aus dem Ausgabe-Ordner). Verbesserungsvorschläge in eine Warteschlange schreiben. Fragen an den Entwickler stellen.
Jede dieser 22 Anfragen wird in einem Audit-Log festgehalten: Zeitstempel, Endpunkt, Antwortzeit. Das Log rotiert nach 90 Tagen. Wenn etwas Ungewöhnliches passiert, kann man nachschauen.
Konkret: Der Assistent sieht Ihre Termine, Ihre Notizen und Ihre Mails. Er sieht nicht Ihre Dateien, Ihr Passwortarchiv oder die Festplatte des Rechners.
Der Vermittler ist keine Einbahnstraße. Wenn der Assistent etwas nicht kann, was der Nutzer braucht, schreibt er einen Vorschlag in eine interne Warteschlange: Begründung, Kontext, Beispiel. Daraus sind neue Fähigkeiten entstanden: E-Mail-Zugriff, Notizsystem-Schreibzugriff, ein persistentes Audit-Log, automatische Budget-Kontrolle. Jede vor der Freischaltung auf ihre Angriffsfläche geprüft.
Das ist der Mechanismus, durch den das System wächst: kontrolliert, dokumentiert, immer mit dem Menschen als Entscheider. Wie das aussieht, wenn der Beifahrer daneben sitzt, zeigt der nächste Abschnitt.
Das Beifahrer-Prinzip
Es gibt einen Einwand, der naheliegt: Wenn der Assistent so eingesperrt ist, was kann er dann überhaupt? Keine Programme schreiben, keine APIs anbinden, keinen Code deployen. Das klingt nach einem sehr teuren Notizblock.
Der Einwand übersieht die zweite Hälfte des Systems.
Hinter dem Bot sitzt dasselbe KI-Modell (mit allen Werkzeugen, ohne Käfig). Aber nicht allein. Sondern mit einem Menschen, der jede Entscheidung sieht, prüft und freigibt. Was sicher ist, läuft autonom. Was riskant ist, läuft gemeinsam.
Aus dem Rallye-Sport: Der Fahrer hat die Hände am Steuer, aber wäre ohne den Beifahrer blind. Der Beifahrer liest die Strecke: Kurven, Tempo, Gefahren. Keiner kommt ohne den anderen aus. Volle Geschwindigkeit, aber niemand fährt blind.
Was das konkret bedeutet: Der Bot erkennt seine eigenen Grenzen und meldet sie als Vorschlag: Begründung, Kontext, Beispiel, direkt in die Warteschlange des Entwickler-Tandems aus Mensch und Claude Code. In acht Tagen Betrieb sind daraus 38 solcher Meldungen entstanden: 18 Feature Requests, 7 Fehlerberichte, 5 Architekturvorschläge. Darunter die Idee für die Bild-Analyse, die Kalender-Optimierung, ein persistentes Audit-Log. 21 Vorschläge wurden umgesetzt. Alle 7 Fehler behoben. Kein einziger abgelehnt — manche zurückgestellt, als bewusste Entscheidung, nicht als Absage.
Die Konkurrenz hat Sicherheitsmodi. Aber wer will, schaltet sie ab — ein Flag, ein Klick, ein überzeugender Prompt. Was Software erlaubt, kann Software auch umgehen. Unser System setzt auf eine andere Grenze: architektonisch, nicht konfigurierbar.
Wer schnell sein will, fährt nicht solo.
Was wir gefunden haben, als wir den Käfig überprüft haben
Was folgt, ist der unangenehmste Teil.
Wir haben das System zwei unabhängigen Sicherheitsprüfungen unterzogen. Beide KI-gestützt, anschließend manuell validiert. Das Ergebnis: 20 Schwachstellen. Davon fünf kritische.²
Die schwerwiegendste: Der Kalender-Vermittler nahm Terminbezeichnungen entgegen und baute sie direkt in einen Systembefehl ein, ohne die Eingabe zu bereinigen. Ein Terminname wie „Besprechung; lösche alle Dateien” hätte beliebige Befehle auf dem Mac ausführen können. Der Käfig wäre intakt geblieben. Der Vermittler hätte die Hintertür geöffnet.²
Ein Lehrbuchfehler: fehlende Eingabebereinigung. Steht auf Seite eins jedes Sicherheitsleitfadens. Und trotzdem ist er uns passiert.
Drei weitere Erkenntnisse, die wir nicht erwartet hatten:
Was nicht stimmt, stimmt gefährlicher nicht. Unsere Sicherheitsdokumentation versprach eine Begrenzung auf zehn Anfragen pro Minute. Im Code gab es keine Begrenzung. Wirklich keine. Das ist schlimmer als eine fehlende Sicherheitsmaßnahme: Es ist ein falsches Versprechen. Ein Prüfer, der die Dokumentation liest und dann in den Code schaut, verliert sofort das Vertrauen in alles andere.
Der erste Durchlauf übersah ein Drittel. Die erste Prüfung fand zwölf Schwachstellen. Die zweite Prüfung, am selben Code mit frischem Blick, fand acht weitere. Darunter die Kalender-Schwachstelle. Das beweist: Eine einzelne Prüfung reicht nicht. Auch nicht zwei. Aber zwei sind deutlich besser als eine.
Die einfachsten Fehler waren die gefährlichsten. Fehlende Anführungszeichen-Bereinigung. Fehlende Pfadprüfung. Ein Standard-Passwort als Rückfallwert. Keine dieser Schwachstellen erforderte tiefes Sicherheitswissen. Sie erforderten Sorgfalt. Und sie waren alle in weniger als einem Tag behoben.
Der Vergleich
Gegen OpenClaw
OpenClaw, eines der am schnellsten gewachsenen Projekte der GitHub-Geschichte und ein Ökosystem für KI-Agenten, das weltweit im Einsatz ist, hat laut dem Sicherheitsforscher Johann Rehberger 512 bekannte Schwachstellen. Acht davon kritisch. 40.000 Installationen standen Anfang 2026 offen im Netz.³
Unser System hatte 20 Schwachstellen nach zwei Prüfungen. Alle behoben. Der Unterschied ist architektonisch: OpenClaw gibt dem Assistenten alles und hofft, dass nichts passiert. Unser System gibt ihm fast nichts und fügt Rechte einzeln hinzu. Alle Schlüssel am ersten Tag gegen ein Büro im dritten Stock.
Gegen die Großen
Im März 2026 wurde der Quellcode von Anthropics eigenem Coding-Werkzeug versehentlich öffentlich.⁴ Die Analyse bestätigte: Dutzende eingebaute Werkzeuge, Feature-Flags die Sicherheitsgrenzen konfigurierbar machen, und eine Architektur, die (soweit der veröffentlichte Code zeigt) darauf ausgelegt ist, dass der Assistent sich selbst beschränkt.
Unser Käfig hat drei eigene Werkzeuge: Web-Suche, Web-Abruf und Datei-Lesen. Alles andere läuft über den Vermittler: 19 weitere Werkzeuge für Notizsystem, Kalender, E-Mail und Bild-Analyse. Jedes einzeln freigeschaltet, jedes authentifiziert, jedes auf Häufigkeit begrenzt. Keinen Schalter, der die Sicherung lockert. Die Beschränkungen werden vom Betriebssystem durchgesetzt, nicht vom Assistenten. Eine Tür, die von außen abgeschlossen ist, kann man von innen nicht öffnen.
Anthropics Claude Code hat Dutzende Werkzeuge und arbeitet ohne menschliche Kontrolle im Loop. Unser Bot hat 22 und handelt autonom, wo es sicher ist. Was dahintersteckt, ist ein Architekturmodell, kein Sicherheitskompromiss.
Einige KI-Systeme setzen zusätzliche Schichten ein, die Aktionen prüfen, bevor sie ausgeführt werden. Clever, aber eine weiche Grenze. Ein gut formulierter Angriff kann auch den Prüfer täuschen. Werkzeug-Beschränkung ist eine harte Grenze: Was der Assistent nicht hat, kann er nicht missbrauchen.
Gegen den Industriestandard
Die OWASP, die wichtigste Organisation für Anwendungssicherheit, hat im Dezember 2025 erstmals eine Top-10-Liste speziell für autonome KI-Agenten veröffentlicht (OWASP Top 10 for Agentic AI, ASI01-ASI10).⁵ Zehn Risiken, entwickelt von über hundert Sicherheitsforschern.
Unser System adressiert neun davon durch Designentscheidungen, nicht durch nachträgliche Patches: kein Shell-Zugriff, keine überschüssigen Berechtigungen, Werkzeug-Beschränkung, Einzelbenutzer-Prüfung, Audit-Log, Ressourcenlimits. Gedächtnismanipulation (ASI06) ist durch einen Write Guard adressiert — entworfen, Implementierung folgt.
Das verbleibende Restrisiko sind Lieferketten-Angriffe. Sie sind dokumentiert. Keine Architektur schließt alle Risiken aus. Aber diese dokumentiert, welche sie adressiert und welche nicht.
Was der Käfig nicht schützt
Eine Schwachstelle haben unsere eigenen Sicherheitsprüfungen übersehen, und sie betrifft nicht den Käfig, sondern den Weg dorthin: den Kommunikationskanal.
Unser Prototyp nutzt Telegram: App auf dem Handy, Nachrichten von unterwegs, Dokumente als Anhang. Das ist bequem. Aber Telegram-Bots können keine Ende-zu-Ende-Verschlüsselung nutzen — das ist in der Bot-API-Dokumentation ausdrücklich bestätigt.⁶ Jede Nachricht zwischen Ihnen und dem Assistenten läuft im Klartext über Telegram-Server.
Der Käfig ist ein Tresorraum mit meterdicken Wänden, aber die Dokumente werden per Postkarte rein- und rausgeschickt. Jeder Briefträger kann mitlesen.
Für einen persönlichen Recherche-Assistenten ist das akzeptabel, solange Sie keine vertraulichen Daten über den Kanal schicken. Für Patientendaten oder Vertragsdetails braucht es einen eigenen Kommunikationskanal: selbst gehostet, Ende-zu-Ende verschlüsselt. Die Technologie dafür existiert: das Matrix-Protokoll, ein offener Standard für sichere Kommunikation.⁷ Der Käfig bleibt identisch. Nur der Briefträger wird ersetzt.
Es gibt eine zweite bekannte Schwachstelle, und die liegt nicht außen, sondern innen: das Gedächtnis. Der Assistent hat eine schreibbare Gedächtnis-Datei, die er bei jedem Start lädt und nach dem Gespräch aktualisiert. Was dort steht, prägt sein Verhalten. Das ist sein Vorteil — und sein einziger weicher Punkt: Wer ihn dazu bringt, falsche Fakten als eigene Erinnerungen zu speichern, kann sein Verhalten dauerhaft verbiegen.
Der Schreibschutz. Die Antwort ist zweischichtig. Erstens: Ein separates, lokales Sprachmodell prüft jeden Text, den der Assistent speichern will — Metas Llama Prompt Guard 2, trainiert auf acht Sprachen (Englisch, Französisch, Deutsch, Hindi, Italienisch, Portugiesisch, Spanisch, Thai), 92 Millisekunden pro Prüfung.⁸ Der Assistent weiß nicht, dass es existiert. Zweitens: Jeder geschriebene Text wird in eine kryptographische Markierung eingehüllt. Beim späteren Lesen gilt alles zwischen den Markierungen als Daten, nie als Anweisung. Was den Prüfer übersteht, kann trotzdem nichts auslösen. Zusammen schließen die beiden Schichten die letzte dokumentierte Lücke in der OWASP-Checkliste.
Ob das hält, zeigt der nächste Artikel.
Was das bedeutet
Dieser Artikel behauptet nicht, dass unser System unknackbar ist. Er behauptet, dass es transparent ist: Architektur, Schwachstellen, Korrekturen, Grenzen — alles liegt offen. In einem Feld, in dem jeder „sicher” sagt und niemand zeigt, was er geprüft hat, ist das die einzige ehrliche Position.
Für einen persönlichen Assistenten auf dem eigenen Rechner reicht das. Verlage, Pharmaunternehmen und Finanzdienstleister, die dieses Modell einsetzen wollen, stehen vor drei konkreten Fragen: Ist die Architektur transparent genug, um einem externen Penetrationstest standzuhalten? Ist der Kommunikationskanal für die eigenen Datenklassen geeignet? Und deckt die DSGVO-Bewertung auch die KI-Schicht ab, nicht nur die Infrastruktur? Diese Fragen sind beantwortbar — aber nur, wenn die Architektur offen liegt. Hier liegt sie offen. Code, der läuft — kein Versprechen.
Was als Nächstes kommt
Der vollständige Code steht als Referenzimplementierung auf Anfrage zur Verfügung — mit Architekturdiagramm und Prüfberichten.
Im nächsten Teil wird es konkret: 442 Angriffe in vier Sprachen — Englisch, Deutsch, Russisch, Chinesisch. Wie gut erkennt ein lokales Sprachmodell Manipulationsversuche? Wo versagt es? Und warum scheitert das beliebteste Open-Source-Modell für diese Aufgabe an einem einzigen deutschen Satz?
Teil 4: Ist Paranoia eine Tugend? Erscheint demnächst.
Wenn Sie dieses Modell für Ihren Einsatzfall durchdenken wollen: schreiben Sie mir — ich antworte persönlich.
Quellen
¹ Center for Internet Security (2024). CIS Docker Benchmark v1.7. cisecurity.org
² Schürmann, C. (2026). MakkaClaw Dual Security Audit: 20 Findings. Internes Dokument, 01.04.2026. Auf Anfrage einsehbar.
³ Rehberger, J. (2026). OpenClaw Security Analysis. Einschließlich CVE-Analysen und Shodan-Scan-Daten, Anfang 2026.
⁴ Anthropic (2026). Claude Code Source Code. Versehentlich veröffentlicht März 2026; Analyse durch unabhängige Sicherheitsforscher.
⁵ OWASP Foundation (2025). Top 10 Risks for Agentic AI Applications: Threats and Mitigations, v1.0. Veröffentlicht Dezember 2025. genai.owasp.org
⁶ Telegram (2026). Bot API Documentation. core.telegram.org/bots/api
⁷ The Matrix.org Foundation (2025). Matrix Specification v1.12. spec.matrix.org
⁸ Meta AI (2025). Llama Prompt Guard 2 86M. AUC 0.995 multilingual. huggingface.co/meta-llama/Llama-Prompt-Guard-2-86M
Dr. Christof Schürmann berät Verlage und Unternehmen in regulierten Branchen bei der KI-gestützten Fachbuchentwicklung. Mehr unter drschuermann.com/leistung
← Teil 2: [Fünf Freigaben für Dr. Jekyll — wie Sie einen KI-Assistenten schrittweise autorisieren] ← Teil 1: [Dr. Jekyll im Käfig — wie Sie KI-Agenten wie OpenClaw sicher einsetzen]