Multi-agent-systemen beheren: Agent-identiteit, A2A en de Agent Gateway

Single-agent-systemen roepen modellen en tools aan. Multi-agent-systemen voegen iets nieuws toe: agents die agents aanroepen. Dat oost-westverkeer — een orchestrator die delegeert aan sub-agents, agents die werk aan elkaar overdragen via het nog jonge Agent2Agent-protocol — is waar kosten uit de hand lopen, de blast radius groter wordt en de vraag "welke agent wat deed" onbeantwoord blijft. De protocollen standaardiseren hoe agents elkaar ontdekken en werk uitwisselen, en ze bieden beveiligingshaken — maar ze schrijven niet uw enterprise-identiteitsmodel, policy graph, budgetmodel of observability- en control plane voor. Deze post behandelt die governance-laag en legt uit waarom deze bij de gateway thuishoort.

Tomás, een platform engineer, werd geconfronteerd met een kostenwaarschuwing en een raadsel. Van de ene op de andere dag had de nieuwe multi-agent-research-workflow van het bedrijf meer uitgegeven dan in de hele vorige maand. Een orchestrator-agent delegeerde subtaken aan een reeks sub-agents; één sub-agent stuitte op een tijdelijke fout en probeerde het opnieuw door de orchestrator opnieuw aan te roepen, die vervolgens weer delegeerde — een lus die urenlang doorging. Tegen de ochtend hadden de agents elkaar tientallen duizenden keren aangeroepen. Tomás wilde weten welke agent het was gestart en waar de cyclus ontstond, maar kwam erachter dat hij dat niet kon zien: elke agent authenticeerde met dezelfde gedeelde service-sleutel, de calls tussen agents werden niet als een grafiek vastgelegd en er was geen rate limit per agent die zou zijn geactiveerd. Het systeem had governance voor calls naar de model provider. Het had vrijwel niets voor calls tussen de eigen agents.

Dit is de kloof die multi-agent-systemen doen ontstaan. Het moment dat agents aan elkaar beginnen te delegeren, hebt u een nieuw intern netwerk — een netwerk zonder identiteit, zonder policy en standaard zonder trace. De agent-frameworks helpen u bij het bouwen van de workflow; ze beheren deze niet. Deze post legt uit hoe u dat interne netwerk dezelfde identiteit, limieten en observability geeft waar u een microservice mesh nooit zonder zou laten draaien.

1. Het nieuwe verkeerspatroon: Agents die agents aanroepen

Gedurende het grootste deel van het gateway-verhaal tot nu toe was het verkeer noord-zuid: een applicatie roept een model aan, eventueel via een tool. Multi-agent-systemen voegen oost-westverkeer toe — agents die andere agents aanroepen. Een orchestrator delegeert aan specialisten; een specialist raadpleegt een andere; resultaten stromen terug omhoog. Het nog jonge Agent2Agent (A2A)-protocol geeft dit een standaardvorm, waarbij agents functionaliteitsbeschrijvingen (agent cards) publiceren die anderen ontdekken, en taken en berichten uitwisselen via een gemeenschappelijke interface, net zoals MCP de manier waarop agents tools bereiken heeft gestandaardiseerd.

De vergelijking die u in gedachten moet houden, is de overstap van een monoliet naar microservices. Het moment dat uw agents met elkaar praten, hebt u een gedistribueerd systeem met de failure modes van dien: cascading retries, cycli, fan-out-amplificatie en het verlies van één duidelijke call-stack. En net als bij microservices is de oplossing niet om te hopen dat de calls verdwijnen, maar om ze achter een laag te plaatsen die elke aanroeper een identiteit geeft, elke call een policy en elke stroom een trace. Die laag is voor agents de agent gateway.

2. Agent-identiteit: Waarom een gedeelde service-sleutel niet volstaat

Het kernprobleem van Tomás was identiteit. Wanneer elke agent authenticeert met één gedeelde service-sleutel, kan het systeem zijn agents letterlijk niet van elkaar onderscheiden — wat betekent dat het ze niet verschillend kan autoriseren, kosten niet afzonderlijk kan toewijzen en niet kan reconstrueren welke agent heeft gehandeld.

De oplossing is om elke agent een eigen identiteit te geven, uitgegeven en geverifieerd bij de gateway, en deze door te geven bij elke call die de agent maakt — naar een model, naar een tool en naar een andere agent. Die identiteit is waar elke latere controle aan hangt: autorisatiebeslissingen, rate limits, kostentoewijzing en trace-toewijzing zijn allemaal gebaseerd op "welke agent".

