Beveiliging van A2A- en MCP-agents: identiteit, afgevaardiging en audittrails

Protocolbeveiliging bepaalt wie mag handelen, niet het model.

Inhoud

Promptinjectie krijgt de meeste aandacht op het gebied van beveiliging in LLM-systemen, en dat is terecht, maar het is niet het enige probleem zodra agents tools gaan aanroepen en werk delegeren aan andere agents.

MCP geeft een agent gestructureerde toegang tot bestanden, APIs, databases en ticketingsystemen. A2A stelt een agent in staat taken, berichten en artefacten te verzenden naar een andere agent die mogelijk behoort tot een ander team, leverancier of runtime. Deze protocollen zijn nuttig juist omdat ze vertrouwensgrenzen overschrijden, wat betekent dat identiteit, autorisatie, delegatiebeperkingen en audittrails eerste-class architectuurcomponenten worden in plaats van optionele hardening.

A2A en MCP agent beveiligingsarchitectuur met identiteits-, gateway- en audittlaag

Dit artikel is de canonieke gids voor agentprotocolbeveiliging in de LLM-architectuur-cluster. Het behandelt threat models, identiteit, gateways, registers, delegatie en productiechecklists. Voor validatie van invoer, filtering van uitvoer en patronen voor promptveiligheid, zie LLM Guardrails in de praktijk in plaats daarvan.

Guardrails vs. Protocolbeveiliging vs. Runtimebeleid

Deze drie lagen lossen verschillende problemen op en falen op verschillende manieren wanneer ze met elkaar worden verward.

LLM-guardrails werken op modelinvoer en -uitvoer: ze blokkeren injectiepatronen, filteren schadelijke inhoud, valideren JSON-vormen en handhaven regels voor toon of naleving van gegenereerde tekst. Ze beschermen het conversatielaag.

Protocolbeveiliging werkt op agentgrenzen: welke MCP-tool mag worden aangeroepen, welke agent mag welke peer delegeren, welke OAuth-scopes aan een taak zijn gekoppeld en of een downstream-agent namens een gebruiker mag handelen. Het beschermt het actielayer.

Runtimebeleid zit ertussen: een beleidengine die verzoeken evalueert tegen regels, ongeacht of de trigger natuurlijke taal was of een gestructureerd protocolverzoek. Het kan menselijke goedkeuring vereisen voordat een tool wordt uitgevoerd, egress naar onbekende domeinen blokkeren of delegatie weigeren wanneer de scope de oorspronkelijke gebruiker overschrijdt.

Mijn mening is blunt: guardrails zonder protocolbeveiliging produceren beleefde chatbots die toch data exfiltreren via een toolaanroep. Protocolbeveiliging zonder guardrails produceert goed geauthenticeerde agents die toch maliciële instructies volgen die in een artefact zijn ingebed. Je hebt beide nodig, plus runtimebeleid voor risicovolle acties.

Threat Model voor A2A- en MCP-agentsystemen

Begin met assets en adversaria, niet met een boodschappenlijstje van controls.

Assets die beschermd moeten worden: gebruikersdata in prompts en artefacten, referenties voor MCP-servers, productie-systemen die via tools bereikbaar zijn, agentreputatie, factureringsaccounts gekoppeld aan tokengebruik en auditintegriteit.

Realistische adversaria: externe gebruikers die publieke agentendpoints misbruiken, gecompromitteerde MCP-servers die vergiftigde toolresultaten teruggeven, maliciuze agents die vaardigheden misleidend presenteren in Agent Cards, insiders die overmatige autoriteit delegeren, en supply-chain manipulatie van toolmetadata die het modelgedrag manipuleert.

Maliciuze of gecompromitteerde tools (MCP)

Een MCP-server is code plus data die aan het model wordt blootgesteld. Een vijandige server kan misleidende toolbeschrijvingen teruggeven, argumenten die door het model worden doorgegeven exfiltreren, of acties uitvoeren die verder gaan dan wat de gebruiker bedoelde wanneer de host toolaanroepen uitvoert zonder scoped referenties.

Maliciuze of geïmperoneerde agents (A2A)

Een agent die taken accepteert kan kwaadaardig zijn, gecompromitteerd, of simpelweg overgeprivilegieerd. Agent Cards beschrijven capaciteiten; ze bewijzen identiteit niet tenzij je handtekeningen, TLS en issuer-trust verifieert.

Verwarring van afgezand (Confused deputy)

