Absicherung Ihrer Multi-Agenten-Workflows mit Agent-zu-Agent-Verbindungen

Der blinde Fleck beim Identity-Management in Multi-Agenten-Workflows

Genau jetzt könnte in Ihrem Unternehmen ein KI-Agent autonom einen anderen Agenten aufrufen. Ein Vertriebsagent ruft die Zahlungshistorie eines Kunden von einem Finanzagenten ab. Ein Überwachungsagent aktiviert einen Diagnoseagenten, um einen ausgefallenen Dienst zu untersuchen. Arbeit, die früher Dutzende von manuellen Übergaben erforderte, ist nun in Sekunden abgeschlossen.

Und genau das ist das Problem: Jede einzelne dieser Übergaben ist ein Zugriffsereignis, das überwacht und gesteuert werden muss. Und die meisten Security-Teams haben keinen Einblick darin. Gleichzeitig programmieren KI-Teams, die diese Multi-Agenten-Workflows entwickeln, die Autorisierung zwischen jedem einzelnen Agentenpaar individuell von Hand. Dabei verknüpfen sie Punktlösungen, ohne eine zentrale Möglichkeit zu haben, das Geschehen zu überblicken oder zu steuern.

Multi-Agenten-Architekturen, ob von Menschen, von Maschinen oder zunehmend von Agenten selbst initiiert, sind bereits in Produktion. Aber die Identity-Ebene darunter fehlt. Ohne eine Identity-Ebene, die speziell für Agent-zu-Agent-Interaktionen entwickelt wurde, werden diese Verbindungen zu blinden Flecken: Ungesteuert, nicht zuzuordnen und unmöglich einem Audit zu unterziehen.

Neu: Sichere Agent-zu-Agent-Verbindungen

Um Multi-Agenten-Workflows zu sichern und zu verwalten, nutzt Okta for AI Agents Oktas Konzept für das sichere agentenbasierte Unternehmen, ein strategisches Framework zur Erkennung, Autorisierung und Verwaltung autonomer KI-Agenten. Die zweite Säule dieses Konzepts stellt die Frage: „Womit können sie sich verbinden?“. Der Fokus liegt dabei auf der Sicherung von Agent-zu-Ressource-Verbindungen, um Agenten einen zweckgebundenen, auditierten Zugriff auf die benötigten Unternehmensdaten und -systeme zu gewähren.

Nun erweitern wir dasselbe sichere Konnektivitätsmodell auf Multi-Agenten-Workflows. Die gleichen Grundbausteine, die heute Menschen und Anwendungen absichern, wie etwa Agentenidentitäten, bereichsbezogene Anmeldedaten und Audit-Zuordnung, erstrecken sich nun auch auf die Verbindungen zwischen Agenten.

Im Mittelpunkt stehen dabei Agent-zu-Agent-Verbindungen, eine neue Funktion von Okta for AI Agents, mit der Sie Folgendes festlegen können: 

• Verbindungsrichtlinien pro Agent 
• Welche Upstream Dienste und Agenten können einen Agenten aufrufen? 
• Agentenberechtigung (worauf er zugreifen kann)
• Session-Dauer (wie lange dieser Zugriff andauert)

Die Identität bleibt bei jeder Übergabe erhalten, sodass jede Verbindung über den gesamten Workflow hinweg überprüfbar bleibt.

Für Security-Teams bedeutet das, dass jeder Agent-zu-Agent-Aufruf gesteuert, eingegrenzt und vollständig überprüfbar ist. Für Entwickler:innen bedeutet dies, dass sie Multi-Agenten-Workflows erstellen können, ohne die Autorisierung für jeden Agenten programmieren zu müssen. Sie brauchen Autorisierungs- und Zugriffsrichtlinien nur einmal in Okta zu definieren, und jeder Agent in der Delegationskette arbeitet automatisch mit diesen definierten Richtlinien.

Wie funktionieren Agent-zu-Agent-Verbindungen?

