Entwicklung von KI-Agenten: zentrale Konzepte und Risiken

Entwicklung von KI-Agenten: Definition und Abgrenzung

Die Entwicklung von KI-Agenten umfasst Design, Aufbau, Test und Deployment von KI-Systemen, die Ziele eigenständig verfolgen. Dazu analysieren sie Probleme, planen Aktionen und erledigen Aufgaben mit Tools und externen Diensten. Das Thema ist gerade jetzt relevant, denn Agenten wandern rasant aus Forschungsdemos in produktive Cloud-Workloads. Dort arbeiten sie mit echten Daten, echter Infrastruktur und echten Nutzenden. Daraus entstehen Herausforderungen für Entwicklung und Sicherheit, für die klassisches Software Engineering nie gedacht war.

Ebenso wichtig ist die Abgrenzung. Eine einfache LLM-Chat-Anwendung, bei der ein Prompt hineingeht und Text zurückkommt, ist keine Agent-Entwicklung. Klassische Wenn-dann-Automatisierungsskripte sind es ebenfalls nicht. Ein KI-Agent verbindet ein LLM mit Memory, Tools, Datenzugriff und einer Entscheidungslogik, die seine nächsten Schritte selbst bestimmt. Das LLM arbeitet dabei als Reasoning-Engine, nicht bloß als Textgenerator.

Laut dem Report Wiz State of AI in the Cloud 2025 nutzen inzwischen 85 % der Unternehmen KI-Dienste oder KI-Tools. Agentenbasierte Architekturen gehören dabei zu den am schnellsten wachsenden Mustern in Cloud-Umgebungen. Der Unterschied ist erheblich: Klassische Automatisierung folgt festen Regeln aus der Feder von Entwicklungsteams. KI-Agenten interpretieren Situationen dagegen mithilfe von LLMs und entscheiden selbst über den nächsten Schritt. Diese Flexibilität macht sie leistungsfähig, aber auch weniger vorhersehbar und schwerer abzusichern.

Warum KI-Agenten gerade jetzt relevant sind

KI hat sich von „Frage stellen, Antwort erhalten“ zu „Ziel definieren, den Agenten den Weg finden lassen“ entwickelt. Statische LLM-Anwendungen wie Chatbots und Zusammenfassungstools weichen autonomen Agenten, die in Produktion echte Aktionen ausführen. Dieser Wandel verändert, was Entwicklungsteams bauen und was Sicherheitsteams schützen müssen.

Die Flut an Agent-Frameworks (etwa LangGraph, CrewAI, Google ADK und AutoGen) und Protokolle wie das Model Context Protocol (MCP) haben die Einstiegshürde für Agenten drastisch gesenkt. Immer mehr Teams bringen Agenten immer schneller in Produktion. Etablierte Sicherheitsprüfungen oder eine zentrale Governance fehlen dabei oft.

Die geschäftlichen Treiber sind klar: Agenten automatisieren komplexe agentische Workflows in Kundensupport, Codegenerierung, Datenanalyse und internen Abläufen. Wer autonom handelt, macht aber auch autonom Fehler. Diese Fehler haben echte Folgen, sobald Agenten Zugangsdaten für Produktivsysteme besitzen.

Agenten werden zu Cloud-Workloads mit eigenen Identitäten, eigenem Netzwerkzugriff und eigenen Datenverbindungen. Damit wächst die Lücke zwischen dem, was Entwicklungsteams bauen, und dem, was Sicherheitsteams erkennen können.

Ein Beispiel aus der Praxis: Jemand im Entwicklungsteam startet einen Coding-Agenten, der sich mit einem Code-Repository, einer Cloud-Deployment-Pipeline und einer Datenbank verbindet. Dieser Agent hat nun Zugriff auf Quellcode, Produktionsinfrastruktur und potenziell sensible Daten. All das läuft über einen einzigen Satz Zugangsdaten, den ein Sicherheitsteam womöglich nie prüft.

Unternehmen, die Agent-Entwicklung als reines KI-Thema behandeln und nicht als Frage von Cloud-Infrastruktur und Identitäten, schaffen gefährliche blinde Flecken.

Funktionsweise von KI-Agenten

