AI-Agent-Orchestrierung: Das Wichtigste für Sicherheitsteams

AI-Agent-Orchestrierung im Überblick

AI-Agent-Orchestrierung ist die koordinierte Steuerung mehrerer AI-Agenten, die über einen gemeinsamen Workflow komplexe, mehrstufige Aufgaben erledigen. Ohne sie zerfallen Multi-Agent-Systeme in isolierte Automatisierungen, die Arbeit doppelt erledigen, einander widersprechen und keinen Kontext teilen.

Im Zentrum jedes orchestrierten Systems steht ein Orchestrator-Agent. Diese Koordinationsebene zerlegt ein Ziel in Teilaufgaben, delegiert sie an spezialisierte Agenten, steuert den Datenfluss zwischen ihnen und setzt das Endergebnis zusammen. Im Grunde arbeitet er wie ein Projektmanager: Er entscheidet, wer was in welcher Reihenfolge erledigt und was passiert, wenn etwas schiefgeht.

Ein einzelner AI-Agent stößt bei komplexen Aufgaben schnell an Grenzen. Mit Orchestrierung lassen sich spezialisierte Agenten, jeweils für eine eng umrissene Funktion optimiert, zu einem System kombinieren, das End-to-End-Workflows abdeckt. Ein Beispiel ist die Rückerstattungsanfrage eines Kunden:

• Ein Agent ruft die Bestelldetails ab.

• Ein zweiter prüft die Rückgaberichtlinie.

• Ein dritter wickelt die Rückbuchung der Zahlung ab.

• Der Orchestrator legt die Reihenfolge dieser Schritte fest und behandelt Ausnahmen (etwa eine abgelaufene Rückgabefrist).

Darin unterscheidet sich Agent-Orchestrierung von klassischen Tools zur Workflow-Automatisierung wie Apache Airflow oder AWS Step Functions, die deterministische, vordefinierte Aufgabenfolgen ausführen. Agent-Orchestrierung ergänzt autonome Entscheidungen. Der Orchestrator wählt Agenten, Tools und Ausführungspfade dynamisch anhand von Zwischenergebnissen aus statt nach einem festen Skript. Genau diese fehlende Determiniertheit macht orchestrierte Agenten leistungsfähig und, wie sich noch zeigen wird, schwerer abzusichern.

Wachsende Bedeutung der AI-Agent-Orchestrierung

Unternehmen wechseln in hohem Tempo von AI-Tools mit Einzelzweck zu autonomen Multi-Agent-Systemen. Laut dem Wiz-Bericht State of AI in the Cloud 2025 nutzen inzwischen 85 % der Unternehmen AI-Services oder AI-Tools.

Mit jedem weiteren Agenten verschiebt sich der Engpass: weg vom Bau einzelner Agenten, hin zu ihrer Koordination. Ohne Orchestrierung arbeiten Agenten als unverbundene Automatisierungen ohne gemeinsamen Kontext, mit doppeltem Aufwand und ohne einheitliche Governance für Agent-Sicherheit. Ein Beispiel sind drei Marketing-Agenten, die mit verschiedenen SaaS-APIs und Cloud-Storage-Buckets verbunden sind. Dort lässt sich weder steuern, welcher Agent auf welche Daten zugreift, noch ein fehlgeschlagener Schritt wiederholen oder der End-to-End-Workflow auditieren.

Was in den meisten Diskussionen fehlt, ist der Blick auf die Cloud-Infrastruktur. Orchestrierte Agenten laufen auf echten Cloud-Services mit echten IAM-Rollen, Netzwerkkonfigurationen und Datenzugriffen. Die Orchestrierungsebene bestimmt, welche Cloud-Ressourcen in welcher Reihenfolge aktiviert werden. Damit wird sie zu einem kritischen Kontrollpunkt für Betrieb und Sicherheit und ist weit mehr als ein reines AI-Thema.

Funktionsweise der AI-Agent-Orchestrierung