Jedes Mal, wenn ein Agent einen anderen aufruft, überprüft Okta, ob die Verbindung autorisiert ist, beschränkt die Daten auf das, was für die Aufgabe erforderlich ist, und protokolliert, wer in wessen Namen gehandelt hat, sodass der Multi-Agenten-Workflow durchgängig kontrolliert wird.

Schrittweiser Multi-Agenten-Flow

Um zu sehen, wie dies funktioniert, verfolgen wir eine einzelne Anfrage durch den Multi-Agenten-Workflow. Stellen Sie sich eine routinemäßige Aufgabe zur Berichterstellung vor, die von zwei Agenten bearbeitet wird:

• Benutzerassistent-Agent: Handelt im Namen des Mitarbeitenden
• Datenanalyst-Agent: Ruft Daten aus sensiblen Datenbanken ab

So sieht der Flow aus:

1. Der/die Benutzer:in bittet den Benutzerassistent-Agenten: „Erstelle mir einen Q4-Bericht.“
2. Der Benutzerassistent-Agent benötigt Daten, daher ruft er den Datenanalyst-Agenten „im Auftrag von [Benutzer:in]“ auf.
3. Okta prüft die Richtlinie: Darf der Benutzerassistent-Agent den Datenanalyst-Agenten aufrufen? Darf der Datenanalyst-Agent diese Daten mit dem/der Benutzer:in teilen?
4. Wenn ja, stellt Okta ein temporäres Token aus, das besagt: „Datenanalyst-Agent, diese Anfrage stammt von [Benutzer:in] über [Benutzerassistent-Agent]. Sie können X, Y, Z teilen."
5. Der Datenanalyst-Agent validiert das Token, gibt nur das weiter, was erlaubt ist, und protokolliert die Anfrage.
6. Der Benutzerassistent-Agent verwendet die Daten, um den Bericht zu erstellen, und gibt ihn an den/die Benutzer:in zurück.
7. Alles ist auditierbar. Das Log zeigt: Benutzer:in → Benutzerassistent-Agent → Datenanalyst-Agent.

Drei Prinzipien machen dies möglich:

•  Explizite Allow-Listen: Sie können festlegen, welche Agenten welche anderen Agenten aufrufen dürfen.
•  Bereichsbezogene Berechtigungen: Sie sollten jedem nachgelagerten Agenten nur die Berechtigungen erteilen, die für die jeweilige Aufgabe benötigt werden.
•  Verifizierbare Delegierungsketten: Werden mit jedem Token übertragen, sodass das Audit-Protokoll erfasst, wer was autorisiert hat.

Das Ergebnis: Security-Teams erhalten vollständige Transparenz über jede Aktion des Agenten. Entwickler:innen müssen keinen Autorisierungscode zwischen Agenten mehr schreiben und können Multi-Agenten-Workflows schneller bereitstellen.

Warum die Multi-Agenten-Delegationskette vertrauenswürdig bleibt

Zwei Dinge sorgen dafür, dass die Delegationskette vertrauenswürdig bleibt: 

1. Jeder Agent kann sowohl als Client als auch als Ressource fungieren. 
2. Jedes Token enthält einen vollständigen, überprüfbaren Nachweis darüber, wer was autorisiert hat. Die Autorisierung erfolgt zur Laufzeit und die Aktion wird im Audit-Log gespeichert.

Agenten, die sowohl als Clients als auch als Ressourcen fungieren

Jeder Agent in Okta ist sowohl ein Client als auch eine Ressource. Das ist deshalb so wichtig, weil Agenten in einem echten Multi-Agenten-Workflow nicht einfach nur am Ende einer Verbindung sitzen – sie sitzen mittendrin. Jeder Agent kann Anfragen an andere Agenten oder Dienste initiieren und Anfragen von diesen empfangen. Diese Doppelrolle macht die Orchestrierung möglich.