Elke agent draagt zijn eigen identiteit bij elke hop (ter illustratie)

Het centraliseren van identiteit bij TrueFoundry's Agent Gateway — die authenticatie, identiteit en service-accountbeheer voor agents op de gateway-laag beheert — betekent dat de identiteit één keer wordt vastgesteld en overal stroomafwaarts wordt vertrouwd, in plaats van dat elk agent-framework zijn eigen schema bedenkt. Het behouden van de menselijke principal (namens wie de workflow draait) naast de agent-identiteit zorgt ervoor dat autorisatie van de eindgebruiker en audit intact blijven, zelfs drie delegaties diep.

3. A2A-autorisatie en policy: Welke agent welke mag aanroepen

Identiteit maakt autorisatie mogelijk, en de vragen zijn concreet in een multi-agent-systeem. Mag de research-agent de writer-agent aanroepen, of alleen de orchestrator? Mag een sub-agent rechtstreeks externe tools aanroepen, of alleen via zijn parent? Welke agents mogen ten laste van welk budget uitgaven doen? Door deze uit te drukken als policy-as-code — dezelfde Cedar- of OPA-benadering uit de posts over governance en routing — worden de toegestane verbindingen van de agent-grafiek expliciet en controleerbaar in plaats van impliciet in de code.

Autorisatie per agent voor oost-west-calls (voorbeeld-policy)

Let op de tweede regel: een policy die sub-agents verbiedt de orchestrator opnieuw aan te roepen, zou de lus van Tomás bij de eerste hop hebben onderbroken, onafhankelijk van enige rate limit. Autorisatie is hier niet alleen een beveiligingscontrole; het beperken van de vorm van de agent-grafiek is ook de manier waarop u hele categorieën van ontspoord gedrag voorkomt. De gateway wordt het handhavingspunt wanneer dit de enige plek is waar elk oost-westverkeer doorheen wordt geleid.

Het helpt om precies te zijn over wat de protocollen bepalen en wat ze aan u overlaten. Discovery en transport zijn gestandaardiseerd; het identiteitsmodel, de policy, budgetten en het handhavingspunt zijn dat niet:

4. De blast radius beperken: Lussen, ontspoorde fan-out en rate limits

Zelfs met een goede autorisatie falen multi-agent-systemen op manieren waarop afzonderlijke calls dat niet doen, omdat de schade-eenheid de cascade is. Een retry die opnieuw delegeert kan een cyclus vormen; een agent die fanning-out toepast op vele children kan één verzoek versterken tot duizenden; een trage sub-agent kan een hele workflow doen stokken. Dit zijn de varianten op agent-schaal van de thundering-herd- en silent-escalation-problemen die bekend zijn uit routing en failover op de model-laag.

Inperking is gelaagd. Een delegatiedieptelimiet beperkt hoe diep de keten kan recurseren, wat cycli structureel doorbreekt. Rate limits per agent beperken hoe vaak een specifieke agent andere kan aanroepen, zodat een lus een plafond bereikt in plaats van de hele nacht door te draaien. Timeouts en stall-detection voorkomen dat een agent eindeloos op een child wacht. En een globaal budget per run maximeert de totale uitgaven van één workflow, ongeacht de structuur ervan. TrueFoundry's Agent Gateway documenteert de relevante primitives — retry-policies, fallback-paden, timeouts en beveiligingen tegen oneindige lussen of vastgelopen agents, plus token- en kostengerelateerde quota per agent, workflow of omgeving. De exacte configuratievorm hieronder is ter illustratie; de primitives zijn wat de productpagina beschrijft.

Blast-radius-bedieningselementen voor een multi-agent-run (voorbeeld van gateway-configuratie)

De verandering in denkprikkel is om een multi-agent-run te behandelen als een begrensde transactie met een budget en een diepte, niet als een gesprek met een open einde. Met die grenzen gehandhaafd bij de gateway verandert de nachtelijke lus van Tomás in een overschreden limiet en een melding om 02:00 uur in plaats van een factuur van vijf cijfers om 09:00 uur.

5. Observability: Een multi-agent-run end-to-end traceten

Metrieken per verzoek — latency, tokens, fouten op elke individuele call — zijn noodzakelijk maar niet voldoende voor multi-agent-systemen, omdat ze hetgeen verliezen dat u het meest nodig hebt: de structuur van de run. Wanneer er drie delegaties diep iets misgaat, hebt u de hele boom nodig — welke agent welke aanriep, in welke volgorde, met welke invoer en uitvoer, en waar de kosten stegen. Dat is een end-to-end trace die agentstappen, model-calls en tool-invocaties omvat, aan elkaar gekoppeld door de run-identifier die elke hop met zich meedraagt.

