Ich sehe bei KI-Agenten immer wieder denselben Reflex.
Wenn ein Agent nicht sauber genug arbeitet, bekommt er noch ein Tool. Wenn er Kontext nicht findet, bekommt er mehr Quellen. Wenn er eine Aufgabe nicht vollständig löst, bekommt er mehr Zugriff. Browser, Shell, CRM, Ticketsystem, Dateisystem, Kalender, Slack, Wiki, Datenbank.
Das sieht nach Fortschritt aus.
In der Praxis kann es das Gegenteil sein.
Ein KI-Agent wird nicht automatisch besser, wenn er mehr anfassen darf. Er wird oft schwerer prüfbar, schwerer wartbar und riskanter. Nicht weil Tools schlecht sind. Sondern weil jeder neue Zugriff eine neue Entscheidung darüber ist, was das System tun darf.
Und genau dort beginnt Agenten-Sicherheit.
Mehr Fähigkeiten sehen gut aus
Eine Demo mit vielen Tools wirkt beeindruckend.
Der Agent liest Dateien, ruft Webseiten auf, schreibt Tickets, recherchiert Kunden, aktualisiert Daten, entwirft Antworten und schiebt Aufgaben weiter. Für eine Präsentation ist das stark. Man sieht sofort, was möglich ist.
Aber Betrieb ist keine Demo.
Im Betrieb zählt nicht, ob ein Agent viel kann. Im Betrieb zählt, ob er zuverlässig das Richtige tut, ob seine Quellen stimmen, ob seine Aktionen nachvollziehbar sind und ob ein Mensch versteht, warum etwas passiert ist.
Mehr Fähigkeiten vergrößern nicht nur den Nutzen.
Sie vergrößern auch die Fehlerfläche.
Ein Agent mit einem klaren Lesezugriff kann falsch zusammenfassen. Ein Agent mit Schreibzugriff kann falsche Daten speichern. Ein Agent mit Shell-Zugriff kann echte Änderungen auslösen. Ein Agent mit Browserzugriff kann fremde Inhalte in den Kontext holen. Ein Agent mit CRM-Zugriff kann Kundendaten verändern.
Das sind verschiedene Risikoklassen.
Sie sollten nicht alle denselben Vertrauensvorschuss bekommen.
Jeder Tool-Zugriff ist eine Sicherheitsentscheidung
In klassischer IT-Sicherheit ist das selbstverständlich.
Ein Benutzer bekommt nicht “ein bisschen Admin”, weil es praktisch wäre. Ein Service-Account bekommt nicht alle Tabellen, weil irgendwann vielleicht eine Abfrage nützlich sein könnte. Ein Script bekommt nicht Schreibrechte auf alles, nur weil es damit flexibler wird.
Bei KI-Agenten wird dieses Prinzip schnell vergessen.
Man spricht über Fähigkeiten und vergisst Berechtigungen. Man spricht über Autonomie und vergisst Nachweis. Man spricht über Produktivität und vergisst, dass ein Tool nicht nur eine Funktion ist, sondern ein möglicher Ausführungspfad.
OWASP nennt dieses Risiko in den LLM Top 10 für 2025 Excessive Agency.
Der Begriff ist gut, weil er das Problem nüchtern benennt. Ein LLM-System bekommt Handlungsmacht über Tools, Plugins oder Skills. Wenn diese Handlungsmacht zu breit ist, können unerwartete, manipulierte oder schlicht falsche Modellentscheidungen reale Auswirkungen haben.
OWASP nennt drei typische Ursachen: zu viel Funktionalität, zu viele Berechtigungen und zu viel Autonomie.
Für mich ist das eine sehr praktische Checkliste.
Wenn ein Agent etwas darf, muss ich fragen: Braucht er diese Funktion wirklich? Braucht er diese Berechtigung wirklich? Darf er diese Aktion wirklich ohne menschliche Freigabe ausführen?
Wenn eine dieser Antworten schwach ist, ist der Agent zu breit gebaut.
Kleine Werkzeugkästen sind kein Rückschritt
Ein kleiner Werkzeugkasten klingt erst einmal nach weniger Leistung.
Ich sehe das anders.
Ein kleiner Werkzeugkasten ist oft die Voraussetzung dafür, dass ein Agent produktiv werden kann. Nicht weil er weniger kann, sondern weil klarer wird, was er tun soll.
Ein Research-Agent braucht vielleicht Quellen lesen, Notizen schreiben und Zitate markieren. Er braucht nicht automatisch E-Mail, Kalender, Browser-Automation, Shell und Zugriff auf private Ablagen.
Ein SOC-Agent braucht vielleicht Telemetrie lesen, Abfragen dokumentieren und einen Investigation Draft erstellen. Er braucht nicht automatisch Remediation-Rechte in Produktion.
Ein Schreib-Agent braucht vielleicht Drafts, Stilregeln und Quellenpakete. Er braucht nicht automatisch Publishing-Rechte.
Das ist nicht Misstrauen gegenüber KI.
Das ist normales Sicherheitsdenken.
Anthropic beschreibt in Building Effective AI Agents einen ähnlichen Grundsatz: mit der einfachsten möglichen Lösung anfangen und Komplexität nur erhöhen, wenn sie nötig ist. Das kann sogar heißen, kein agentisches System zu bauen, wenn ein klarer Workflow reicht.
Ich halte das für einen sehr wichtigen Punkt.
Nicht jede Aufgabe braucht einen Agenten. Manche Aufgaben brauchen einen Workflow. Manche brauchen ein Script. Manche brauchen eine Checkliste. Manche brauchen einen Menschen, der entscheidet.
Agenten sind dann sinnvoll, wenn die Dynamik wirklich gebraucht wird.
Nicht, weil Dynamik in einer Demo gut aussieht.
Guardrails gehören an die Tool-Grenze
Prompts helfen.
Aber Prompts sind keine technische Sicherheitsgrenze.
Das habe ich im letzten Agenten-Sicherheitsartikel schon geschrieben, und hier wird es noch konkreter: Wenn ein Agent ein Tool aufruft, muss die Kontrolle an dieser Stelle greifen. Nicht nur vorher im Systemprompt. Nicht nur nachher im Review.
OpenAI beschreibt in der Agents-SDK-Dokumentation Tool Guardrails, die vor und nach Custom-Function-Tool-Aufrufen laufen können. Das ist die richtige Denkrichtung.
Ein Tool-Aufruf ist ein Kontrollpunkt.
Dort muss geprüft werden:
Darf dieser Agent dieses Tool nutzen? Darf er es mit diesen Parametern nutzen? Kommen die Parameter aus einer erlaubten Quelle? Ist die Aktion read-only oder schreibt sie etwas? Braucht sie menschliche Freigabe? Muss sie geloggt werden? Gibt es ein Rollback?
Wenn diese Fragen nicht beantwortet sind, ist das Tool zu früh freigegeben.
Dann hängt die Sicherheit wieder an der Hoffnung, dass das Modell schon das Richtige tut.
Hoffnung ist keine Architektur.
Wartung heißt auch Löschen
Viele Teams denken bei Wartung an Updates.
Neue Versionen. Neue Modelle. Neue Features. Neue Integrationen.
Bei KI-Agenten muss Wartung aber auch Löschen heißen.
Ein Tool, das beim ersten Modell hilfreich war, kann später stören. Eine Quelle, die einmal gültig war, kann veralten. Eine Berechtigung, die bei einem schwachen Modell harmlos wirkte, kann bei einem stärkeren Modell plötzlich riskant werden, weil der Agent mehr plausible Aktionen erzeugt.
Agenten driften in zwei Richtungen.
Die Welt um sie herum verändert sich: Prozesse, Wikis, Dashboards, Zuständigkeiten, Datenfelder, Policies.
Und das Modell im Agenten verändert sich: Es wird besser, schneller, eigenständiger, manchmal auch anders fehleranfällig.
Wenn der Werkzeugkasten gleich bleibt, obwohl sich Aufgabe und Modell ändern, entsteht Sicherheits- und Wartungsschuld.
Dann produziert der Agent weiter Arbeit aus einer Umgebung, die nicht mehr stimmt.
Das ist gefährlicher als eine kaputte Automation, die sichtbar scheitert. Ein Agent kann leise falsch weiterarbeiten und dabei sehr überzeugend aussehen.
Was ich vor jedem neuen Tool fragen würde
Ich würde vor jedem neuen Tool fünf Fragen stellen.
Erstens: Welche konkrete Aufgabe wird dadurch besser?
Nicht allgemeiner. Nicht beeindruckender. Besser.
Zweitens: Welche Aktion darf der Agent damit ausführen?
Nur lesen? Draften? Schreiben? Löschen? Veröffentlichen? Geld ausgeben? Daten verändern?
Drittens: Welche Quelle darf diese Aktion beeinflussen?
Eine interne Policy ist etwas anderes als eine Webseite. Ein Ticket ist etwas anderes als eine E-Mail. Eine Logzeile ist etwas anderes als eine Freigabe.
Viertens: Wo ist der Nachweis?
Ein Agent sollte nicht nur sagen, was er getan hat. Er sollte zeigen, welche Quellen er geprüft hat, welche Tools er genutzt hat, welche Annahmen offen sind und wo ein Mensch entscheiden muss.
Fünftens: Wann löschen wir das wieder?
Diese Frage wird zu selten gestellt.
Wenn ein Tool später nicht mehr gebraucht wird, sollte es verschwinden. Wenn ein Workflow enger geworden ist, sollte der Agent enger werden. Wenn ein Modell besser geworden ist, muss der alte Werkzeugkasten neu geprüft werden.
Ein Agent, der nur wächst, wird irgendwann unverständlich.
Ein Agent, der gepflegt wird, darf auch kleiner werden.
Meine Meinung ist
Bessere KI-Agenten brauchen nicht automatisch mehr Tools.
Sie brauchen passendere Tools.
Sie brauchen klare Quellen, enge Berechtigungen, technische Guardrails, Logging, menschliche Freigaben und einen Wartungsprozess, der auch Entfernen erlaubt.
Das klingt weniger spektakulär als Autonomie.
Aber genau so entsteht Betriebssicherheit.
Ein guter Agent ist nicht der, der alles anfassen kann.
Ein guter Agent ist der, der genau genug darf, um seine Aufgabe zuverlässig zu erledigen.
Und eng genug bleibt, damit ein Mensch die Verantwortung dafür tragen kann.
Quellen
Anthropic: Building Effective AI Agents
OWASP: LLM06:2025 Excessive Agency
OWASP: Agentic AI — Threats and Mitigations
Gregor Lyttek ist Security Architect & AI Strategist und Threat Hunter im Versicherungsumfeld.