• Als Client: Der Agent kann andere Agenten oder Dienste aufrufen
• Als Ressource: Andere Agenten können diesen Agenten aufrufen (sofern die Richtlinie dies zulässt)

Ein einzelner Agent kann sowohl spezialisiert als auch orchestrierend sein, ohne die Vertrauenskette zu unterbrechen.

Beibehaltung des Kontexts über tokenbasierte Delegationsdatensätze

Wenn Okta ein Token für einen Agent-zu-Agent-Aufruf ausstellt, enthält dieses eine Aufzeichnung des gesamten Pfads:

• „Dies ist für Benutzer:in A“
• „Benutzer:in A hat an den Assistenz-Agenten delegiert“
• „Der Assistenz-Agent delegierte an den Datenanalyst-Agenten“
• „Der Datenanalyst-Agent ist berechtigt, X, Y, Z zu tun“

Okta nimmt die vollständige Delegierungskette in das Token auf, damit der empfangende Agent die Autorisierung vor der Ausführung überprüfen kann. Das Okta Audit-Log erfasst die Delegationskette für jeden Aufruf und bewahrt sie noch lange nach Ablauf des Tokens selbst auf. 

Wenn etwas schiefgeht, wie beispielsweise bei einem Sicherheitsvorfall, einer Audit-Anfrage oder einer Compliance-Prüfung, können Sie das Audit-Protokoll abrufen und genau nachvollziehen, was passiert ist, wer es autorisiert hat und ob es der Richtlinie entsprach. Kein manuelles Durchsuchen von Logs. Kein Korrelationsaufwand.

Analyse von menschlich vs. maschinell gesteuerten Flow-Mustern

Unabhängig davon, ob ein Workflow von einem Menschen oder einer Maschine gestartet wird, bildet eine einzige Identität den Anker für die gesamte Kette. Jeder nachgelagerte Agent handelt unter dieser Autorität, und jeder Schritt ist ihr zuzuordnen. Agent-zu-Agent-Verbindungen unterstützen heute beide Muster.

Muster 1: Ein Mensch startet die Kette

Ein:e Benutzer:in meldet sich an und fordert einen Agenten auf, eine Aktion auszuführen. Dieser Agent ruft möglicherweise andere Agenten auf, um die Aufgabe zu erledigen, aber die Identität des Menschen ist der Anker.

Beispiel: Mitarbeiter:in fragt: „Gib mir eine Zusammenfassung der Q4-Kennzahlen.“

1. Der Zusammenfassungs-Agent ruft den Dashboard-Agenten (im Auftrag des Mitarbeitenden) auf
2. Der Dashboard-Agent ruft den Datenbank-Agenten (im Auftrag des Mitarbeitenden) auf

Die Identität des Mitarbeitenden durchläuft die gesamte Kette und jeder Schritt wird unter seinem Namen protokolliert.

Was Okta im Audit-Log erfasst: „Der Mitarbeitende hat den Zusammenfassungs-Agenten autorisiert, den Dashboard-Agenten aufzurufen. Der Dashboard-Agent hat Kennzahlen vom Datenbank-Agenten innerhalb des Zugriffsbereichs des Mitarbeitenden abgerufen."

Muster 2: Ein Dienst startet die Kette 

Unternehmen verfügen über jahrzehntealte Service-Apps, ETL-Pipelines, geplante Aufgaben und Microservices, die deterministische Workloads ausführen. Diese Systeme integrieren nun KI.

Beispiel: Ein Überwachungsdienst erkennt eine CPU-Spitze.

1. Der Monitoring-Dienst ruft den Diagnose-Agenten auf
2. Der Diagnose-Agent ruft den Protokollanalyse-Agenten auf

Kein:e Benutzer:in hat die Anfrage initiiert. Der Überwachungsdienst ist der Client und der Diagnose-Agent ist seine Ressource, und die Berechtigung des Dienstes durchläuft die gesamte Kette.