Dit bouwt rechtstreeks voort op de tracing uit onze OpenTelemetry-post: hetzelfde span-model, met de agent als primaire dimensie en de run als de trace die spans samenbindt. TrueFoundry's Agent Gateway legt deze end-to-end uitvoerings-traces vast en stelt u in staat logs per stap te inspecteren om fouten te diagnosticeren — waardoor "de agents hebben afgelopen nacht te veel uitgegeven" verandert in "deze verbinding vormde een cyclus op diepte vier," wat het verschil is tussen een raadsel en een oplossing.

6. Kostentoewijzing op basis van agent-identiteit

Kosten in een multi-agent-systeem zijn betekenisloos zonder identiteit. "De workflow kostte X" vertelt u niet of de uitgaven komen door de plannings-calls van de orchestrator, de duurste modelkeuze van één sub-agent of een lus. Het toewijzen van tokens en kosten aan de specifieke agent, workflow en run — gekoppeld aan de identiteit uit sectie 2 — maakt de uitgaven inzichtelijk en het ontsporen diagnosticeerbaar.

Dit is de administratie per team uit de kostentoewijzings-post, uitgebreid met de agent als eenheid. De Agent Gateway wijst tokengebruik en kosten toe aan specifieke agents, workflows, teams en omgevingen, wat een dubbele functie heeft: het beantwoordt de financiële vraag (welke agent veroorzaakt de kosten) en het brengt de operationele anomalie aan het licht (een kostenspiek bij één agent is vaak het eerste zichtbare teken van een lus, lang voor de maandelijkse factuur). Combineer het met het budget per run uit sectie 4 en kosten worden zowel observeerbaar als begrensd.

7. Beveiliging: Hoe prompt-injectie zich verspreidt over agents

Multi-agent-systemen geven prompt-injectie een nieuwe manier om zich te verplaatsen. Zoals behandeld in onze prompt-injectie-post, kan een agent die niet-vertrouwde inhoud leest — een opgehaald document, een toolresultaat — worden gestuurd door daarin verborgen instructies. In een multi-agent-systeem praat die gecompromitteerde agent vervolgens met andere agents, en wordt zijn uitvoer hun invoer. Een injectie die binnenkomt bij de research-agent kan zich verspreiden naar de writer- en critic-agents stroomafwaarts, omdat de research-agent voor hen een vertrouwde peer is, geen onbetrouwbare bron.

Dit is waarom verdediging tegen injectie een agent-naar-agent-aangelegenheid is, en niet alleen voor de invoergrens, en waarom het centraliseren ervan bij de gateway van belang is: wanneer agent-naar-agent-verkeer via de gateway wordt geleid, ziet deze elk oost-west-bericht en kan de guardrails uniform toepassen, in plaats van erop te vertrouwen dat elke agent zijn peers scant.

8. De Gateway als de Agent Control Plane

Elke draad hier komt samen op één punt: een multi-agent-systeem is een gedistribueerd systeem, en zoals elk gedistribueerd systeem heeft het een control plane nodig die elke aanroeper identiteit geeft, elke call een policy, elke stroom een trace en elke run een budget. Dat inbouwen in elk agent-framework binnen end user computing-omgevingen — LangChain hier, CrewAI daar, een aangepaste orchestrator elders — garandeert inconsistentie en lacunes, precies waar de lus van Tomás doorheen glipte.

De agent gateway is die control plane. TrueFoundry's Agent Gateway draait framework-agnostische agents via één beheerde uitvoeringslaag: identiteit en RBAC per agent, token- en kostenquota per agent en workflow, retries, timeouts en lusbeveiligingen, end-to-end tracing en via MCP beheerde tool-toegang — waarmee het modelverkeer van de AI Gateway, het toolverkeer van de MCP Gateway en het agent-naar-agent-verkeer van multi-agent-systemen op één plek worden verenigd. Voor een dieper inzicht in de orchestratiepatronen zelf is TrueFoundry's multi-agent orchestratiegids een nuttige aanvulling; deze post gaat over het beheren ervan zodra ze actief zijn.

9. Veelgestelde vragen

Is A2A niet nog erg nieuw? Waarom nu al beheren?

