Ich sehe bei Agenten einen einfachen Reflex: Wenn eine Aufgabe nicht sauber gelöst wird, bekommt das System ein weiteres Tool oder mehr Zugriff. So wächst aus einem Research-Helfer ein System mit Browser, Shell, Dateisystem, E-Mail und Tickets. Die Demo kann dadurch mehr. Im Betrieb steigen zugleich Angriffsfläche und Prüfaufwand.

Ein Lesezugriff kann zu einer falschen Zusammenfassung führen. Schreib-, Shell- oder CRM-Rechte erzeugen andere Schadensklassen. Diese Fähigkeiten verdienen unterschiedliche Freigaben und Nachweise.

Jeder Tool-Zugriff ist eine Sicherheitsentscheidung

In klassischer IT-Sicherheit erhält ein Service-Account die Tabellen und Aktionen, die seine Aufgabe erfordert. Bei Agenten gilt dasselbe Prinzip. Ein Tool ist eine Funktion und ein möglicher Ausführungspfad.

In der aktuellen OWASP GenAI LLM Top 10 2026 heißt dieses Risiko LLM03:2026 Excessive Agency; in der Vorgängerversion war es LLM06:2025. Die drei Ursachen bleiben gleich: übermäßige Funktionalität, zu breite Berechtigungen und zu viel Autonomie.

Die daraus folgende Sicherheitsheuristik ist enger als der Titel dieses Artikels: Für eine klar abgegrenzte Aufgabe reduziert ein minimaler, passender Werkzeugsatz typischerweise Angriffsfläche und Prüfaufwand. Das sagt noch nichts darüber aus, welche Toolzahl die beste fachliche Leistung liefert. Nutzen und Risiko müssen getrennt getestet werden.

Kleine Werkzeugkästen sind kein Rückschritt

Ein Research-Agent muss vielleicht Quellen lesen, Zitate markieren und Notizen in einem festgelegten Ordner ablegen. E-Mail, Kalender und private Ablagen wären dafür Ballast. Ein SOC-Agent kann Telemetrie lesen und einen Investigation Draft erstellen, ohne Remediation-Rechte in Produktion zu erhalten. Ein Schreib-Agent braucht für einen Entwurf keine Publishing-Berechtigung.

Anthropic empfiehlt in Building effective agents, mit der einfachsten geeigneten Lösung zu beginnen und Komplexität nur bei nachgewiesenem Bedarf hinzuzufügen. Manchmal reicht ein fester Workflow oder ein Skript. Ein Agent lohnt sich dort, wo die Aufgabe tatsächlich dynamische Planung erfordert.

Guardrails gehören an die Tool-Grenze

Der Toolaufruf ist ein technischer Kontrollpunkt. Das OpenAI Agents SDK unterstützt Input- und Output-Guardrails für FunctionTool-Aufrufe. Input-Guardrails laufen vor der Funktion, Output-Guardrails danach.

Diese Funktion hat klare Grenzen: Sie gilt laut Dokumentation nicht für Handoffs, HostedMCPTool, gehostete Tools oder die eingebauten Computer-, Shell- und ApplyPatch-Tools. Das SDK bietet außerdem eigene Approval-Flows. Parameterherkunft, Audit-Logging und Rollback entstehen dadurch nicht automatisch; sie müssen in der Anwendung entworfen werden.

Vor der Ausführung prüfe ich deshalb Rolle, Tool, Parameter, Datenquelle und Wirkungsklasse. Schreibende, löschende, veröffentlichende oder kostenpflichtige Aktionen erhalten eigene Freigaberegeln. Fehlen diese Antworten, bleibt das Tool gesperrt.

Werkzeugkästen müssen kleiner werden dürfen

Agenten und ihre Umgebung driften. Prozesse, Datenfelder und Policies ändern sich. Neue Modelle können vorhandene Werkzeuge anders nutzen als ihre Vorgänger. Ein unveränderter Werkzeugkasten erzeugt deshalb Wartungs- und Sicherheitsschuld.

Vor jedem neuen Tool stelle ich fünf Fragen:

  1. Welche konkrete Aufgabe wird messbar besser?
  2. Welche Wirkungsklasse erhält der Agent: lesen, entwerfen, schreiben, löschen, veröffentlichen oder Geld ausgeben?
  3. Welche Quellen dürfen die Aktion und ihre Parameter beeinflussen?
  4. Welche Protokolle und Belege braucht eine spätere Prüfung?
  5. Unter welcher Bedingung wird das Tool wieder entfernt?

Die letzte Frage verhindert, dass jeder Versuch dauerhaft zur Angriffsfläche wird. Ein gepflegter Agent darf kleiner werden.

Ein guter Werkzeugkasten ist groß genug für die belegte Aufgabe und eng genug für nachvollziehbare Verantwortung. Mehr Tools sind nur dann Fortschritt, wenn ihr zusätzlicher Nutzen die neue Fehler- und Angriffsfläche rechtfertigt.

Quellen

Gregor Lyttek ist Security Architect & AI Strategist und Threat Hunter im Versicherungsumfeld.

lyttek.org · gregor@lyttek.org