Governance für Multi-Agenten-Systeme: Agenten-Identität, A2A und das Agent Gateway

Single-Agenten-Systeme rufen Modelle und Tools auf. Multi-Agenten-Systeme fügen eine neue Komponente hinzu: Agenten, die Agenten aufrufen. Dieser East-West-Traffic – ein Orchestrator, der Aufgaben an Sub-Agenten delegiert, oder Agenten, die sich gegenseitig Arbeit über das noch junge Agent2Agent-Protokoll zuspielen – ist der Bereich, in dem Kosten explodieren, der Blast Radius wächst und die Frage „Welcher Agent hat was getan?“ unbeantwortbar wird. Die Protokolle standardisieren zwar, wie Agenten einander entdecken und Aufgaben austauschen, und bieten Sicherheits-Hooks – sie schreiben jedoch weder Ihr Enterprise-Identitätsmodell, Ihren Policy-Graphen, Ihr Budgetmodell noch Ihre Observability- und Control-Plane vor. Dieser Beitrag beschreibt diese Governance-Ebene und warum sie an das Gateway gehört.

Tomás, ein Platform Engineer, wurde von einem Kostenalarm und einem Rätsel überrascht. Über Nacht hatte der neue Multi-Agenten-Forschungs-Workflow des Unternehmens mehr verbraucht als im gesamten Vormonat. Ein Orchestrator-Agent delegierte Teilaufgaben an eine Gruppe von Sub-Agenten; ein Sub-Agent stieß auf einen transienten Fehler und versuchte es erneut, indem er den Orchestrator wieder aufrief, der erneut delegierte – eine Schleife, die stundenlang lief. Bis zum Morgen hatten sich die Agenten zehntausende Male gegenseitig aufgerufen. Tomás wollte wissen, welcher Agent den Prozess gestartet hatte und wo die Schleife entstanden war, konnte es aber nicht herausfinden: Jeder Agent authentifizierte sich mit demselben geteilten Service-Key, die Aufrufe zwischen den Agenten wurden nicht als Graph aufgezeichnet, und es gab kein pro Agent definiertes Rate-Limit, das hätte greifen können. Das System verfügte über Governance für Aufrufe an den Modellanbieter, aber so gut wie keine für Aufrufe zwischen den eigenen Agenten.

Dies ist die Lücke, die Multi-Agenten-Systeme aufreißen. In dem Moment, in dem Agenten beginnen, Aufgaben aneinander zu delegieren, entsteht ein neues internes Netzwerk – eines ohne Identität, ohne Richtlinien und standardmäßig ohne Tracing. Agenten-Frameworks helfen beim Aufbau des Workflows, aber nicht bei dessen Governance. Dieser Beitrag zeigt, wie Sie diesem internen Netzwerk dieselbe Identität, dieselben Limits und dieselbe Observability verleihen, die Sie bei einem Microservice-Mesh als selbstverständlich voraussetzen würden.

1. Das neue Traffic-Muster: Agenten rufen Agenten auf

Bisher war der Traffic am Gateway meist North-South: Eine Anwendung ruft ein Modell auf, möglicherweise über ein Tool. Multi-Agenten-Systeme fügen East-West-Traffic hinzu – Agenten, die andere Agenten aufrufen. Ein Orchestrator delegiert an Spezialisten; ein Spezialist konsultiert einen anderen; Ergebnisse fließen zurück. Das noch junge Agent2Agent-Protokoll (A2A) gibt dem einen standardisierten Rahmen: Agenten veröffentlichen Fähigkeitsbeschreibungen (Agent Cards), die andere entdecken können, und tauschen Aufgaben sowie Nachrichten über eine gemeinsame Schnittstelle aus – ähnlich wie MCP standardisiert hat, wie Agenten auf Tools zugreifen.