Agent B heeft toestemming om toegang te krijgen tot een financiële API. Agent A, met lagere privileges, vraagt B om “deze factuur samen te vatten” terwijl het een overdrachtinstructie smokkelt in een artefact. B voert dit uit met zijn eigen referenties, tenzij delegatiescope van eind tot eind wordt afgedwongen.

Te brede permissies en verborgen delegatieketens

Gebruiker keurt één stap goed. De orchestrator ketent stilzwijgend drie A2A-hops en vijf MCP-aanroepen. De gebruiker ziet nooit de volledige grafiek, maar de organisatie is nog steeds verantwoordelijk voor het resultaat.

Promptinjectie via artefacten en cross-agent berichten

Injectie is niet alleen een probleem van gebruikersberichten. Een PDF-artefact, een webpagina die door een tool wordt opgehaald, of een bericht van Agent C kan instructies bevatten die gericht zijn op het model van Agent D. Behandel alle via protocol gedragen inhoud als onbetrouwbare invoer aan de modelgrens.

Vergiftigde of misleidende Agent Cards

Beschrijvingen en vaardigheidsnamen zijn promptoppervlak. Een card die safe_read_only_analysis adverteert terwijl het write-capable backends accepteert, is een sociale-engineerlaag, geen technische garantie.

Identiteitsmodel voor Multi-Agent Systemen

Protocolbeveiliging begint met duidelijke identiteitstypes en wat elk ervan mag bewijzen.

Identiteitstype Wat het vertegenwoordigt Typisch bewijs
Menselijke gebruiker Eindgebruiker of operator die het werk initieerde OIDC-sessie, SSO-token
Agentdienst Gedeplaatste agentruntime (orchestrator, specialist) OAuth client credentials, mTLS-certificaat
MCP-server Toolproviderproces API-sleutel, mTLS, scoped service account
Taak / sessie Eenheid van werk die hops overspant Taak-ID, trace-ID, gedelegeerd scope-token

De Agent Card van A2A adverteert ondersteunde authenticatieschema’s (OAuth 2.0, API-sleutels, mTLS en vergelijkbare patronen afgestemd op OpenAPI-praktijk) en vaardigheden met optionele beveiligingsvereisten. De card is discoverymetadata, geen trust anchor. Clients verkrijgen referenties out of band en sturen ze in standaard HTTP-headers bij elk verzoek; servers moeten bij elke call valideren en 401 of 403 teruggeven wanneer auth of scope faalt.

Interne vs. externe weergaven van dezelfde agent

Productieagents publiceren vaak een publieke Agent Card met een beperkte vaardigheidslijst en een rijkere geauthenticeerde card voor interne callers. De A2A-specificatie staat uitgebreide cards toe voor geauthenticeerde clients. Gebruik die splitsing bewust: partners mogen interne vaardigheden niet zien, en interne orchestrators mogen niet alleen vertrouwen op publieke discovery voor autorisatie.

Authenticatie en Autorisatie voor MCP en A2A

Authenticatie beantwoordt de vraag wie belt. Autorisatie beantwoordt de vraag wat ze mogen doen.

MCP-toegang tot tools

Definieer voor elke MCP-verbinding:

  • welke agenthost verbinding mag maken
  • welke tools voor die host zijn ingeschakeld
  • welke OS-gebruiker of service account side effects uitvoert
  • of de menselijke gebruiker elke muterende call moet goedkeuren

Voorkeur voor tool-allowlists boven “connect everything” MCP-configs. Een coding agent heeft geen payroll MCP-servers nodig op hetzelfde profiel als een publieke supportbot.

A2A-agenttoegang

Definieer voor elke agentpeer-relatie:

  • welke caller agent-IDs welke vaardigheden mogen aanroepen
  • maximale delegatiediepte
  • welke artifacttypes de grens mogen overschrijden
  • of gebruikerscontext moet worden doorgegeven als signed claims

Map OAuth-scopes (of equivalent) naar vaardigheden, niet naar blanket agent-admin. Least privilege op het tokenlaag wint van hoop op het promptlaag.

Gateway-afgedwongen vs. per-agent beleid

Per-agent beleid werkt wanneer één team het hele grafiek eigenaarschap heeft en releases gecoördineerd zijn. Gateway-afgedwongen beleid werkt wanneer meerdere teams, tenants of leveranciers een agentnetwerk delen en je één plek nodig hebt om allowlists, rate limits en audit af te dwingen.