Wie funktioniert AI-Agent-Orchestrierung? Orchestrierung folgt einem Lebenszyklus von der Planung über die Ausführung bis zum Feedback. Die Details unterscheiden sich je nach Framework, also den Softwarebibliotheken für die technische Grundlage der Agent-Koordination, etwa LangGraph, CrewAI oder AutoGen. Die zentralen Mechanismen bleiben aber gleich.

Komponenten eines Orchestrierungssystems

Jedes Orchestrierungssystem besteht aus denselben Grundbausteinen. Jeder davon entspricht direkt realer Cloud-Infrastruktur, und genau deshalb ist Orchestrierung ein Thema für die Cloud-Sicherheit.

Aus Sicherheitssicht ist jede Komponente mehr als Anwendungslogik. Sie ist eine Identität mit Berechtigungen, eine Menge erreichbarer Datenpfade und ein möglicher Pivot-Punkt für Angreifer. Wer Orchestrierungssicherheit verstehen will, muss diese Beziehungen abbilden, statt die Komponenten nur zu inventarisieren.

Der Orchestrator läuft auf einem Compute-Service. Sub-Agenten laufen typischerweise unter einer Cloud-Identität (zum Beispiel einer IAM-Rolle in AWS, einer Managed Identity in Azure oder einem Service-Konto in GCP/Kubernetes), die je nach Deployment-Architektur gemeinsam oder pro Agent genutzt wird. Tools rufen externe APIs auf, und gemeinsamer Speicher liegt oft in einer Vektordatenbank oder einem Objektspeicher. Jede Komponente in dieser Tabelle hat eine Cloud-Identität mit daran gebundenen Berechtigungen.

Lebenszyklus der Orchestrierung

Der Lebenszyklus umfasst fünf Phasen, wobei die Schritte zwei bis vier oft dynamisch zur Runtime ablaufen:

• Aufgabenzerlegung: Der Orchestrator erhält ein Ziel, zerlegt es in Teilaufgaben und legt fest, welche Agenten beteiligt werden.

• Agent-Auswahl und Delegation: Der Orchestrator weist Teilaufgaben anhand von Fähigkeiten und Verfügbarkeit spezialisierten Agenten zu.

• Ausführung und Datenfluss: Agenten erledigen ihre Aufgaben und geben Outputs an den Orchestrator oder direkt an nachgelagerte Agenten weiter. Tools werden bei Bedarf aufgerufen.

• State-Management und Kontextaustausch: Der Orchestrator hält einen gemeinsamen State vor, damit Agenten auf der Arbeit der anderen aufbauen, ohne Kontext zu verlieren.

• Ergebniszusammenführung und Feedback: Der Orchestrator sammelt Outputs, validiert Ergebnisse, behandelt Fehler und liefert das Endergebnis. Feedbackschleifen fließen in künftige Durchläufe ein.

Entscheidend ist: Der Orchestrator legt den Ausführungspfad anhand von Zwischenergebnissen fest statt nach einem festen Skript. Diese fehlende Determiniertheit macht orchestrierte Systeme leistungsfähig, aber auch schwerer vorherzusagen, zu testen und in der Runtime abzusichern.

Muster der AI-Agent-Orchestrierung

Orchestrierungsmuster beschreiben, wie Agenten koordiniert werden. Die meisten Produktivsysteme kombinieren mehrere Muster. Die Wahl des Musters wirkt sich direkt auf die Angriffsfläche aus, weil sie Datenflüsse und die Kommunikationswege zwischen Agenten bestimmt.

Sequenzielle Orchestrierung

Agenten führen Aufgaben nacheinander in einer festgelegten Reihenfolge aus, und der Output eines Agenten speist den nächsten. Das eignet sich für lineare Workflows wie Pipelines zur Dokumentenverarbeitung, ist für parallelisierbare Arbeit aber langsam.

• Beispiel: eine Pipeline für Compliance-Reviews, in der ein Extraktions-Agent Daten abruft, ein Agent zur Datenklassifizierung sie kennzeichnet und ein Reporting-Agent den Output erzeugt.