Die Analogie zum Übergang von Monolithen zu Microservices ist hier sehr hilfreich. Sobald Ihre Agenten miteinander kommunizieren, haben Sie ein verteiltes System mit dessen typischen Fehlermodi: kaskadierende Retries, Zyklen, Fan-out-Verstärkung und der Verlust eines klaren Call-Stacks. Und wie bei Microservices besteht die Lösung nicht darin, sich zu wünschen, die Aufrufe gäbe es nicht, sondern sie hinter eine Ebene zu legen, die jedem Aufrufer eine Identität, jedem Aufruf eine Richtlinie und jedem Flow ein Trace zuweist. Diese Ebene ist für Agenten das Agent-Gateway.

2. Agenten-Identität: Warum ein geteilter Service-Key nicht ausreicht

Das Grundproblem bei Tomás war die Identität. Wenn sich jeder Agent mit einem einzigen geteilten Service-Key authentifiziert, kann das System seine Agenten buchstäblich nicht voneinander unterscheiden – was bedeutet, dass es sie nicht unterschiedlich autorisieren, Kosten nicht separat zuordnen und nicht nachvollziehen kann, welcher Agent gehandelt hat.

Die Lösung besteht darin, jedem Agenten eine eigene Identität zu geben, die am Gateway ausgestellt und verifiziert wird, und diese bei jedem Aufruf des Agenten weiterzureichen – sei es an ein Modell, ein Tool oder einen anderen Agenten. Diese Identität ist der Ankerpunkt für alle nachgelagerten Kontrollmechanismen: Autorisierungsentscheidungen, Rate-Limits, Kostenzuordnung und Trace-Attribution basieren alle auf der Frage „Welcher Agent?“.

Jeder Agent trägt bei jedem Hop seine eigene Identität (illustrativ)

# The gateway issues and verifies a per-agent identity, not a shared key.
ctx = AgentContext(
    agent_id="agent:research",          # this agent's own identity
    on_behalf_of="user:tomas",          # the human principal, preserved end-to-end
    run_id="run_4f9c",                  # correlates every hop of one workflow
    depth=2,                            # how deep in the delegation chain we are
)

# Propagated when this agent delegates to another agent or calls a tool:
gateway.invoke(target="agent:writer", context=ctx, payload=task)

Die Zentralisierung der Identität bei TrueFoundry's Agent Gateway – das Authentifizierung, Identität und Service-Account-Management für Agenten auf Gateway-Ebene verwaltet – bedeutet, dass die Identität einmalig etabliert und überall downstream als vertrauenswürdig eingestuft wird, anstatt dass jedes Agenten-Framework sein eigenes Schema erfindet. Die Bewahrung des menschlichen Principals (in dessen Auftrag der Workflow läuft) neben der Agenten-Identität stellt sicher, dass die Autorisierung und Auditierung des Endbenutzers selbst drei Delegationsstufen tief intakt bleibt.

3. A2A-Autorisierung und Policy: Welcher Agent darf welchen aufrufen

Identität ermöglicht Autorisierung, und in einem Multi-Agenten-System sind die Fragen konkret. Darf der Forschungs-Agent den Schreib-Agenten aufrufen oder nur der Orchestrator? Darf ein Sub-Agent externe Tools direkt aufrufen oder nur über seinen Parent? Welche Agenten dürfen Budgets belasten? Wenn man dies als Policy-as-Code ausdrückt – nach dem gleichen Cedar- oder OPA-Ansatz wie in den Governance- und Routing-Beiträgen –, werden die erlaubten Verbindungen des Agenten-Graphen explizit und überprüfbar, anstatt implizit im Code verborgen zu bleiben.

Autorisierung pro Agent für East-West-Aufrufe (illustrative Policy)

# Default-deny: an agent may only invoke agents it is explicitly allowed to.
allow if principal.agent_id == "agent:orchestrator"
      and action == "invoke"
      and resource.agent_id in ["agent:research", "agent:writer", "agent:critic"]

# Sub-agents may NOT invoke the orchestrator — this edge is what created the loop.
deny  if principal.agent_id in ["agent:research", "agent:writer"]
      and resource.agent_id == "agent:orchestrator"