Ein KI-Agent besteht aus wenigen Kernkomponenten, die in einer fortlaufenden Schleife zusammenarbeiten. Wer diese Bausteine versteht, trifft bessere Entscheidungen bei der Wahl der Frameworks und beim ersten Code.

Diese Komponenten durchlaufen einen wiederkehrenden Zyklus. Der Agent nimmt einen Input wahr, bewertet ihn mit dem LLM und plant die nächste Aktion. Dann handelt er über einen Tool- oder API-Aufruf, beobachtet das Ergebnis und beginnt von vorn. Ein Agent für die Triage von Support-Tickets liest etwa das Ticket und durchsucht per Retrieval-Augmented Generation (RAG) eine Wissensdatenbank. Anschließend prüft er per API-Aufruf den Kontostatus des Kunden und leitet das Ticket an das richtige Team weiter, ganz ohne menschliches Eingreifen.

Jede Komponente dieser Architektur ist zugleich ein potenzieller Fehlerpunkt oder Teil der Angriffsfläche. Tools brauchen Authentifizierung. Memory-Stores können sensible Daten enthalten. Die Orchestrierungslogik legt fest, was der Agent tun darf. Deshalb ist Agent-Entwicklung nicht nur ein KI-Thema, sondern gleichzeitig eine Frage von Cloud-Infrastruktur, Identitäten und Datensicherheit.

Zentrale Designmuster für KI-Agenten

Nicht jeder Anwendungsfall braucht einen vollständig autonomen Agenten. Erfahrene Teams wählen das einfachste Muster, das das Problem löst, und erhöhen die Komplexität erst, wenn der einfachere Ansatz nicht ausreicht. Der Leitfaden von Anthropic zum Aufbau effektiver Agenten hat dieses musterbasierte Denken populär gemacht. Inzwischen ist es der Standardansatz für Architekturentscheidungen in der Praxis.

Prompt Chaining

Prompt Chaining zerlegt eine Aufgabe in feste Schritte, und das Ergebnis jedes Schritts fließt in den nächsten ein. Dieses Muster ist einfach, vorhersehbar und leicht zu debuggen. Es eignet sich am besten für klar definierte Workflows mit vorab bekannter Abfolge. Ein Beispiel ist eine Content-Review-Pipeline: Schritt eins extrahiert zentrale Aussagen, Schritt zwei prüft jede Aussage auf Fakten, Schritt drei erstellt einen zusammenfassenden Bericht.

Routing

Routing klassifiziert einen Input und leitet ihn an einen spezialisierten Handler weiter. Das Muster passt gut zu Agenten, die sehr unterschiedliche Anfragen bearbeiten. Ein Support-Agent ordnet eingehende Tickets beispielsweise als Abrechnungs-, Technik- oder Kontoprobleme ein. Jede Kategorie landet dann bei einem eigenen spezialisierten Prompt oder Toolset.

Tool Use und Function Calling

Hier entscheidet das LLM, welche Tools es mit welchen Parametern aufruft. An dieser Stelle gewinnen Agenten echte Fähigkeiten, und hier entstehen auch die wichtigsten Sicherheitsfragen. Tool Use ist der Wendepunkt, an dem ein Agent vom „Denken“ zum „Handeln“ übergeht. Genau dort bündeln sich die meisten Sicherheitsrisiken. Ein Agent, der beliebige APIs aufrufen oder beliebigen Code ausführen kann, braucht sorgfältig eingegrenzte Berechtigungen.

Orchestrator-Worker

Ein zentrales LLM zerlegt eine Aufgabe in Teilaufgaben und delegiert sie an spezialisierte Worker. KI-Agent-Orchestrierung hilft bei komplexen, mehrstufigen Problemen, deren Teilaufgaben vorab nicht bekannt sind. Ein Research-Agent erhält etwa eine breite Frage und zerlegt sie in Teilfragen. Jede Teilfrage geht an einen Worker, der andere Datenquellen durchsucht, und am Ende führt der Agent die Ergebnisse zusammen.

Multi-Agent-Systeme

Hier arbeiten mehrere Agenten zusammen, jeder mit eigener Rolle und eigenen Fähigkeiten. Das Muster ist leistungsstark, aber schwerer zu debuggen, abzusichern und zu überwachen. Jeder Agent kann eigene Identitäten, Tool-Zugriffe und Datenverbindungen haben. Die meisten Anwendungsfälle in Produktion brauchen keine Multi-Agent-Architektur. Ein einfacher Start ist fast immer die richtige Entscheidung, denn der Koordinationsaufwand lohnt sich nur, wenn ein einzelner Agent die Aufgabe tatsächlich nicht bewältigt.