Parallele Orchestrierung

Mehrere Agenten führen Aufgaben gleichzeitig aus, der Orchestrator sammelt die Ergebnisse und gleicht sie ab. Das eignet sich für unabhängige Aufgaben wie die gleichzeitige Abfrage mehrerer Datenquellen. Das Muster ist schneller, erfordert aber Konfliktauflösung, wenn Outputs voneinander abweichen.

• Beispiel: ein Workflow für Threat Intelligence, der drei externe Feeds parallel abfragt und die Ergebnisse zusammenführt.

Hierarchische Orchestrierung

Ein übergeordneter Orchestrator delegiert an Orchestratoren auf mittlerer Ebene, die ihre eigenen Sub-Agenten steuern. Das hilft bei komplexen Workflows über mehrere Domänen hinweg, erhöht aber Latenz und Koordinationsaufwand.

• Beispiel: ein IT-Operations-System im Unternehmen, in dem ein übergeordneter Orchestrator Aufgaben an separate Orchestratoren für Netzwerk, Identitäten und Anwendungen weiterleitet.

Ereignisgesteuerte Orchestrierung

Agenten werden durch Ereignisse ausgelöst statt durch explizite Befehle des Orchestrators. Ein Agent veröffentlicht ein Ergebnis, nachgelagerte Agenten abonnieren es und reagieren darauf. Das Muster ist stark entkoppelt und skalierbar, erschwert aber das Nachverfolgen des Ausführungsflusses und das Debugging von Fehlern.

• Beispiel: eine Pipeline für Sicherheitsalarme, in der ein Erkennungs-Agent einen Fund veröffentlicht und damit unabhängig voneinander einen Anreicherungs-Agenten und einen Benachrichtigungs-Agenten auslöst.

Föderierte Orchestrierung

Mehrere autonome Orchestratoren koordinieren sich über Organisations- oder Systemgrenzen hinweg, und jeder verwaltet einen eigenen Agent-Pool. Das hilft bei teamübergreifenden Workflows, bringt aber Herausforderungen bei Vertrauen, Datenaustausch und Governance mit sich.

• Beispiel: Zwei Geschäftsbereiche betreiben jeweils eigene orchestrierte Agent-Systeme, teilen Ergebnisse aber über eine gemeinsame API für konsolidiertes Reporting.

Vorteile der AI-Agent-Orchestrierung

Der Nutzen von Orchestrierung wächst mit jedem Ausbau des Agent-Systems. Diese Ergebnisse zählen am meisten:

• Bewältigt Komplexität jenseits einzelner Agenten: Mehrstufige, domänenübergreifende Aufgaben übersteigen, was ein einzelnes Modell zuverlässig leisten kann. Orchestrierung zerlegt sie in handhabbare Teilaufgaben und leitet sie an Spezialisten weiter.

• Skaliert Agent-Fähigkeiten unabhängig voneinander: Einzelne Agenten lassen sich hinzufügen, ersetzen oder aktualisieren, ohne das gesamte System neu zu entwerfen. Ein besseres Modell für Zusammenfassungen passt hinein, ohne die Agenten für Abruf oder Aktionen anzufassen.

• Erhält Kontext über lang laufende Workflows: Dank gemeinsamem State-Management verlieren Agenten nicht aus dem Blick, was zuvor passiert ist. Das ist entscheidend für mehrstufige Kundeninteraktionen oder phasenweise Datenanalysen.

• Erhöht die Zuverlässigkeit durch Aufgabenisolierung: Fällt ein Agent aus, kann der Orchestrator den Schritt wiederholen, umleiten oder kontrolliert eingeschränkt weiterarbeiten, statt den gesamten Workflow abstürzen zu lassen.

• Erzeugt einen natürlichen Audit-Trail: Zentrale Orchestrierung schafft einen Logging-Punkt für jede Delegation, jeden Tool-Aufruf und jeden Datenaustausch. Das ist relevant für Compliance und die Untersuchung von Sicherheitsvorfällen.