flowchart LR U[Gebruiker / client] --> G[A2A gateway] G --> O[Orchestrator agent] O -->|A2A scoped token| S1[Specialist agent] O -->|A2A scoped token| S2[Specialist agent] S1 --> MG[MCP gateway] S2 --> MG MG --> T1[MCP tool servers] MG --> T2[MCP tool servers] G --> A[Audit log] MG --> A S1 --> A S2 --> A

A2A Gateway als Control Plane

Een A2A gateway is niet strikt vereist door het protocol, maar wordt noodzakelijk wanneer agentverkeer gecentraliseerde governance nodig heeft.

Een gateway behandelt typisch:

  • authenticateterminatie en tokenruil
  • routing naar de juiste agentdienst op basis van vaardigheid of tenant
  • beleidchecks voordat taken worden geaccepteerd of doorgestuurd
  • protocolversieonderhandeling
  • rate limiting en misbruikdetectie
  • gestructureerde audit-emissie bij elke taakovergang

Wanneer een gateway overkill is versus noodzakelijk

Een gateway is vaak overkill voor één orchestrator en twee specialist agents in één Kubernetes-namespace die door één team wordt onderhouden. Het wordt noodzakelijk wanneer partners je agents aanroepen, wanneer meerdere eenheden infrastructuur delen, wanneer compliance uniforme logging vereist, of wanneer je niet elke agentimplementatie kunt vertrouwen om beleid correct af te dwingen.

Combineer een A2A gateway met een MCP gateway (of MCP-proxy) zodat tooltoegang dezelfde behandeling krijgt: identiteit, allowlists, egress-controls en audit aan de toolgrens in plaats van alleen op de chat-UI.

Partner-facing vs. interne Agent Cards

Publiceer verschillende discoverymetadata voor externe en interne callers. Externe cards tonen smalle vaardigheden en striktere auth. Interne cards kunnen onderhouds- of adminvaardigheden opsommen, maar mogen nooit bereikbaar zijn zonder sterkere authenticatie dan de publieke card impliceert.

Agentregister en Discoverybeveiliging

Discovery is onderdeel van de attack surface. Iedereen die beheert welke agents “beschikbaar” lijken, beheert waar orchestrators werk naartoe sturen.

Register vs. well-known Agent Card URLs

Kleine deployments gebruiken well-known URLs per agent (/.well-known/agent-card.json). Enterprise deployments voegen een register toe dat agent-IDs, versies, endpoints, eigenaars en beleidtags indexeert. Het register is een beleidobject: entries moeten vastleggen welke tenants welke agents mogen ontdekken, niet alleen waar ze wonen.

Versionering, deprecatie en eigenaarschap

Registerrecords hebben eigenaars, veranderingsgeschiedenis en deprecatiedatums nodig. Een orchestrator die Agent Cards cacheert, moet vernieuwen op TTL en handtekeningen verifiëren waar ondersteund. Verouderde cards zijn hoe gepensioneerde vaardigheden verkeer blijven ontvangen lang nadat een kwetsbaarheid is gepatcht.

Enterprise interne netwerken vs. externe partners

Interne agentmeshes kunnen vertrouwen op mTLS en private DNS. Partneragents hebben expliciete federatieregels nodig, contractueel gescopte vaardigheden en sterkere artefactinspectie omdat je hun runtime niet beheert.

Delegatie over Agentgrenzen

Delegatie is waar A2A-beveiliging wordt gewonnen of verloren. Wanneer Agent A een taak naar Agent B stuurt, moeten drie vragen scherpe antwoorden hebben:

  1. Wiens autoriteit wordt uitgeoefend? Die van de gebruiker, die van A’s service account, of een samengesteld gedelegeerd token?
  2. Wat mag B doen met die autoriteit? Alleen-lezen-analyse, of muterende tools namens A?
  3. Wie is verantwoordelijk als B de scope overschrijdt? A, B, de gatewaybeleid, of de mens die een onduidelijke prompt goedkeurde?

Doorgeven van gebruikersintentie vs. overmatige delegatie

Geef signed delegation claims door die gebruikers-ID, oorspronkelijke taak-ID, toegestane vaardigheden, vervaldatum en maximale hop-telling bevatten. Downstream agents moeten taken weigeren die scope stilzwijgend uitbreiden. Als B hogere privileges nodig heeft dan A had, ga over naar input_required en verkrijg expliciete menselijke goedkeuring in plaats van tokens onzichtbaar op te waarderen.