Frameworks und Tools für die Entwicklung von KI-Agenten

Das Framework-Ökosystem entwickelt sich schnell. Die richtige Wahl hängt vom Anwendungsfall, von der Expertise im Team und von den Anforderungen in Produktion ab.

• LangGraph: Graphbasierte Orchestrierung für komplexe, zustandsbehaftete Agent-Workflows mit bedingten Verzweigungen und persistentem Zustand über mehrere Schritte.

• CrewAI: Rollenbasiertes Framework für die Zusammenarbeit mehrerer Agenten, die jeweils eigene Personas übernehmen.

• Google Agent Development Kit (ADK): Code-first-Framework mit tiefer Google-Cloud-Integration für Enterprise-Teams, die Agenten mit Google-Diensten verbinden.

• AutoGen: Multi-Agent-Konversationsframework von Microsoft, stark bei Forschung und Prototyping konversationeller Multi-Agent-Systeme.

• Pydantic AI: Typsicheres Agent-Framework mit Fokus auf strukturierte Outputs und strikter Datenvalidierung für Inputs und Outputs des Agenten.

• Model Context Protocol (MCP): Offenes Protokoll, das Agenten standardisiert mit Tools und Datenquellen verbindet, ähnlich wie USB Hardwareverbindungen standardisiert hat.

Auch die Wahl des Frameworks hat Folgen für die Sicherheit. Frameworks, die Agenten mühelos breiten Tool-Zugriff gewähren oder Verbindungen zu beliebigen MCP-Servern erlauben, erfordern strengere Governance. Entscheidend ist deshalb, was ein Framework dem Agenten standardmäßig erlaubt. Da sich die Landschaft rasch ändert, gehören neben den aktuellen Funktionen auch Community-Aktivität, Dokumentationsqualität und die Sicherheitsvoreinstellungen des Anbieters in die Bewertung.

KI-Agenten entwickeln: der Prozess Schritt für Schritt

Die Entwicklung eines KI-Agenten folgt einem strukturierten Prozess. Anders als bei klassischer Software bringt jedoch jeder Schritt eigene Anforderungen mit, weil sich Agenten nicht deterministisch verhalten. Die folgenden Schritte zeigen, wie produktionsreife Agenten tatsächlich entstehen.

Schritt 1: Ziel und Umfang definieren

Am Anfang steht das Problem, nicht die Technologie. Welche konkrete Aufgabe soll der Agent erledigen? Welche Daten braucht er, und was darf er niemals anfassen? Die Eingrenzung ist auch eine Sicherheitsübung: Festzulegen, was der Agent nicht tun soll, ist genauso wichtig wie festzulegen, was er tun soll.

Schritt 2: Agent-Architektur entwerfen

In diesem Schritt fällt die Wahl auf das passende Designmuster, und Tools, Datenquellen sowie Orchestrierungslogik werden skizziert. Hier entsteht auch die Identität des Agenten: bei welchen Cloud-Diensten er sich mit welchen Berechtigungen authentifiziert. Die Entscheidungen an dieser Stelle bestimmen den Schadensradius des Agenten, falls etwas schiefgeht.

Schritt 3: Frameworks, Modelle und Tools auswählen

Jetzt folgen LLM, Orchestrierungs-Framework und Tool-Integrationen. Jeder Modellanbieter, jeder Tool-Connector und jeder MCP-Server wird Teil der Agent-Lieferkette. Diese Abhängigkeiten verdienen dieselbe Sorgfalt wie jede andere Softwarekomponente von Drittanbietern.

Schritt 4: Entwickeln und iterieren

Die Agent-Logik entsteht zunächst als einfachste funktionsfähige Version. Jede Komponente wird isoliert getestet, bevor sie mit anderen zusammenspielt. Ein funktionierendes Single-Agent-System mit zwei Tools lehrt mehr als eine Multi-Agent-Architektur, die nie in Produktion geht.

Schritt 5: Evaluieren und testen

