Eine Fortsetzung zur Self-Hosting-Frage, diesmal aus der anderen Richtung gedacht.

In meinem letzten Beitrag habe ich argumentiert, dass Self-Hosting für AI-Coding meistens überflüssig ist, weil wir in der reinen Entwicklung kaum personenbezogene Daten verarbeiten. Wir bauen den Code, der später mit echten Daten umgeht, nicht die Datenverarbeitung selbst. Genau an dieser Stelle kam eine berechtigte Nachfrage: Was ist, wenn die KI eben doch an die echten Daten kommt? Etwa in einer Agentenstruktur, die eigenständig läuft, Zugriff auf Systeme hat und Inhalte verarbeitet, filtert und weitergibt. Das ist eine andere Welt, und sie verdient eine eigene Betrachtung.

Der Denkfehler: flüchtig heißt nicht spurlos

Ein Sprachmodell hat kein Gedächtnis im menschlichen Sinne. Es bekommt bei jeder Anfrage das gesamte Kontextfenster vorgelegt und berechnet daraus die nächste Antwort. Endet die Session, wird dieser Kontext nicht mehr mitgeschickt, und für das Modell ist die Information weg. Daraus ziehen viele den falschen Schluss: Wenn ohnehin alles vergessen wird, ist es egal, was ich hineinschreibe.

Flüchtig ist aber nur das Arbeitsgedächtnis des Modells, also das, was es bei der nächsten Berechnung sieht. Die Daten selbst sind damit nicht verschwunden. Sie wurden übertragen, auf Servern verarbeitet, je nach Anbieter und Vertrag geloggt, zwischengespeichert oder zur Qualitätssicherung eingesehen. Was du in den Prompt schreibst, hat einen Weg zurückgelegt, und auf diesem Weg kann es liegen bleiben. Das Vergessen durch das Modell schützt dich davor nicht.

Code ist nicht gleich Geheimnis

Bei Quellcode lässt sich das Risiko meist nüchtern einordnen. Ein Passwort, ein API-Key, ein echter Kundendatensatz oder ein Token ist eine andere Kategorie. Solche Werte sind oft sofort und unmittelbar missbrauchbar, sie verlieren ihren Wert nicht über Zeit, und sie lassen sich nicht anonymisieren. Ein durchgesickerter Boilerplate-Controller ist ärgerlich. Ein durchgesickerter Produktiv-Key ist ein Vorfall. Deshalb gilt für Zugangsdaten und personenbezogene Daten eine einfache Regel: gar nicht erst hineingeben.

Bei Agenten wird es richtig heikel

Im klassischen Chat triffst du diese Entscheidung bewusst. Du tippst, du siehst, was du teilst. Ein autonom laufender Agent dreht diese Logik um. Er entscheidet selbst, welche Dateien er liest, welche Endpunkte er aufruft und welche Inhalte er in den nächsten Schritt weiterreicht. Hat er Zugriff auf eine Datenbank, ein Postfach oder ein Filesystem mit echten Daten, dann wandert dieser Inhalt unter Umständen in den Kontext, ohne dass jemand ihn dort bewusst platziert hat.

Dazu kommt ein zweites Problem: Prompt Injection. Inhalte, die der Agent verarbeitet (eine E-Mail, ein Dokument, eine Webseite), können selbst Anweisungen enthalten. Im schlechten Fall bringt ein manipulierter Inhalt den Agenten dazu, sensible Daten aus dem Kontext nach außen zu geben oder Aktionen auszuführen, die niemand beabsichtigt hat. Je mehr Autonomie und je breiter die Zugriffsrechte, desto größer die Angriffsfläche.

Was das praktisch heißt

Trennung von Code und echten Daten bleibt der wichtigste Hebel. Secrets gehören in einen Secret Manager und werden zur Laufzeit referenziert, nicht in Prompts genannt. Agenten bekommen nur die Rechte, die sie für ihre Aufgabe wirklich brauchen, idealerweise mit lesendem statt schreibendem Zugriff und mit klaren Grenzen, welche Systeme überhaupt erreichbar sind. Inhalte aus externen Quellen werden als potenziell feindlich behandelt, nicht als vertrauenswürdige Anweisung. Und für produktive Setups mit echten personenbezogenen Daten gilt das, was ich im letzten Beitrag als die 10 Prozent beschrieben habe: hier ist die strengere Architektur tatsächlich gerechtfertigt.

Die Faustregel bleibt am Ende erstaunlich simpel. Behandle den Kontext nicht als Tresor, sondern als Postkarte. Was nicht auf eine Postkarte gehört, gehört auch nicht in den Prompt. Und bei einem Agenten, der eigenständig Postkarten schreibt, lohnt sich der Blick darauf, was er überhaupt in die Hand bekommt.