Sicherheitsrisiken der AI-Agent-Orchestrierung

Die meisten Diskussionen über Agent-Orchestrierung behandeln Sicherheit als Randnotiz. In der Praxis erzeugen orchestrierte Agenten eine der komplexesten Angriffsflächen moderner Cloud-Infrastrukturen. Multi-Agent-Architekturen vergrößern die Angriffsfläche und erzeugen eine „Vertrauenskaskade“: Wird ein einzelner Knoten kompromittiert, kann das den Kontext und die Aktionen nachgelagerter Agenten vergiften. Manipuliert ein Angreifer den Output eines Agenten, fließen die verfälschten Daten an abhängige Agenten weiter und können die gesamte Orchestrierungskette beeinträchtigen.

Der Orchestrator als hochwertiges Angriffsziel

Der Orchestrator entscheidet, welche Agenten aufgerufen, welche Tools genutzt und welche Daten abgefragt werden. Das Risiko: Für die Tool-Auswahl ist der Orchestrator auf Eingaben in natürlicher Sprache angewiesen. Das macht ihn angreifbar für Prompt Injection, bei der bösartige Prompts oder präparierte Dokumente in Forschungsumgebungen Erfolgsquoten von bis zu 71 % erreichen, wenn sie die Entscheidungen von Agenten manipulieren. In realen Umgebungen variieren die Erfolgsquoten je nach Modellschutz, Eingabevalidierung und Umsetzung der Guardrails.

So sieht das in der Praxis aus: Ein Angriff per Prompt Injection zielt auf eine kundenseitige Agent-Schnittstelle. Die eingeschleuste Anweisung erreicht den Orchestrator, der die Aufgabe „interne Dokumente zusammenfassen“ an einen Sub-Agenten delegiert. Dieser hat Lesezugriff auf eine interne Wissensdatenbank mit personenbezogenen Daten (PII). Der Sub-Agent ruft die sensiblen Inhalte pflichtbewusst ab und gibt sie zurück. Keine einzelne Komponente wies für sich genommen eine Fehlkonfiguration auf. Das Risiko entstand erst aus dem Zusammenspiel.

Kaskadierende Agent-Identitäten und Berechtigungen

Jeder Agent in einer Orchestrierungskette läuft mit Cloud-Identitäten (IAM-Rollen, Service-Konten), die festlegen, auf welche Cloud-Ressourcen er zugreifen kann. Delegiert ein Orchestrator an einen Sub-Agenten, bestimmen dessen Berechtigungen den Blast Radius, falls dieser Agent kompromittiert wird.

Entwicklungsteams vergeben an Agenten häufig weitreichende, statische Berechtigungen, damit Aufgaben nicht fehlschlagen. Das führt oft zu überprivilegierten Zugriffen mit einem großen, ungeschützten Blast Radius. In einem orchestrierten System vervielfachen sich diese überprivilegierten Rollen über jeden Agenten der Kette. Ein Agent, der Bestelldaten abruft, braucht weder s3:* noch secretsmanager:GetSecretValue ohne Einschränkung auf bestimmte Ressourcen.

Gegenmaßnahmen gegen überprivilegierte Agent-Identitäten:

• Jeder Agent erhält eine eigene, eng begrenzte Identität mit den minimal erforderlichen Berechtigungen (getrennte Rollen für „Read-only-Abruf“ und „Schreib-/Aktionsoperationen“).

• Tool-Allowlists legen fest, welche Tools jeder Agent aufrufen darf.

• Secrets-Brokering mit kurzlebigen Zugangsdaten ersetzt statische API-Schlüssel.

• Egress-Kontrollen beschränken ausgehende Verbindungen auf freigegebene Domains.

• Strukturierte Audit-Logs mit Korrelations-IDs erfassen alle Agent- und Tool-Aufrufe.

Offenlegung von Daten durch Tool-Aufrufe und RAG