Human-in-the-loop goedkeuringsstromen voor risicovolle delegatie worden behandeld in A2A Streaming en Async Taken voor Lange Agent Workflow waar input_required een eerste-class taakstatus is in plaats van een fout.

sequenceDiagram participant User participant Orch as Orchestrator agent participant GW as A2A gateway participant Spec as Specialist agent participant MCP as MCP tool server User->>Orch: Verzoek met gebruikers-token Orch->>GW: Delegeer taak (scoped delegation token) GW->>GW: Beleidcheck scope + hop-telling GW->>Spec: Doorstuur taak (reduced scope token) Spec->>MCP: Toolaanroep (tool-scoped credential) MCP->>MCP: Dwang allowlist + gebruikerscontext af Spec-->>GW: Artefact + audit events GW-->>Orch: Taakupdate Orch-->>User: Eindantwoord

Splits redeneren van uitvoeringspermissies

Een agent kan brede lees-toegang nodig hebben om te plannen terwijl schrijf-tools achter goedkeuring zitten. Splits referenties of gebruik afzonderlijke MCP-profielen voor plannen versus uitvoeren zodat een modelfout niet onmiddellijk productie kan muteren.

Audittrails en Antwoordprovenance

Als je een delegatieketen niet kunt reconstrueren, kun je een incident niet verklaren, een audit niet passeren of een factureringsanomalie niet betwisten.

Log op drie lagen:

Gateway: authenticatieresultaat, beleidbeslissing, gerouteerde agent-ID, taak-ID, parent taak-ID, rate-limit events.

Agent: taakstatusovergangen, verzonden/ontvangen berichten, model/tool-aanroepen (argumenten geredacteerd indien nodig), gecreëerde artefacten, uitgaande delegatie.

MCP-server: toolnaam, caller agent-ID, gebruikerscontext, succes/falen, latentie, beïnvloede rijen of resource-IDs (beleid toelatend).

Correleer met trace-ID over alle lagen. Observability voor LLM-systemen behandelt instrumentatiebackends; dit artikel definieert wat moet worden vastgelegd zodat die backends betekenisvolle signalen hebben.

Eindantwoordprovenance moet beantwoorden: welke gebruiker, welke orchestrator taak, welke specialist agents, welke tools, welke artefacten het tekst beïnvloedden die de gebruiker zag, en welke poortbeleid langs de weg afviren.

Runtimebeleid, Egress en Secrets

Runtimebeleidengines (OPA, Cedar, custom rule services) evalueren gestructureerde events: “tool X met args Y voor gebruiker Z.” Ze vullen guardrails aan omdat ze niet afhankelijk zijn van goed modelgedrag.

Menselijke goedkeuring hoort bij runtimebeleid voor onherroepelijke of kostbare acties: betalingen, externe e-mail, productieconfiguratieveranderingen, privilege-toewijzingen.

Egress-controls beperken welke domeinen MCP-servers en agents mogen aanroepen. Een agent die zowel secrets kan lezen als POST naar willekeurige URLs is een dataverlies in de maak.

Secrets horen nooit in Agent Cards of prompts. MCP-hosts moeten short-lived credentials injecteren op uitvoeringstijd vanuit een secrets manager. Voor transportencryptie, sleutelbeheer en baseline infrastructuurbeveiligingspatronen, zie Architecturale Patronen voor Data Beveiliging.

Pushberichtenwebhooks in asynchrone A2A-stromen hebben dezelfde rigor nodig: verifieer zenderidentiteit, verwerp verouderde events en behandel een webhookpayload nooit als autorisatie op zichzelf.

Referentie Beveiligingsarchitectuur

Het volgende diagram vat een productie-georiënteerde layout samen voor A2A buiten, MCP binnen-deployments op schaal.

flowchart TB subgraph Client layer U[Gebruiker / API client] end subgraph Control plane GW[A2A gateway] REG[Agent register] POL[Beleid engine] AUD[Audit log] SEC[Secrets manager] end subgraph Agent layer OR[Orchestrator] SA[Specialist agents] end subgraph Tool layer MG[MCP gateway] MCP[MCP servers] end subgraph Observability OBS[Tracing + metrics] end U --> GW GW --> REG GW --> POL GW --> OR OR --> GW GW --> SA SA --> MG MG --> MCP POL --> GW POL --> MG SEC --> SA SEC --> MCP GW --> AUD MG --> AUD SA --> AUD AUD --> OBS

De orchestrator ziet specialist agents via A2A. Specialisten zien tools via MCP. Gebruikers ontvangen nooit ruwe MCP-referenties, en partners ontvangen nooit interne vaardigheidsoppervlakten zonder beleidreview.