A2A is als enterprise-adoptiepatroon nog jong — hoewel het protocol nu een formele v1.0-specificatie heeft — en ecosysteemconventies zullen blijven evolueren, dus beschouw de details als voorlopig. Maar de noodzaak voor governance wacht niet tot de adoptie is gestabiliseerd: het moment dat uw agents aan elkaar delegeren, via welk mechanisme dan ook, hebt u oost-westverkeer zonder identiteit of limieten. De controles hier — identiteit per agent, autorisatie, blast-radius-limieten, tracing — zijn van toepassing of agents nu praten via A2A, de systeemeigen delegatie van een framework of eenvoudige HTTP.

Hoe verschilt dit van de post over de beheerde agent-laag?

Die post pleitte voor het scheiden van agent-logica en runtime — waar agent-code draait en hoe deze wordt ingezet. Deze post gaat over het beheren van de communicatie tussen agents zodra ze actief zijn: identiteit bij elke hop, wie wie mag aanroepen, het inperken van cascades en het traceten van de run. Gerelateerde lagen, verschillende problemen — runtime-scheiding gaat over de agent als een implementeerbare eenheid; dit gaat over de agent als netwerkdeelnemer.

Welke enkele controle zou het probleem in het begin hebben voorkomen?

Twee controles, samenwerkend. Een autorisatieregels die sub-agents verbiedt de orchestrator opnieuw aan te roepen, zou de lus structureel bij de eerste hop hebben onderbroken; een delegatiedieptelimiet en een rate limit per agent zouden elke cyclus hebben opgevangen die door het beleid glipte. Geen van beide vereist begrip van de bedoeling van de workflow — ze begrenzen de vorm ervan — en daarom horen ze thuis bij de gateway in plaats van in de logica van elke agent afzonderlijk.

Hebben agents echt elk hun eigen identiteit nodig?

Voor alles wat u per agent wilt autoriseren, toewijzen of auditen — ja. Een gedeelde sleutel voegt elke agent samen tot één principal, wat de reden is dat Tomás niet kon zien welke agent de lus begon of wat elke agent kostte. Identiteit per agent, waarbij de menselijke principal daarnaast behouden blijft, is het fundament waarvan elke andere controle in deze post afhankelijk is.

Gateway of framework voor multi-agent-governance?

Het framework bouwt de workflow; de gateway beheert deze. Identiteit, autorisatie, rate- en dieptelimieten, tracing en kostentoewijzing zijn overkoepelende belangen die consistent moeten zijn voor elke agent en elk framework dat u gebruikt. Dat is precies wat één control plane biedt en wat een implementatie per framework niet kan garanderen.

Het incident van Tomás was geen lumineuze fout; het was een onbeheerd intern netwerk dat deed wat onbeheerde netwerken doen. Multi-agent-systemen zijn krachtig omdat agents vrijelijk kunnen delegeren — en diezelfde vrijheid is de reden waarom ze identiteit, limieten en een trace op elke verbinding nodig hebben. Plaats die control plane voor het agent-verkeer, en delegatie blijft een functionaliteit in plaats van te veranderen in een nachtelijk incident.

Referenties

• TrueFoundry — Agent Gateway (agent-identiteit, quota, tracing, lusbeveiligingen)
• TrueFoundry — What is multi-agent orchestration?
• Agent2Agent (A2A) protocol — agent cards en agent-naar-agent-berichtuitwisseling
• Onze Agent Gateway-, Prompt Injection-, Cost Attribution- en OpenTelemetry for LLMs-posts.

Northwind en Tomás zijn ter illustratie. Een verduidelijking die expliciet gemaakt moet worden: Agent2Agent (A2A) is een open communicatieprotocol, terwijl TrueFoundry Agent Gateway de product- en control plane-implementatie van TrueFoundry is voor het beheren van agent-workflows — het zijn verschillende dingen, en deze post gebruikt A2A als de standaardterminologie voor het verkeer dat de gateway beheert. De functionaliteiten van de TrueFoundry Agent Gateway zijn samengevat uit openbare productdocumentatie van juni 2026 en zullen evolueren; sommige functies zijn mogelijk in preview. A2A is nieuw als enterprise-adoptiepatroon en de ecosysteemconventies zullen blijven evolueren, dus protocoldetails worden hier op hoofdlijnen beschreven en moeten worden gecontroleerd aan de hand van de huidige specificatie. Code- en policy-voorbeelden dienen ter illustratie van de gedocumenteerde patronen en zijn niet gekopieerd uit een referentie-implementatie.

‍