83 % der KI-Agenten-Funktionen ohne Sicherheitsprüfungen – eine Bestandsaufnahme

Eine Studie zeigt: Bei der Analyse von drei Open-Source-KI-Agenten-Systemen in TypeScript fanden sich 669 Funktionen mit potenziell gefährlichen Seiteneffekten – doch 83 % dieser Funktionen verfügten über keinerlei Schutzmechanismen wie Eingabevalidierung, Authentifizierung oder Bestätigungsschritte.

Die Untersuchung, durchgeführt mit einem eigens entwickelten statischen Analysetool, offenbart ein kritisches Sicherheitsrisiko: In vielen Fällen entscheidet ein Sprachmodell selbstständig über den Aufruf von Funktionen, ohne dass der Code angemessene Kontrollen vorsieht. Doch wie entsteht diese Lücke zwischen Absicht und Umsetzung – und was bedeutet sie für die Entwicklung sicherer KI-Agenten?

Warum ungeschützte Tool-Aufrufe in Agenten-Systemen besonders riskant sind

In herkömmlichen Webanwendungen durchläuft jede sicherheitskritische Aktion wie eine Datenbankoperation oder eine Zahlung mehrere Schutzschichten: Benutzeroberfläche, Validierungslogik, Sitzungsmanagement und Bestätigungsschritte. Jede dieser Ebenen wurde bewusst gestaltet, um Missbrauch zu verhindern.

In KI-Agenten-Systemen hingegen entscheidet ein Sprachmodell (LLM) selbstständig, welche Funktion mit welchen Parametern aufgerufen wird. Ohne explizite Kontrollen im Code kann ein Agent:

• Endlosschleifen ausführen
• Falsche oder manipulierte Argumente verwenden
• Durch manipulierte Tool-Ergebnisse in andere Aktionen geleitet werden

Die Folge: Sicherheitsmechanismen müssen direkt im Code integriert sein – doch genau dort fehlen sie oft. Die zentrale Frage lautet daher nicht mehr, ob eine Anwendung sicher ist, sondern ob für jede potenziell gefährliche Funktion eine sichtbare Kontrolle existiert.

Wie die Analyse durchgeführt wurde und was gemessen wurde

Für die Untersuchung entwickelte der Autor ein statisches Analysetool namens diplomat-agent-ts, das auf ts-morph basiert – der TypeScript-Compiler-API. Das Tool durchsucht den Abstract Syntax Tree (AST) des Codes und identifiziert alle Funktionsaufrufe, die potenziell gefährliche Seiteneffekte auslösen können.

Die Analyse umfasste drei Open-Source-KI-Agenten-Systeme mit insgesamt 11.379 TypeScript-Dateien. Die untersuchten Funktionen wurden in 12 Kategorien eingeteilt, darunter:

• Datenbankoperationen (Schreiben/Löschen)
• Dateimanipulation (Löschen/Erstellen)
• Zahlungsabwicklung
• HTTP-Anfragen (Schreiben)
• Agenten-Aufrufe
• Dynamischer Code (z. B. eval)
• Shell-Befehle (z. B. execSync)

Als Schutzmechanismus galt jede im Code sichtbare Kontrolle, wie:

• Eingabevalidierung (z. B. mit Zod, Yup oder Klassenvalidierung)
• Ratenbegrenzung (z. B. @Throttle-Dekorator)
• Authentifizierungsprüfungen
• Bestätigungsschritte
• Idempotenzschlüssel

Jede identifizierte Funktion wurde in eine von drei Kategorien eingeordnet:

