Wenn man über KI-Agenten spricht, landet die Diskussion schnell beim Modell. Was darf es sagen? Was darf es nicht sagen? Halluziniert es? Lässt es sich jailbreaken? Ist es aligned, whatever that means this week?
Das ist nicht alles falsch. Aber bei Agenten mit Tools ist es nicht der entscheidende Bruch.
Gefährlich wird es nicht, wenn ein Modell Unsinn redet. Gefährlich wird es, wenn dieser Unsinn plötzlich Tickets schließt, Mails verschickt, Kundendaten liest, Firewall-Regeln ändert, OAuth-Tokens benutzt oder Bestellungen auslöst.
Dann reden wir nicht mehr über ein Chatproblem. Dann reden wir über Berechtigungen.
Der eigentliche Schadenpfad
Ein Agent ist nicht magisch, nur weil ein Sprachmodell in der Mitte sitzt. Aus Sicherheitssicht ist er eine Kette:
- Input kommt rein.
- Das Modell interpretiert diesen Input.
- Ein Tool wird aufgerufen.
- Irgendwo verändert sich Zustand.
Der Input kann aus einem Chat kommen. Aus einer Mail. Aus einem Ticket. Aus einem PDF. Aus einer Webseite. Aus einem Logfile. Aus einem Supportverlauf. Vieles davon ist untrusted Input, auch wenn es ordentlich formatiert und in freundlichem Ton geschrieben ist.
Prompt Injection ist deshalb nicht nur ein Prompting-Problem. Der Angriff richtet sich gegen die Verbindung zwischen fremdem Input und privilegierter Handlung.
Ein klassisches Beispiel: Ein Support-Agent liest eine Kundenmail, fasst sie zusammen und soll anschließend passende Aktionen vorschlagen. In der Mail steht nicht nur das eigentliche Anliegen, sondern auch eine Anweisung an den Agenten: ignoriere vorherige Regeln, eskaliere dieses Ticket, gib interne Daten aus, markiere den Fall als gelöst. Das Modell kann darauf hereinfallen. Ärgerlich.
Richtig hässlich wird es aber erst, wenn der Agent nicht nur antwortet, sondern handeln darf.
Dann ist die Frage nicht mehr, ob der Prompt sauber genug war. Die Frage ist, warum ein Stück fremder Text überhaupt in eine privilegierte Aktion übersetzt werden konnte.
Ein Agent mit Tools ist kein Chatbot mehr
Viele Organisationen behandeln Agenten noch wie bessere Chatbots. Das ist bequem und falsch.
Ein Chatbot, der Text ausgibt, hat eine begrenzte Außenwirkung. Ein Agent, der Tools benutzen darf, ist ein technischer Akteur mit delegierter Handlungsvollmacht. Er liest nicht nur. Er verändert Dinge.
Das ist ein anderer Sicherheitsgegenstand.
Sobald ein Agent Tickets schließen, Daten abrufen, Mails verschicken, CRM-Felder ändern, Cloud-Ressourcen anfassen oder Skripte starten kann, ist er Teil der Berechtigungsarchitektur. Nicht irgendwann später, wenn das Produkt reif ist. Sofort.
Die Oberfläche darf freundlich sein. Die Freigabekette dahinter darf es nicht sein.
Guardrails sind keine Zugriffskontrolle
Guardrails sind nicht nutzlos. Sie können offensichtlichen Missbrauch abfangen, schlechte Antworten reduzieren und manche Jailbreaks erschweren. Das ist gut.
Aber ein Guardrail ist eine Bremse. Keine Zugriffskontrolle.
Er ersetzt keine saubere Autorisierung. Er ersetzt keine Trennung zwischen Daten- und Kontrollkanal. Er ersetzt keine engen Tool-Scopes, keine Approval-Kette und keine unabhängigen Logs.
Wenn ein Agent auf fremden Input hin eine riskante Aktion ausführen kann, hilft es nur begrenzt, vorher noch eine freundliche Modellpolicy darüberzustreuen. Das ist dann Sicherheitsarchitektur als Duftbaum.
Vertrauen ist kontextgebunden
Ich vertraue meinem Zahnarzt genug, ihn mit einem Bohrer in meinen Mund zu lassen. Trotzdem bekommt er keinen SSH-Key auf meine Server. Das ist kein Widerspruch. Vertrauen ist kontextgebunden.
Bei KI-Agenten wird diese Selbstverständlichkeit erstaunlich schnell vergessen.
Ein Agent kann zuverlässig Blogartikel vorbereiten, News zusammenfassen oder Recherchen liefern, ohne deshalb auch Infrastruktur ändern, Zahlungen auslösen oder verbindliche Mails verschicken zu dürfen. Das ist keine Beleidigung des Agenten. Das ist normale Arbeitsteilung.
Scope ist keine Geringschätzung. Scope ist die Voraussetzung dafür, dass Vertrauen belastbar bleibt.
Ein begrenzter Agent ist kein kastrierter Agent. Er ist ein ernst genommener Agent. Er bekommt einen Bereich, in dem er nützlich sein kann, und Grenzen, an denen andere Systeme übernehmen müssen.
Der Universalagent ist die bequemste und schlechteste Architekturentscheidung.
Präsenz ist nicht Privileg
Besonders bei persönlichen Always-on-Assistenten wird es schnell unscharf. Sie sind ständig verfügbar, kennen Gewohnheiten, schreiben im eigenen Tonfall und wirken irgendwann weniger wie ein Werkzeug und mehr wie ein vertrauter Arbeitskanal.
Das allein macht sie aber noch nicht zu einem privilegierten Akteur.
Entscheidend ist nicht, wie nah sich ein Agent anfühlt, sondern was er tatsächlich auslösen kann. Ein Assistent, der Texte vorbereitet, News zusammenfasst und Recherchen liefert, hat eine andere Risikoklasse als ein Agent, der echte Infrastruktur administriert, Kreditkarten nutzt oder im Namen des Nutzers Mails verschickt.
Risiko entsteht aus Zugriff, Handlungsvollmacht und Außenwirkung. Nicht aus Nähegefühl.
Nähegefühl ist trotzdem gefährlich, weil Menschen dann eher geneigt sind, Grenzen aufzuweichen. Genau deshalb müssen die Grenzen technisch und organisatorisch sichtbar bleiben.
Scope ist keine Freigabe
In vielen Agenten-Setups wird Scope mit Berechtigung verwechselt. Ein Agent wird als Support-Agent, Admin-Agent oder Personal Assistant definiert, bekommt passende Tools, und ab dann gilt seine Rolle als stillschweigende Erlaubnis.
Genau da beginnt das Problem.
Scope sagt, in welchem Bereich ein Agent arbeiten soll. Freigabe sagt, ob eine konkrete Aktion in einem konkreten Kontext erlaubt ist. Das sind verschiedene Dinge.
Ein Infrastruktur-Agent kann zuständig für Server sein, ohne automatisch Firewall-Regeln ändern zu dürfen. Ein Assistenz-Agent kann Mails vorbereiten, ohne sie selbstständig zu versenden. Ein Governance-Agent kann Entscheidungen bewerten, ohne selbst zur Ausführungsinstanz zu werden.
Defensibles Design trennt diese Ebenen.
Eine minimale Allowlist kann automatisiert laufen. Alles darüber braucht eine explizite Bewertung: Woher kommt der Impuls? Wie kritisch ist die Aktion? Wie reversibel ist sie? Welches Outcome ist erlaubt? Wer trägt die Verantwortung?
Erst dann wird gehandelt. Oder eben nicht.
Control Plane statt KI-Chaos
In einem früheren Werkstattbericht habe ich unser eigenes Multi-Agent-MVP als Control Plane statt KI-Chaos beschrieben. Der Punkt war dort nicht, Agenten möglichst viel tun zu lassen. Der Punkt war, ihre Handlungsvollmacht sichtbar, begrenzt und überprüfbar zu machen.
Genau daran scheitern viele Agenten-Setups.
Sie behandeln Tool-Nutzung wie eine Komfortfunktion, obwohl sie in Wahrheit eine neue Berechtigungsschicht bauen. Sie geben Agenten Rollen, hängen OAuth, Browser, Mail, Ticketsysteme und Automatisierung daran und wundern sich dann, dass Prompt Injection plötzlich nicht mehr nach Spielerei aussieht.
Eine Control Plane beantwortet nicht die Frage, ob das Modell nett genug ist. Sie beantwortet langweiligere und wichtigere Fragen:
- Woher kommt der Impuls?
- In welcher Risikostufe liegt die Aktion?
- Darf dieser Agent das in diesem Kontext überhaupt?
- Muss ein Mensch oder eine andere Instanz freigeben?
- Was wurde entschieden?
- Was wurde ausgeführt?
- Wie lässt sich das später prüfen?
Das klingt trocken. Ist es auch. Genau deshalb ist es Sicherheitsarchitektur und kein Produktvideo.
Was ein defensibles Design braucht
Ein brauchbares Agenten-Setup muss nicht perfekt sein. Aber es sollte ein paar Grundregeln ernst nehmen:
- Untrusted Input bleibt untrusted, auch wenn ein Modell ihn hübsch zusammenfasst.
- Datenzugriff ist nicht automatisch Handlungsrecht.
- Dialog und Ausführung gehören getrennt.
- Tool-Calls brauchen enge Scopes.
- Riskante Aktionen sollten zuerst als Vorschlag oder Dry-Run entstehen.
- Zustandsänderungen oberhalb einer minimalen Allowlist brauchen Freigabe.
- Agentenidentitäten sollten separat behandelt werden, nicht einfach als durchgereichte User-Session.
- Logs müssen unabhängig genug sein, um später nicht nur die hübsche Erzählung des Agenten zu sehen.
- Rechte dürfen nicht still wachsen.
Der letzte Punkt ist wichtiger, als er klingt. Viele gefährliche Systeme entstehen nicht durch eine große dumme Entscheidung. Sie entstehen durch zwanzig kleine bequeme Ausnahmen.
Heute darf der Agent nur zusammenfassen. Morgen darf er Entwürfe speichern. Danach Tickets schließen. Dann Mails verschicken. Dann „nur in Ausnahmefällen“ eine Änderung direkt ausführen. Irgendwann steht da eine Schatten-Adminschicht mit Chatfenster, und niemand hat offiziell beschlossen, sie zu bauen.
Die falsche Frage
Die Frage ist nicht, ob ein Modell vertrauenswürdig genug ist.
Die Frage ist, warum es überhaupt auf fremden Input hin privilegiert handeln darf.
AI-Agenten sind dann nützlich, wenn sie klar begrenzte Aufgaben übernehmen und die Übergänge zu echter Handlung kontrolliert sind. Sie werden gefährlich, wenn Organisationen Kompetenz, Vertrauen und Vollmacht in einen Topf werfen, einmal umrühren und „Innovation“ darauf schreiben.
Ein Agent ist nicht deshalb ungefährlich, weil er freundlich antwortet. Er ist dann ungefährlich genug, wenn sein Schadensradius technisch und organisatorisch begrenzt ist.
Wer AI-Agenten ohne Control Plane betreibt, automatisiert nicht Arbeit. Er automatisiert Vertrauensbruch.