Orchestrierte Agenten greifen über Tool-Aufrufe häufig auf Datastores, Vektordatenbanken, RAG-Wissensdatenbanken und externe APIs zu. Der Orchestrator bestimmt, welche Tools aufgerufen werden. Die zurückgegebenen Daten fließen jedoch in den Agent-Kontext und können Nutzern oder nachgelagerten Agenten angezeigt werden.

Ohne Transparenz darüber, welche Daten jeder Agent erreichen kann und ob diese sensibel, klassifiziert oder reguliert sind, können Teams die tatsächlichen Auswirkungen eines kompromittierten Orchestrierungs-Workflows nicht bewerten.

Supply-Chain-Risiken in Orchestrierungs-Frameworks

Orchestrierungs-Frameworks (LangGraph, CrewAI, AutoGen), MCP-Server-Implementierungen, Modellanbieter, Embedding-Bibliotheken und Clients für Vektordatenbanken bilden eine tiefe Kette von Dependencies. Laut der zitierten Studie umfasst das Ökosystem über 12.000 Tools auf 1.360 MCP-Servern. Jede dieser Implementierungen ist Code und unterliegt damit klassischen Risiken der Software-Lieferkette, darunter Schwachstellen in Dependencies, bösartige Pakete und unsichere Standardeinstellungen. Bei der Analyse öffentlich verfügbarer MCP-Server-Implementierungen stellten Forschende fest, dass 43 % Command-Injection-Schwachstellen enthielten, während 30 % uneingeschränktes Abrufen von URLs zuließen. Eine Deserialisierungsschwachstelle in einer gemeinsam genutzten Bibliothek oder ein bösartiger MCP-Server kann den gesamten Orchestrierungsgraphen kompromittieren.

Shadow AI und unkontrollierte Verbreitung von Agenten

Entwicklungsteams können orchestrierte Agent-Workflows mit verwalteten Cloud-Services aufsetzen, an interne Datastores anbinden und über APIs bereitstellen, oft ohne Transparenz für das Sicherheitsteam. Zur Absicherung gehört daher eine vollständige Inventarisierung aller Agenten und Orchestrierungstools. Dazu zählen auch die Integrationen, Berechtigungen und Daten, auf die diese Agenten zugreifen.

Das Sicherheitsteam von Synthesia hat diese Herausforderung selbst erlebt. Überlastet von Alarmen ohne Kontext, brauchte das Team einen Weg, um zu erkennen, welche Risiken in seiner AI-gestützten Umgebung tatsächlich relevant waren. Wiz lieferte kontextbezogene, priorisierte Transparenz, sodass sich das Team auf echte Bedrohungen konzentrieren konnte, statt dem Alarmrauschen hinterherzulaufen.

Typische Fehler beim Deployment von Agent-Orchestrierung

Diese Fehler passieren Teams häufig beim Übergang vom Prototyp zur Produktion mit orchestrierten Agenten:

• Orchestrierung als deterministisch behandeln: Orchestrierte Agenten treffen Entscheidungen zur Runtime. Wer nur den Happy Path testet, übersieht emergentes Verhalten bei unerwarteten Eingaben, deshalb braucht es Runtime-Monitoring und nicht nur Tests vor dem Deployment.

• Agenten dieselben Berechtigungen wie dem Entwicklungsteam geben: Ausführungsrollen von Agenten sollten dem Prinzip der geringsten Berechtigung folgen. Ein Agent, der Bestelldaten abruft, braucht keinen Schreibzugriff auf die Bestelldatenbank.

• Keine Observability für die Kommunikation zwischen Agenten: Ohne Logging und Tracing über die Orchestrierungskette hinweg werden Debugging und die Untersuchung von Sicherheitsvorfällen zum Ratespiel.

• Den Blast Radius von gemeinsamem Kontext ignorieren: Teilen Agenten ihren State über einen gemeinsamen Speicher, kann ein kompromittierter oder fehlerhafter Agent den Kontext für jeden nachgelagerten Agenten vergiften.