Was Okta im Audit-Log aufzeichnet: „Der Überwachungsdienst hat den Diagnose-Agenten autorisiert, den Protokollanalyse-Agenten aufzurufen. Der Protokollanalyse-Agent kann Produktions-Logs für den Überwachungsdienst analysieren.“

Wesentliche Unterschiede zwischen den beiden Mustern

Das Ergebnis: Ein Governance-Modell, unabhängig davon, wo die Delegationskette beginnt. Security-Teams erhalten eine vollständige Rückverfolgbarkeit über alle von Menschen und Maschinen initiierten Workflows hinweg, wobei jede Übergabe protokolliert wird. KI-Teams erhalten eine Autorisierung, die immer gleich funktioniert, unabhängig davon, ob ein:e Benutzer:in oder ein Dienst den Ursprung bildet. Somit muss nicht für jedes Muster eine separate Logik entwickelt und gewartet werden.

Muster 3: Ein autonomer Agent startet die Kette (demnächst verfügbar)

Ein drittes Muster folgt in Kürze: On-behalf-of-self, bei dem ein autonomer Agent völlig eigenverantwortlich und ohne jegliche Delegierung gemäß einer Richtlinie, die vorab durch eine:n Administrator:in genehmigt wurde, handeln kann. Mit diesem Muster können Sie autonome Agenten innerhalb einer vordefinierten Richtlinie ausführen, vollständig geprüft und kontrolliert. 

Zusammenführung von Multi-Agenten-Workflows unter zentraler Governance

Agenten rufen bereits andere Agenten in Ihrer Umgebung auf, aber nichts steuert diese Aufrufe. Die Frage war nie, ob Agenten andere Agenten aufrufen würden; es geht darum, ob Sie verantworten können, was passiert, wenn sie es tun.

Genau das macht Okta for AI Agents möglich. Indem Sie dieselben Identity-Funktionen, die Ihre Nutzer:innen, Apps und Agenten schützen, auf die Verbindungen zwischen Agenten ausweiten, holen Sie den Multi-Agenten-Workflow aus dem toten Winkel und unterstellen ihn der Governance. Agent-zu-Agent-Verbindungen bietet Ihnen die Allow-Listen, bereichsbezogenen Berechtigungen und die verifizierbare Kette, die eine sichere Skalierung autonomer Workflows ermöglichen.

Da Multi-Agenten-Architekturen immer komplexer werden, werden die Unternehmen, die sich durchsetzen, nicht nur schnell agieren; sie werden jederzeit nachweisen können, wer was in wessen Auftrag und im Rahmen welcher Richtlinie getan hat.

Sind Sie bereit, Ihre Multi-Agenten-Workflows zu steuern?

Early Access für Agent-to-Agent Connections ist jetzt verfügbar für Okta-Kund:innen. Wenden Sie sich an Ihr Okta-Account-Team, um sich zu registrieren.

Sehen Sie sich an, wie diese Kontrollen für KI-Agenten in der Praxis funktionieren. Nehmen Sie an unserem Okta-Streamcast teil, um mehr darüber zu erfahren, wie Agent-Governance aussieht, wenn die Identität der Kontrollpunkt ist. 

Diese Materialien dienen ausschließlich allgemeinen Informationszwecken und stellen keine Rechts-, Datenschutz-, Sicherheits-, Compliance- oder Geschäftsberatung dar. Sie sind dafür verantwortlich, Beratung zu Sicherheits-, Datenschutz-, Compliance- oder Geschäftsfragen von Ihren eigenen professionellen Berater:innen einzuholen. Jegliche Erwähnung zukünftiger Produkte, Funktionen, Funktionalitäten oder Zertifizierungen in diesem Blog dient ausschließlich Informationszwecken. Diese Angaben stellen keine Lieferzusagen dar und sollten nicht als Grundlage für Kaufentscheidungen dienen. © Okta, Inc. und verbundene Unternehmen. 2026.