Die Evaluierung von Agenten geht über Unit-Tests hinaus, weil ihr Verhalten nicht deterministisch ist. Evaluierungs-Harnesses sollten vielfältige Inputs und Edge Cases abdecken, darunter auch adversariale Inputs wie Prompt-Injection-Angriffe. Sinnvolle Metriken sind etwa die Erfolgsquote bei Aufgaben, die Genauigkeit von Tool-Aufrufen und die Häufigkeit von Halluzinationen.

Schritt 6: In Produktion bereitstellen

Das Deployment in die Cloud-Infrastruktur erfolgt mit passenden Identitätsbindungen, Netzwerkzugriffskontrollen und Monitoring. Berechtigungen, die in der Entwicklung bequem waren, müssen nach dem Prinzip der geringsten Berechtigung eingegrenzt werden. Ein lokaler Agent, der in der Entwicklung mit einem persönlichen API-Schlüssel lief, braucht nun ein passend eingegrenztes Service-Konto mit Audit-Logging.

Schritt 7: Überwachen und verbessern

Tool-Aufrufe, Datenzugriffsmuster, Fehlerraten und auffälliges Verhalten gehören kontinuierlich überwacht. Agenten verändern sich nach dem Deployment, weil ihre Inputs unvorhersehbar sind. Was ein Agent im Test tut, kann sich deutlich von seinem Verhalten mit echten Nutzereingaben unterscheiden.

Typische Fallstricke bei der Entwicklung von KI-Agenten

Die meisten Leitfäden zur Agent-Entwicklung drehen sich darum, Agenten zum Laufen zu bringen. Dieser Abschnitt zeigt, was danach schiefgeht. Die Beispiele stammen aus Praxiserfahrung mit produktiven KI-Workloads.

Überprivilegierte Agent-Identitäten

In der Entwicklung erhalten Agenten oft weitreichende IAM-Berechtigungen, damit sie „einfach funktionieren“. Diese Berechtigungen bleiben bis in die Produktion bestehen und vergrößern den Schadensradius unnötig. Agent-Identitäten sollten auf die minimalen Berechtigungen für jede konkrete Aufgabe beschränkt sein. Bei der Prüfung gilt dieselbe Sorgfalt wie bei Benutzerkonten von Menschen.

Nicht erfasste Agent-Lieferketten

Ein einzelner Agent kann von mehreren Modellen, Tool-Integrationen, MCP-Servern, Prompt-Vorlagen und Daten-Connectors abhängen. Daraus ergeben sich komplexe Anforderungen an die Sicherheit der KI-Lieferkette. Ohne klares Inventar dieser Komponenten, vergleichbar mit einer Software Bill of Materials (SBOM), können Teams ihre Angriffsfläche nicht bewerten, sobald eine Schwachstelle bekannt wird. Besonders kritisch ist das bei MCP-Servern, die oft von der Community gepflegt werden.

Vernachlässigtes Runtime-Verhalten

Statische Codeanalyse findet Konfigurationsprobleme, doch Agenten verhalten sich per Design nicht deterministisch. Prompt Injection, unerwartete Tool-Aufrufe und Versuche der Datenexfiltration zeigen sich erst zur Runtime durch reale Inputs. Teams, die Agenten nur während der Entwicklung testen, übersehen eine ganze Risikoklasse.

Schatten-Agenten („Shadow Agents“) und unkontrollierte Deployments

Frameworks senken die Einstiegshürde, und so starten Teams im gesamten Unternehmen Agenten ohne zentrale Transparenz oder Sicherheitsprüfung. Laut dem Report Wiz State of AI in the Cloud 2025 wächst die Zahl der KI-Dienste in Cloud-Umgebungen weit schneller, als die meisten Unternehmen sie inventarisieren und absichern können.

Offenlegung sensibler Daten über RAG und Wissensdatenbanken

Agenten mit Retrieval-Augmented Generation greifen auf Datastores mit potenziell sensiblen Informationen zu. Ohne passende Zugriffskontrollen können sie unbemerkt Daten preisgeben, die sie nie erreichen dürften. Ein Beispiel: Ein kundenseitiger Agent ist mit einer internen Wissensdatenbank verbunden, die öffentliche Dokumentation und interne Sicherheitsprozesse enthält. Fehlen klare Zugriffsgrenzen, kann der Agent auf eine geschickt formulierte Abfrage hin interne Prozesse preisgeben.