• Deployment ohne Inventar der Agent-Fähigkeiten: Wer nicht weiß, welche Agenten existieren, welche Tools sie aufrufen, auf welche Daten sie zugreifen und welche Berechtigungen sie haben, kann die eigene Angriffsfläche nicht bewerten. Das ist das Agent-Pendant zu Shadow IT.

• Keine durchgesetzte Tool-Allowlist: Können Agenten dynamisch jedes Tool aufrufen oder sich uneingeschränkt mit jedem MCP-Server verbinden, wird die Orchestrierung zu einer unbegrenzten Ausführungsebene. Abhilfe schaffen explizite Allowlists erlaubter Tools pro Agent und die Validierung von Tool-Argumenten vor der Ausführung.

AI-Agent-Orchestrierung und verwandte Konzepte im Vergleich

Mehrere Begriffe überschneiden sich mit AI-Agent-Orchestrierung, und in Suchanfragen werden sie oft vermischt. Diese Tabelle grenzt sie voneinander ab:

In der Praxis verbinden die meisten AI-Systeme in Unternehmen diese Konzepte. Ein orchestriertes Agent-System kann Airflow für Batch-Jobs, MLOps-Pipelines für Modellaktualisierungen und Agent-Orchestrierung für adaptive Workflows in Echtzeit nutzen. Die Herausforderung für die Sicherheit: Jede Ebene bringt eigene Identitäten, Berechtigungen und Datenzugriffsmuster mit.

AI-Agent-Orchestrierung mit Wiz absichern

Für die Absicherung von AI-Agenten braucht es eine einheitliche Sicht auf Code, Cloud, Identitäten, Daten und Runtime. Die Wiz AI-Application Protection Platform (AI-APP) liefert diese gemeinsame Sicht und hilft Teams, reale Risiken schnell zu reduzieren.

So sichert Wiz Orchestrierungs-Workflows in jeder Phase ab:

• Entwicklung (Wiz Code): Scannt Repositorys und CI/CD-Pipelines auf hartcodierte Secrets, zu weit gefasste Agent-Definitionen und unsichere MCP-Integrationen, bevor diese in die Produktion gelangen.

• Deployment (Wiz AI-SPM): Erkennt und inventarisiert automatisch den gesamten AI-Footprint, einschließlich Shadow AI. Wiz AI-SPM erstellt eine AI-BOM, um Dependencies abzubilden, und markiert Fehlkonfigurationen im Cloud-Hosting.

• Kontext (Wiz Security Graph): Verknüpft isolierte Signale zu Kontext und bildet die gesamte Kette ab (z. B. einen öffentlich erreichbaren Endpunkt, der zu einem überprivilegierten Agenten mit Zugriff auf personenbezogene Daten (PII) führt). So deckt der Security Graph automatisch toxische Kombinationen auf, die ausnutzbare Angriffspfade erzeugen.

• Runtime (Wiz Defend): Korreliert Cloud-Ereignisse und Runtime-Telemetrie, um Anomalien wie Prompt Injection, eigenmächtige Aktionen und unautorisierten Datenzugriff zu erkennen. Eine Inline-Prüfung des Datenverkehrs ist dafür nicht erforderlich.

Nachweisbare Wirkung: Das Team von PROS hat 19 Sicherheitstools in Wiz konsolidiert. Mit dem Security Graph konnten Entwicklungsteams Angriffspfade nachvollziehen und alle kritischen Probleme innerhalb von 90 Tagen beseitigen.

Ob beim Absichern des ersten Orchestrierungs-Workflows oder beim Verwalten Hunderter Agenten in Produktionsumgebungen: Wiz liefert die einheitliche Transparenz, um Risiken über den gesamten AI-Stack hinweg zu verstehen und zu reduzieren.

Erfahren Sie, wie Wiz Ihrem Team helfen kann, Transparenz über orchestrierte AI-Agenten, Identitäten, Datenzugriffe und potenzielle Angriffspfade zu gewinnen. Wiz in Aktion erleben

Häufig gestellte Fragen