# Only the research agent may reach external search tools.
allow if principal.agent_id == "agent:research"
      and resource.kind == "mcp_tool"
      and resource.name == "web_search"

Beachten Sie die zweite Regel: Eine Richtlinie, die es Sub-Agenten untersagt, den Orchestrator erneut aufzurufen, hätte Tomás' Schleife bereits beim ersten Hop unterbrochen, unabhängig von einem Ratenlimit. Autorisierung ist hier nicht nur eine Sicherheitsmaßnahme; die Einschränkung der Struktur des Agenten-Graphen ist auch der Weg, um ganze Klassen von außer Kontrolle geratenem Verhalten zu verhindern. Das Gateway wird zum Durchsetzungspunkt, wenn es der einzige Ort ist, über den jeder Ost-West-Aufruf geleitet wird.

Es ist hilfreich, präzise zu unterscheiden, was die Protokolle festlegen und was sie Ihnen überlassen. Discovery und Transport sind standardisiert; das Identitätsmodell, Richtlinien, Budgets und der Durchsetzungspunkt hingegen nicht:

4. Begrenzung des Schadensradius: Schleifen, unkontrolliertes Fan-Out und Ratenlimits

Selbst mit einer guten Autorisierung scheitern Multi-Agenten-Systeme auf eine Weise, wie es bei einzelnen Aufrufen nicht der Fall ist, da die Schadenseinheit die Kaskade ist. Ein erneuter Versuch, der eine erneute Delegation auslöst, kann einen Kreislauf bilden; ein Agent, der sich auf viele untergeordnete Agenten verzweigt, kann eine Anfrage in Tausende vervielfachen; ein langsamer Sub-Agent kann einen gesamten Workflow blockieren. Dies sind die Probleme der "Thundering Herd" und der schleichenden Eskalation auf Agenten-Ebene, die man bereits kennt aus Routing und Failover auf der Modellebene.

Die Eindämmung erfolgt in Schichten. Ein Limit für die Delegationstiefe begrenzt, wie tief die Kette rekursiv verlaufen kann, und unterbricht Zyklen strukturell. Ratenlimits pro Agent begrenzen, wie oft ein Agent andere aufrufen kann, sodass eine Schleife an eine Obergrenze stößt, anstatt die ganze Nacht durchzulaufen. Timeouts und die Erkennung von Blockaden verhindern, dass ein Agent ewig auf ein untergeordnetes Element wartet. Und ein globales Budget pro Lauf begrenzt die Gesamtkosten eines Workflows, unabhängig von seiner Form. Das Agent Gateway von TrueFoundry dokumentiert die relevanten Primitive – Wiederholungsrichtlinien, Fallback-Pfade, Timeouts und Schutzmaßnahmen gegen Endlosschleifen oder blockierte Agenten sowie token- und kostenbasierte Kontingente pro Agent, Workflow oder Umgebung. Die genaue Konfigurationsstruktur unten dient der Veranschaulichung; die Primitive sind das, was auf der Produktseite beschrieben wird.

Kontrolle des Schadensradius für einen Multi-Agenten-Lauf (beispielhafte Gateway-Konfiguration)

run_limits:
  max_delegation_depth: 5          # breaks cycles structurally
  max_total_tokens: 500000         # whole-run budget, force-stop past this
  max_wall_clock_seconds: 600

per_agent:
  invoke_rate_limit: 60/min        # one agent can't call others without bound
  timeout_seconds: 45              # stall detection on a child call
  on_breach: halt_and_alert        # stop the run, page a human

Der entscheidende Umdenkprozess besteht darin, einen Multi-Agenten-Lauf als begrenzte Transaktion mit einem Budget und einer Tiefe zu betrachten, nicht als ergebnisoffenes Gespräch. Wenn diese Grenzen am Gateway durchgesetzt werden, führt Tomás' nächtliche Schleife zu einem erreichten Limit und einer Warnung um 2 Uhr morgens, anstatt zu einer fünfstelligen Rechnung um 9 Uhr morgens.