• `no_checks`: Keine erkennbaren Schutzmechanismen
• `partial_checks`: Teilweise Schutzmechanismen, aber unvollständig
• `confirmed`: Explizit als geprüft markiert (mit // checked:ok)

Wichtig: Die Kategorie `confirmed` wurde vom Analysetool selbst eingeführt und ist in keiner der untersuchten Codebasen standardmäßig vorhanden. Daher zeigt die Analyse in allen drei Systemen eine Quote von 0 % für diese Kategorie – was keine Bewertung, sondern eine Bestandsaufnahme ist.

Die zentralen Erkenntnisse: Zahlen, Kategorien und Risiken

Die Untersuchung ergab folgende Ergebnisse:

| Codebase (Scope) | Type | TypeScript-Dateien | Tool-Aufrufe | no_checks | partial | |------------------|------|-------------------|--------------|------------|-----------| | OpenClaw (src/) | Anwendung | 7.874 | 419 | 332 (79%) | 87 | | Mastra (packages/) | Framework | 2.777 | 185 | 162 (88%) | 23 | | OpenAI Agents JS (packages/) | Framework | 426 | 33 | 31 (94%) | 2 | | OpenAI Agents JS (examples/) | Beispiele | 302 | 32 | 28 (88%) | 4 | | Gesamt | — | 11.379 | 669 | 553 (83%) | 116 |

Die Kategorie `no_checks` dominiert mit 83 % – doch die Verteilung zeigt, dass das Problem branchenweit besteht. Selbst OpenAIs Framework-Pakete, die als besonders durchdacht gelten, erreichten eine Quote von 94 % ungeschützter Funktionen.

Gefahrenpotenzial nach Kategorien

Die Analyse identifizierte 669 potenziell gefährliche Tool-Aufrufe, die sich auf folgende Kategorien verteilen:

• destructive (Shell-Befehle, Subprozesse): 486
• file_delete (Dateilöschungen): 214
• publish (Veröffentlichungen): 124
• agent_invocation (Agenten-Aufrufe): 120
• http_write (HTTP-Schreiboperationen): 86
• llm_call (Sprachmodell-Aufrufe): 3
• database_delete (Datenbanklöschungen): 3
• dynamic_code (Dynamischer Code): 1

Einige Kategorien sind besonders auffällig:

• `destructive` macht den größten Anteil aus – doch hier handelt es sich oft um intendierte Funktionen (z. B. ein Tool, das Shell-Befehle ausführt). Die Analyse offenbart damit weniger ein Sicherheitsproblem als vielmehr eine Dokumentationslücke: Welche Funktionen sind wirklich sicher und welche müssen zusätzlich geschützt werden?
• `agent_invocation` und `publish` sind in Framework-Projekten überproportional vertreten, da diese Systeme oft andere Agenten steuern oder Artefakte veröffentlichen müssen.

Jedes Ergebnis wurde zusätzlich mit OWASP-Agentic-Codes klassifiziert:

• ASI-02 (Tool-Missbrauch) traf auf alle 669 Funktionen zu
• ASI-01 (Exzessive Berechtigungen) auf 576 Funktionen
• ASI-03 (Privilegienerweiterung) auf 465 Funktionen

Was diese Ergebnisse für Entwickler und Sicherheitsverantwortliche bedeuten

Die Analyse liefert keine pauschalen Schulnoten, sondern eine Bestandsaufnahme, die Entwicklern und Sicherheitsverantwortlichen hilft, Prioritäten zu setzen. Die wichtigsten Schlussfolgerungen:

1. Sicherheitsmechanismen müssen im Code sichtbar sein

Statische Analysetools können zwar gefährliche Funktionen identifizieren – doch viele Kontrollen (z. B. Authentifizierungslogik in Middleware) sind im Code selbst nicht sichtbar. Hier muss die Zusammenarbeit zwischen Entwicklern und Sicherheitsverantwortlichen gestärkt werden.

1. Agenten-Systeme erfordern ein neues Sicherheitsparadigma

Traditionelle Webanwendungen schützen sich über UI- und Middleware-Schichten. Agenten-Systeme hingegen erfordern proaktive Code-Kontrollen, die direkt im Funktionsaufruf verankert sind.

1. Die größte Gefahr liegt in der Unsichtbarkeit

Viele Entwickler wissen schlicht nicht, welche Funktionen ihr Agent tatsächlich aufrufen kann. Eine regelmäßige Bestandsaufnahme – ähnlich der hier durchgeführten Analyse – sollte zum Standard werden.

Die Studie zeigt: KI-Agenten-Systeme stehen noch am Anfang ihrer Sicherheitsentwicklung. Während Frameworks wie OpenAIs Agenten-Pakete bereits Sicherheitshinweise in ihrer Dokumentation bereitstellen, fehlt in vielen Projekten eine systematische Überprüfung der Tool-Aufrufe. Die Lösung liegt nicht in der Abschaffung von Agenten, sondern in einer kulturellen Veränderung – hin zu mehr Transparenz und proaktiver Sicherheit.

Langfristig wird es darum gehen, statische und dynamische Analysen zu kombinieren und Sicherheitsmechanismen so zu gestalten, dass sie sowohl für Entwickler als auch für Sprachmodelle nachvollziehbar sind.