In den meisten Einführungen entsteht der Zugang beiläufig: Es wird ein Zugangsschlüssel erzeugt, damit „der Agent auf die Daten kommt“. Genommen wird der Schlüssel, der am schnellsten funktioniert — meist ein Administrationszugang. Ab diesem Moment ist die Frage nach Sicherheit keine Modellfrage mehr, sondern eine Rechtefrage.
Der Agent erbt, er entscheidet nicht
Ein Sprachmodell hat keine eigenen Rechte. Es kann nur ausführen, was das Werkzeug erlaubt, mit dem es verbunden ist. Daraus folgt eine unbequeme Konsequenz: Eine Anweisung im Prompt, etwas nicht zu tun, ist keine Sicherheitsmaßnahme. Sie ist eine Bitte an ein System, das durch Eingaben beeinflussbar ist.
Der Prompt ist die Absicht, die Berechtigung ist die Grenze. Alles, was wirklich verhindert werden soll, muss auf der Rechteebene verhindert werden — nicht im Text. Diese Trennung ist der Kern jeder belastbaren Agenten-Architektur.
Vier Stufen, die in der Praxis reichen
- Lesen, eingeschränkt: Der Agent sieht nur die Felder und Datensätze, die er für seine Aufgabe braucht. Personenbezogene Felder, die keine Rolle spielen, werden gar nicht erst mitgeliefert.
- Lesen, vollständig: Sinnvoll bei Auswertungen über einen ganzen Datenbestand — aber ohne Schreibrechte und mit Protokollierung jedes Abrufs.
- Schreiben in einen Entwurfsbereich: Der Agent erzeugt Ergebnisse, die als Entwurf liegen bleiben. Nichts wird versendet, veröffentlicht oder in einen Live-Datensatz übernommen.
- Schreiben produktiv: Nur für eng umrissene, wiederholbare Vorgänge mit klarem Rückweg — und mit einer Obergrenze, wie viele Datensätze in einem Lauf verändert werden dürfen.
Die meisten produktiv nützlichen Agenten bleiben dauerhaft auf Stufe eins bis drei. Der Nutzen entsteht durch Vorbereitung, nicht durch Autonomie.
Was der Zugang technisch braucht
Ein eigener Zugang je Agent, nicht der Schlüssel eines Mitarbeiters. Das klingt nach Formalität und ist der einzige Weg, im Nachhinein zu erkennen, wer etwas verändert hat. Dazu gehören enge Scopes statt Vollzugriff, ein Ablaufdatum für den Schlüssel und ein dokumentierter Weg, ihn sofort zu sperren.
Ebenso wichtig ist die Trennung zwischen Test und Produktion. Ein Agent, der in der Entwicklung gegen echte Kundendaten läuft, ist in der Entwicklung bereits produktiv — mit allen Konsequenzen.
Freigabepunkte setzen, wo es weh tut
Ein Freigabepunkt gehört überall dorthin, wo eine Handlung nach außen wirkt oder schwer umkehrbar ist: Versand an Kunden, Veröffentlichung, Zahlungen, Löschungen, Statusänderungen mit Vertragswirkung. Alles andere darf laufen.
Entscheidend ist, dass die Freigabe eine echte Prüfung bleibt. Eine Freigabe, die aus einem Knopf besteht, den man dreißigmal am Tag drückt, ist keine Kontrolle mehr. Deshalb ist es besser, wenige, aber ernst gemeinte Freigabepunkte zu setzen als viele oberflächliche.
Fremde Inhalte sind Daten, keine Anweisungen
Ein Agent, der E-Mails, Dokumente oder Webseiten verarbeitet, liest damit Text, den Dritte geschrieben haben. Enthält dieser Text Formulierungen, die wie Anweisungen aussehen, kann das Modell sie befolgen. Der Schutz dagegen liegt wieder nicht im Prompt, sondern in der Rechteebene: Wenn der Agent nichts versenden darf, kann eine untergeschobene Anweisung ihn nicht zum Versand bewegen.
Protokollieren, was passiert ist
Zu jedem Agentenlauf gehören Zeitpunkt, Auslöser, gelesene Quellen, erzeugtes Ergebnis und die Person, die freigegeben hat. Ohne dieses Protokoll ist die Frage „warum steht das so im System“ nach zwei Wochen unbeantwortbar — und genau diese Frage kommt.
Der Aufwand ist gering, wenn er beim Bau eingeplant wird, und unverhältnismäßig, wenn er nachträglich eingebaut werden muss. Wie die Freigabestruktur im Tagesgeschäft aussieht, ergänzt der Beitrag zu Human-in-the-Loop.