5. Observability: End-to-End-Tracing eines Multi-Agenten-Laufs

Metriken pro Anfrage – Latenz, Token, Fehler bei jedem einzelnen Aufruf – sind für Multi-Agenten-Systeme notwendig, aber nicht ausreichend, da sie das verlieren, was Sie am meisten brauchen: die Struktur des Laufs. Wenn drei Delegationsebenen tief etwas schiefgeht, benötigen Sie den gesamten Baum – welcher Agent hat wen in welcher Reihenfolge mit welchen Ein- und Ausgaben aufgerufen und wo sind die Kosten entstanden? Das ist ein End-to-End-Trace, der Agentenschritte, Modellaufrufe und Tool-Aufrufe umfasst und durch die Lauf-ID zusammengehalten wird, die jeder Hop mit sich führt.

Dies baut direkt auf dem Tracing aus unserem OpenTelemetry-Beitragauf: dasselbe Span-Modell, wobei der Agent als erstklassige Dimension und der Lauf als Trace fungiert, der die Spans miteinander verbindet. TrueFoundry's Agent Gateway erfasst diese End-to-End-Ausführungstraces und ermöglicht es Ihnen, die Protokolle pro Schritt zu untersuchen, um Fehler zu diagnostizieren – und macht aus „die Agenten haben letzte Nacht zu viel verbraucht“ ein „diese Verbindung hat in der vierten Ebene einen Kreislauf gebildet“, was den Unterschied zwischen einem Rätsel und einer Lösung ausmacht.

6. Kostenzuordnung nach Agentenidentität

Kosten in einem Multi-Agenten-System sind ohne Identität bedeutungslos. Die Aussage „Der Workflow kostet X“ verrät nicht, ob die Ausgaben durch Planungsaufrufe des Orchestrators, die teure Modellwahl eines einzelnen Sub-Agenten oder eine Endlosschleife entstehen. Erst die Zuordnung von Token und Kosten zu einem spezifischen Agenten, Workflow und Lauf – basierend auf der Identität aus Abschnitt 2 – macht Ausgaben nachvollziehbar und Fehlentwicklungen diagnostizierbar.

Dies ist der Beitrag zur Kostenzuordnung, der die teambasierte Abrechnung auf den Agenten als Einheit erweitert. Das Agent Gateway ordnet Token-Verbrauch und Kosten spezifischen Agenten, Workflows, Teams und Umgebungen zu. Das erfüllt einen doppelten Zweck: Es beantwortet die Finanzfrage (welcher Agent verursacht die Kosten) und deckt betriebliche Anomalien auf (ein sprunghafter Kostenanstieg bei einem einzelnen Agenten ist oft das erste sichtbare Anzeichen für eine Endlosschleife, lange bevor die monatliche Abrechnung eintrifft). In Kombination mit dem Budget pro Lauf aus Abschnitt 4 werden Kosten damit sowohl beobachtbar als auch begrenzbar.

7. Sicherheit: Wie sich Prompt-Injection zwischen Agenten verbreitet

Multi-Agenten-Systeme eröffnen Prompt-Injection neue Wege. Wie in unserem Beitrag zu Prompt-Injectionbeschrieben, kann ein Agent, der nicht vertrauenswürdige Inhalte liest – etwa ein abgerufene Dokument oder ein Tool-Ergebnis –, durch darin versteckte Anweisungen manipuliert werden. In einem Multi-Agenten-System kommuniziert dieser kompromittierte Agent dann mit anderen Agenten, und sein Output wird zu deren Input. Eine Injection, die den Recherche-Agenten erreicht, kann sich auf die nachgelagerten Schreib- und Prüf-Agenten ausbreiten, da diese den Recherche-Agenten als vertrauenswürdigen Partner und nicht als unsichere Quelle betrachten.

‍