Voor concepten (Agent Cards, taken, artefacten), zie Wat is het A2A Protocol?. Voor adoptie en enterprise framing, zie Google A2A Protocol in 2026. Voor topologie wanneer veel agents coördineren, zie Multi-Agent Orchestratie Patronen.

Productie Checklist voor A2A en MCP Beveiliging

Voordat je agentprotocollen blootstelt buiten een vertrouwde sandbox, verifieer:

Identiteit en auth

  • Geen anonieme agents in productiepaden
  • Elke MCP- en A2A-call geauthenticeerd bij elk verzoek
  • OAuth-scopes of equivalent gemapped naar vaardigheden/tools, niet blanket admin
  • Publieke vs. geauthenticeerde Agent Card-weergaven bewust gedefinieerd

Delegatie en beleid

  • Delegatietokens bevatten gebruikers-ID, taak-ID, scope, vervaldatum, hop-limiet
  • Downstream agents weigeren scope-uitbreiding zonder expliciete goedkeuring
  • Risicovolle tools vereisen runtimebeleid of menselijke goedkeuring
  • Redeneren en uitvoeren gebruiken afzonderlijke referenties waar mogelijk

Discovery en register

  • Agentregisterentries hebben eigenaars en versiegeschiedenis
  • Agent Cards vernieuwd op TTL; handtekeningen geverifieerd waar ondersteund
  • Partneragents gefedereerd met expliciete vaardigheidsallowlists

Audit en observability

  • Gateway, agent en MCP-lagen emitteren gecorréleerde audit events
  • Delegatieketens gelogd met parent en child taak-IDs
  • Artefactprovenance vastgelegd voor eindantwoorden
  • Trace-IDs verbonden met observability backends

Misbruik en resiliëntie

  • Rate limits per gebruiker, agent en tenant
  • Timeoutbeleid op gedelegeerde taken
  • Egress allowlists op tool servers
  • Secrets in een manager, niet in cards, prompts of repos

Conclusie

A2A- en MCP-interoperabiliteit is krachtig omdat agents en tools kunnen combineren over team- en leveranciargrenzen, maar die kracht is onveilig zonder identiteit, autorisatie, delegatiebeperkingen en auditontwerp. Guardrails beschermen de modelconversatie; protocolbeveiliging beschermt de acties die agents namens gebruikers uitvoeren.

Behandel Agent Cards als advertenties, delegatie als een ondertekend contract, MCP-tools als geprivilegieerde code-uitvoering, en auditlogs als de bewijsketen die je nodig hebt wanneer er iets interessants gebeurt om 2 uur ’s nachts.

Bouw de gateway wanneer governance een enkele keel nodig heeft om te wurgen. Splits referenties voordat je agents splitst. Log elke hop zodat het antwoord “het model besloot” nooit het definitieve incidentrapport is.

Veelgestelde Vragen

Wat is het verschil tussen LLM-guardrails en A2A MCP-agentbeveiliging? Guardrails beperken modelinvoer en -uitvoer. Protocolbeveiliging beperkt wie tools mag aanroepen, taken delegeren en namens wie handelen via MCP en A2A met identiteit, autorisatie en audittrails.

Hoe zou agentidentiteit moeten werken in een A2A-deployment? Splits menselijke, agentdienst- en taakidentiteiten. Valideer referenties bij elk verzoek, gebruik scoped tokens en behandel Agent Cards als discoverymetadata in plaats van bewijs van vertrouwen.

Wat is het confused deputy-probleem in multi-agent systemen? Het treedt op wanneer een geprivilegieerde agent of tool een gevoelige actie uitvoert omdat een minder geprivilegieerde caller instructies smokkelt via delegatie of artefacten. Dwang scope af bij elke hop.

Heb je een A2A gateway nodig in productie? Single-team interne deployments kunnen beleid per agent afdwingen. Multi-tenant, multi-leverancier of partner-facing netwerken hebben meestal een gateway nodig voor gecentraliseerde auth, routing, rate limits en audit.

Wat moet een A2A MCP audit log bevatten? Gebruikers-ID, agent-ID, taak-ID, parent taak-ID, toolaanroepen, beleidbeslissingen, artefacten en tijdstippen gecorréleerd met trace-IDs over gateway-, agent- en MCP-lagen.

Bronnen

Abonneren

Ontvang nieuwe berichten over systemen, infrastructuur en AI-engineering.