Absicherung von KI-Agenten über den gesamten Entwicklungszyklus

Sicherheit gehört in jede Phase der Agent-Entwicklung und lässt sich nicht erst nach dem Deployment nachrüsten. Agenten authentifizieren sich bei mehreren Diensten, verarbeiten nutzergesteuerte Inputs und handeln autonom. Dieses Zusammenspiel erfordert Best Practices für die Sicherheit von KI-Agenten, die Code-, Cloud- und Runtime-Kontext verbinden.

• In der Entwicklung: Scans prüfen den Agent-Code auf hartcodierte Zugangsdaten, unsichere Tool-Definitionen und verwundbare Abhängigkeiten. Vor dem Release wird die Agent-Logik auf unsichere Muster wie uneingeschränkten Tool-Zugriff oder fehlende Eingabevalidierung analysiert.

• Beim Deployment: Teams bewerten die Sicherheitskonfiguration der Cloud-Infrastruktur des Agenten, darunter Identitätsbindungen, Netzwerkerreichbarkeit, Verschlüsselung und Datenzugriff. Zudem setzen sie Konfigurations-Baselines für KI-Dienste durch und reduzieren Berechtigungen aus der Entwicklung auf ein produktionsgerechtes Maß.

• Zur Runtime: Monitoring überwacht das Live-Verhalten des Agenten auf Prompt Injection, nicht autorisierte Tool-Aufrufe, auffällige Datenzugriffe und unkontrollierte Aktionen, die erst durch reale Inputs auftreten.

Kein Tool, das nur eine einzelne Domäne abdeckt, liefert das vollständige Bild. Eine Schwachstelle im Agent-Code zählt nur, wenn der Agent mit Netzwerkerreichbarkeit und Zugriff auf sensible Daten läuft. Eine fehlkonfigurierte Identität zählt nur, wenn der Agent erreichbar ist und Nutzereingaben verarbeitet. Das Risiko entsteht im Zusammenspiel. Deshalb brauchen Unternehmen, die Agenten im großen Stil entwickeln, einen Weg, die Beziehungen zwischen Agent-Komponenten, Cloud-Ressourcen, Identitäten und Daten gemeinsam abzubilden.

Der Wiz-Ansatz zur Absicherung der Entwicklung von KI-Agenten

Wiz betrachtet KI-Agenten als vernetzte Cloud-Workloads statt als isolierte Anwendungen. Die Wiz AI-Application Protection Platform (AI-APP) sichert Agenten über ihren gesamten Lebenszyklus ab. Dazu verbindet sie Code-, Cloud- und Runtime-Kontext in einer einzigen Plattform.

So sichert Wiz den Entwicklungszyklus von Agenten ab:

• Entwicklung (Wiz Code & AI-BOM): Scannt Codebasen von Agenten, CI/CD-Pipelines und IDEs auf eingebettete Zugangsdaten, unsichere Tool-Definitionen und verwundbare AI SDKs. Die AI Bill of Materials erfasst jedes Modell, jedes Tool, jeden MCP-Server und jeden Daten-Connector und bildet so die vollständige Lieferkette ab.

• Deployment (Wiz Cloud): Bildet Infrastruktur, Identitätsbindungen und Datenzugriffe ab, um das reale Risiko zu bewerten. Die Agent Inventory View zeigt den Schadensradius verbundener Modelle und Tools, und integrierte Prüfungen erkennen Fehlkonfigurationen wie unverschlüsselte Endpunkte oder überprivilegierte Identitäten.

• Runtime (Wiz Defend): Überwacht den Live-Traffic von Agenten out-of-band und erkennt Prompt Injection, Fehlverhalten und die Ausführung bösartiger Modelle.

• Kontext (Wiz Security Graph): Verknüpft Risiken über Infrastruktur, Identitäten, Daten und Code hinweg und deckt ausnutzbare Angriffspfade auf. Der Graph markiert toxische Kombinationen, etwa einen öffentlichen Endpunkt, der mit einem Agenten mit Tool-Use-Fähigkeiten und Lesezugriff auf personenbezogene Daten (PII) verbunden ist.

Häufig gestellte Fragen