Säkerhet för A2A- och MCP-agenter: Identitet, delegering och granskningsloggar

Protokollsäkerhet handlar om vem som får agera, inte om modellen.

Sidinnehåll

Promptinjection får mest av säkerhetsuppmärksamheten i LLM-system, och den förtjänar uppmärksamhet, men den är inte hela problemet när agenter börjar anropa verktyg och delegera arbete till andra agenter.

MCP ger en agent strukturerad åtkomst till filer, API:er, databaser och ärendehanteringssystem. A2A låter en agent skicka uppgifter, meddelanden och artefakter till en annan agent som kan tillhöra ett annat team, leverantör eller runtime. Dessa protokoll är användbara just eftersom de korsar tillitgränser, vilket innebär att identitet, auktorisering, delegeringsgränser och revisionspår blir arkitektur av första rang snarare än valfri förstärkning.

A2A och MCP agent säkerhetsarkitektur med identitet, gateway och lager för revision

Den här artikeln är den kanoniska guiden för agentsäkerhet för protokoll i LLM-arkitektur-klustret. Den täcker hotmodeller, identitet, gateways, register, delegering och produktionskontrolllistor. För indatavalidering, utdatafiltrering och mönster för promptsäkerhet, se LLM-skyddsmekanismer i praktiken istället.

Skyddsmekanismer vs protokollsäkerhet vs runtime-policy

Dessa tre lager löser olika problem och misslyckas på olika sätt när de blandas ihop.

LLM-skyddsmekanismer arbetar på modellens in- och utdata: blockerar injektionsmönster, filtrerar skadligt innehåll, validerar JSON-struktur och tillämpar ton- eller efterlevadsregler på genererad text. De skyddar konversationslagret.

Protokollsäkerhet arbetar på agentgränser: vem som får anropa vilket MCP-verktyg, vilken agent som får delegera till vilken peer, vilka OAuth-omfattningar som kopplas till en uppgift och om en nedströmsagent får agera på användarens vägnar. Den skyddar actions-lagret.

Runtime-policy sitter mellan dem: en policy-motor som utvärderar begäran mot regler oavsett om utlösaren var naturligt språk eller ett strukturerat protokollanrop. Den kan kräva godkännande från människa innan ett verktyg exekverar, blockera utgående trafik till okända domäner eller neka delegering när omfattningen överstiger den ursprungliga användarens.

Min åsikt är rak: skyddsmekanismer utan protokollsäkerhet producerar artiga chattrobotar som fortfarande exfiltrerar data genom ett verktygsanrop. Protokollsäkerhet utan skyddsmekanismer producerar väl autentiserade agenter som fortfarande följer skadliga instruktioner inbäddade i en artefakt. Du behöver båda, plus runtime-policy för högriskåtgärder.

Hotmodell för A2A- och MCP-agentsystem

Börja med tillgångar och motståndare, inte med en inköpslista av kontroller.

Tillgångar värd att skydda: användardata i prompts och artefakter, inloggningsuppgifter för MCP-server, produktionsystem som nås genom verktyg, agentens rykte, faktureringskonton kopplade till tokenanvändning och revisionsintegritet.

Realistiska motståndare: externa användare som utnyttjar offentliga agentändpunkter, komprometterade MCP-server som returnerar förgiftade verktygsresultat, skadliga agenter som missrepresenterar färdigheter i Agent Cards, inredningar som överdelegerar auktoritet, och försörjningskedjemanipulation av verktygsmetadata som manipulerar modellbeteende.

Skadliga eller komprometterade verktyg (MCP)

En MCP-server är kod plus data som exponeras för modellen. En fientlig server kan returnera vilseledande verktygsbeskrivningar, exfiltrera argument som skickas av modellen eller utföra åtgärder bortom det användaren avsåg när värdexekverar verktygsanrop utan scoped inloggningsuppgifter.

Skadliga eller utgivna agenter (A2A)

En agent som accepterar uppgifter kan vara ond, komprometterad eller helt enkelt överbehörig. Agent Cards beskriver kapaciteter; de bevisar inte identitet om du inte verifierar signaturer, TLS och utgivartillit.

Förvirrad ombud (Confused deputy)

Agent B har behörighet att åtkomma en finans-API. Agent A, med lägre privilegier, ber B att “sammanfatta denna faktura” medan den smyger in en överföringsinstruktion i en artefakt. B exekverar med sina egna inloggningsuppgifter om inte delegeringsomfattningen tillämpas från ände till ände.

För breda behörigheter och dolda delegeringskedjor

Användaren godkänner ett steg. Orkestratorn kedjar tyst tre A2A-hopp och fem MCP-anrop. Användaren ser aldrig hela grafen, men organisationen är fortfarande ansvarig för utfallet.

Promptinjection genom artefakter och meddelanden mellan agenter

Injection är inte bara ett problem med användarmeddelanden. En PDF-artefakt, en webbsida hämtad av ett verktyg eller ett meddelande från Agent C kan bära instruktioner riktade mot Agent D:s modell. Behandla all protokollburen innehåll som o betrodd indata vid modellgränsen.

Förgiftade eller vilseledande Agent Cards

Beskrivningar och färdighetsnamn är prompt-yta. En card som reklamerar safe_read_only_analysis medan den accepterar skrivbara backends är ett lager för social engineering, inte en teknisk garanti.

Identitetsmodell för multi-agentsystem

Protokollsäkerhet börjar med tydliga identitetstyper och vad varje en är tillåten att bevisa.

Identitetstyp Vad den representerar Typiskt bevis
Mänsklig användare Slutanvändare eller operatör som initierade arbetet OIDC-session, SSO-token
Agentservice Deployad agent-runtime (orkestrator, specialist) OAuth client credentials, mTLS-certifikat
MCP-server Verktygsleverantörsprocess API-nyckel, mTLS, scoped service account
Uppgift / session Enhetsarbete som sträcker sig över hopp uppgifts-ID, spår-ID, delegerat scope-token

A2A:s Agent Card reklamerar stödde autentiseringsscheman (OAuth 2.0, API-nycklar, mTLS och liknande mönster i linje med OpenAPI-praxis) och färdigheter med valfria säkerhetskrav. Carden är upptäcktsmetadata, inte en tillitsankare. Klienter erhåller inloggningsuppgifter utom band och skickar dem i standard HTTP-huvuden vid varje begäran; server måste validera vid varje anrop och returnera 401 eller 403 när autentisering eller scope misslyckas.

Intern vs extern vy av samma agent

Produktionsagenter publicerar ofta en offentlig Agent Card med en begränsad färdighetslista och en rikare autentiserad card för interna anrop. A2A-specifikationen tillåter utökade cards för autentiserade klienter. Använd den uppdelningen medvetet: partners bör inte se interna färdigheter, och interna orkestratorer bör inte förlita sig på offentlig upptäckt ensam för auktorisering.

Autentisering och auktorisering för MCP och A2A

Autentisering svarar på vem som anropar. Auktorisering svarar på vad de får göra.

MCP-verktygsåtkomst

För varje MCP-anslutning, definiera:

  • vilken agentvärd får ansluta
  • vilka verktyg är aktiverade för den här värden
  • vilken OS-användare eller service account exekverar side effects
  • om den mänskliga användaren måste godkenna varje muterande anrop

Föredra verktyg-allowlists över “anslut allt” MCP-konfigurationer. En kodningsagent behöver inte löne-MCP-server på samma profil som en offentlig supportbot.

A2A-agentåtkomst

För varje agent peer-relation, definiera:

  • vilka caller agent IDs får anropa vilka färdigheter
  • maximal delegeringsdjup
  • vilka artefakttyper får korsa gränsen
  • om användarkontext måste propageras som signerade claims

Koppla OAuth-scopes (eller ekvivalent) till färdigheter, inte till blanket agent-admin. Minsta privilegium på token-lagret slår hoppet på prompt-lagret.

Gateway-tvingad vs per-agent policy

Per-agent policy fungerar när ett team äger hela grafen och releaser är koordinerade. Gateway-tvingad policy fungerar när flera team, hyresgäster eller leverantörer delar ett agentnätverk och du behöver en plats att tillämpa allowlists, hastighetsbegränsningar och revision.

flowchart LR U[Användare / klient] --> G[A2A gateway] G --> O[Orkestrator agent] O -->|A2A scoped token| S1[Specialist agent] O -->|A2A scoped token| S2[Specialist agent] S1 --> MG[MCP gateway] S2 --> MG MG --> T1[MCP verktygsserver] MG --> T2[MCP verktygsserver] G --> A[Revisionslogg] MG --> A S1 --> A S2 --> A

A2A Gateway som kontrollplan

En A2A gateway är inte strikt krävd av protokollet, men den blir nödvändig när agenttrafik behöver centraliserad styrning.

En gateway hanterar typiskt:

  • autentiseringsterminering och tokenbyte
  • ruttning till korrekt agentservice efter färdighet eller hyresgäst
  • policykontroller innan uppgifter accepteras eller vidarebefordras
  • protokollversionsförhandling
  • hastighetsbegränsning och missbruksdetektering
  • strukturerad revisionsutsläpp vid varje uppgiftsövergång

När en gateway är överkill vs nödvändig

En gateway är ofta överkill för en ensam orkestrator och två specialistagenter i ett Kubernetes-namespace underhållen av ett team. Den blir nödvändig när partners anropar dina agenter, när flera affärsenheter delar infrastruktur, när efterlevnad kräver uniform loggning, eller när du inte kan lita på varje agentimplementation att tillämpa policy korrekt.

Påpara en A2A gateway med en MCP gateway (eller MCP-proxy) så att verktygsåtkomst får samma behandling: identitet, allowlists, utgående kontroller och revision vid verktygsgränsen snarare än bara vid chatt-UI:n.

Partner-inriktade vs interna Agent Cards

Publicera olika upptäcktsmetadata för externa och interna anrop. Externa cards exponerar smala färdigheter och striktare autentisering. Interna cards kan lista underhåll eller admin-färdigheter men får aldrig vara nåbara utan starkare autentisering än den offentliga carden antyder.

Agentregister och upptäcktssäkerhet

Upptäckt är en del av angreppsytan. Den som kontrollerar vilka agenter verkar “tillgängliga” kontrollerar var orkestratorer skickar arbete.

Register vs välkända Agent Card URL:er

Små deployment använder välkända URL:er per agent (/.well-known/agent-card.json). Enterprise-deployment lägger till ett register som indexerar agent-ID:n, versioner, ändpunkter, ägare och policy-taggar. Registret är ett policy-objekt: poster bör registrera vilka hyresgäster som får upptäcka vilka agenter, inte bara var de bor.

Versionering, nedläggning och ägarskap

Registerposter behöver ägare, ändringshistorik och nedläggningsdatum. En orkestrator som cachar Agent Cards måste uppdatera på TTL och verifiera signaturer där stöd finns. Stale cards är hur pensionerade färdigheter fortsätter att ta emot trafik lång efter att en sårbarhet är patchad.

Enterprise interna nätverk vs externa partners

Interna agentmeshar kan förlita sig på mTLS och privat DNS. Partneragenter behöver explicita federationsregler, kontraktligt scoped färdigheter och starkare artefaktinspektion eftersom du inte kontrollerar deras runtime.

Delegering över agentgränser

Delegering är där A2A-säkerhet vinner eller förloras. När Agent A skickar en uppgift till Agent B, måste tre frågor ha skarpa svar:

  1. Vems auktoritet utövas? Användarens, A:s service account, eller en blandad delegerad token?
  2. Vad får B göra med den auktoriteten? Read-only analys, eller muterande verktyg på A:s vägnar?
  3. Vem är ansvarig om B överskrider scope? A, B, gateway-policy, eller människan som godkände en otydlig prompt?

Propagera användarintention vs överdelegering

Skicka signerade delegeringsclaims som inkluderar användar-ID, ursprungligt uppgifts-ID, tillåtna färdigheter, utgångsdatum och maximal hopräkning. Nedströmsagenter måste avvisa uppgifter som expanderar scope tyst. Om B behöver högre privilegium än A höll, övergå till input_required och erhåll explicit mänskligt godkännande snarare än att uppgradera tokens osynligt.

Human-in-the-loop godkännandeflöden för riskfylld delegering täcks i A2A Streaming och Async Tasks för långvariga agentarbetsflöden där input_required är ett first-class uppgiftstillstånd snarare än ett fel.

sequenceDiagram participant User participant Orch as Orkestrator agent participant GW as A2A gateway participant Spec as Specialist agent participant MCP as MCP verktygsserver User->>Orch: Begäran med användartoken Orch->>GW: Delegera uppgift (scoped delegeringstoken) GW->>GW: Policykontroll scope + hopräkning GW->>Spec: Vidarebefora uppgift (reducerad scope-token) Spec->>MCP: Verktygsanrop (verktyg-scoped inloggningsuppgift) MCP->>MCP: Tillämpa allowlist + användarkontext Spec-->>GW: Artefakt + revisionshändelser GW-->>Orch: Uppgiftsuppdatering Orch-->>User: Slutlig respons

Separera resonemang från exekveringsbehörigheter

En agent kan behöva bred läsåtkomst för att planera medan skrivverktyg sitter bakom godkännande. Dela inloggningsuppgifter eller använd distinkta MCP-profiler för planering vs exekvering så att ett modellmisstag inte omedelbart kan mutera produktion.

Revisionspår och svarsherkomst

Om du inte kan rekonstruera en delegeringskedja, kan du inte förklara en incident, klara en revision eller bestrida en faktureringsanomalie.

Logga på tre lager:

Gateway: autentiseringsresultat, policybeslut, ruttad agent-ID, uppgifts-ID, föräldrauppgifts-ID, hastighetsbegränsningshändelser.

Agent: uppgiftstillståndsövergångar, meddelanden skickade/mottagna, modell/verktygsanrop (argument redigerade vid behov), skapade artefakter, delegering utåt.

MCP-server: verktygsnamn, caller agent-ID, användarkontext, framgång/fel, latens, påverkade rader eller resurs-ID:n (om policy tillåter).

Korrelatera med spår-ID över alla lager. Observability för LLM-system täcker instrumenteringsbackends; den här artikeln definierar vad måste fångas så att dessa backends har meningsfull signal.

Slutsvarsherkomst bör svara på: vilken användare, vilken orkestratoruppgift, vilka specialistagenter, vilka verktyg, vilka artefakter påverkade texten användaren såg, och vilka policygates avfyrades längs vägen.

Runtime-policy, utgående trafik och hemligheter

Runtime-policy-motorer (OPA, Cedar, custom rule services) utvärderar strukturerade händelser: “verktyg X med args Y för användare Z.” De kompletterar skyddsmekanismer eftersom de inte beror på att modellen beter sig bra.

Mänskligt godkännande hör hemma i runtime-policy för irreversibla eller högkostnadsåtgärder: betalningar, extern e-post, produktionskonfigurationsändringar, privilegiumtilldelningar.

Utgående kontroller begränsar vilka domäner MCP-server och agenter får anropa. En agent som både kan läsa hemligheter och POSTa till godtyckliga URL:er är en dataläck i väntan på att hända.

Hemligheter hör aldrig hemma i Agent Cards eller prompts. MCP-värdar ska injektera kortlivade inloggningsuppgifter vid exekveringstid från en hemlighetsmanager. För transportkryptering, nyckelhantering och baseline infra-säkerhetsmönster, se Arkitekturmönster för att säkra data.

Push-meddelandewebhooks i async A2A-flöden behöver samma rigor: verifiera sändaridentitet, avvisa stalin händelser och behandla aldrig en webhook-payload som auktorisering på egen hand.

Referenssäkerhetsarkitektur

Diagrammet nedsummerar en produktionsinriktad layout för A2A utanför, MCP innanför-deployment i stor skala.

flowchart TB subgraph Klientlager U[Användare / API-klient] end subgraph Kontrollplan GW[A2A gateway] REG[Agentregister] POL[Policy-motor] AUD[Revisionslogg] SEC[Hemlighetsmanager] end subgraph Agentlager OR[Orkestrator] SA[Specialistagenter] end subgraph Verktygslager MG[MCP gateway] MCP[MCP-server] end subgraph Observability OBS[Spårning + metriker] 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

Orkestratorn ser specialistagenter genom A2A. Specialister ser verktyg genom MCP. Användare får aldrig råa MCP-inloggningsuppgifter, och partners får aldrig interna färdighetsytor utan policygranskning.

För protokollkoncept (Agent Cards, uppgifter, artefakter), se Vad är A2A-protokollet?. För adoption och enterprise-ramverk, se Google A2A-protokollet 2026. För topologi när många agenter koordinerar, se Multi-agent orkestreringsmönster.

Produktionskontrolllista för A2A- och MCP-säkerhet

Innan du exponerar agentprotokoll bortom en betrodd sandbox, verifiera:

Identitet och autentisering

  • Inga anonyma agenter i produktionsvägar
  • Varje MCP- och A2A-anrop autentiserat vid varje begäran
  • OAuth-scopes eller ekvivalent kopplade till färdigheter/verktyg, inte blanket-admin
  • Offentlig vs autentiserad Agent Card-vy definierad medvetet

Delegering och policy

  • Delegeringstokens bär användar-ID, uppgifts-ID, scope, utgångsdatum, hopgräns
  • Nedströmsagenter avvisar scope-expansion utan explicit godkännande
  • Högriskverktyg kräver runtime-policy eller mänskligt godkännande
  • Resonemang och exekvering använder separata inloggningsuppgifter där möjligt

Upptäckt och register

  • Agentregisterposter har ägare och versionshistorik
  • Agent Cards uppdaterade på TTL; signaturer verifierade där stöd finns
  • Partneragenter federerade med explicita färdighetsallowlists

Revision och observability

  • Gateway-, agent- och MCP-lager emitterar korrelerade revisionshändelser
  • Delegeringskedjor loggade med föräldra- och barnuppgifts-ID:n
  • Artefaktherkomst registrerad för slutsvaren
  • Spår-ID:n kopplade till observability-backends

Missbruk och resiliens

  • Hastighetsbegränsningar per användare, agent och hyresgäst
  • Timeout-policy på delegerade uppgifter
  • Utgående allowlists på verktygsserver
  • Hemligheter i en manager, inte i cards, prompts eller repos

Slutsats

A2A- och MCP-interoperabilitet är kraftfull eftersom agenter och verktyg kan komponeras över team- och leverantörsgränser, men den kraften är osäker utan identitet, auktorisering, delegeringsgränser och revisionsdesign. Skyddsmekanismer skyddar modellkonversationen; protokollsäkerhet skyddar de åtgärder agenter utför på användarens vägnar.

Behandla Agent Cards som annonser, delegering som ett signerat kontrakt, MCP-verktyg som privilegierad kodexekvering, och revisionsloggar som den beviskedja du kommer att behöva när något intressant händer klockan 2 på natten.

Bygg gatewayen när styrning behöver en enda hals att kväva. Dela inloggningsuppgifter innan du delar agenter. Logga varje hopp så att svaret “modellen bestämde” aldrig blir den slutliga incidentrapporten.

Vanliga frågor

Vad är skillnaden mellan LLM-skyddsmekanismer och A2A MCP-agentsäkerhet? Skyddsmekanismer begränsar modellens in- och utdata. Protokollsäkerhet begränsar vem som får anropa verktyg, delegera uppgifter och agera på vars vägnar över MCP och A2A med identitet, auktorisering och revisionspår.

Hur ska agentidentitet fungera i en A2A-deployment? Separera mänsklig, agentservice- och uppgiftsidentitet. Validera inloggningsuppgifter vid varje begäran, använd scoped tokens, och behandla Agent Cards som upptäcktsmetadata snarare än bevis på tillit.

Vad är confused deputy-problemet i multi-agentsystem? Det uppstår när en privilegierad agent eller verktyg utför en känslig åtgärd eftersom en mindre privilegierad caller smög in instruktioner genom delegering eller artefakter. Tillämpa scope vid varje hopp.

Behöver du en A2A gateway i produktion? Single-team interna deployment kan tillämpa policy per agent. Multi-tenant, multi-leverantör eller partner-inriktade nätverk behöver vanligtvis en gateway för centraliserad autentisering, ruttning, hastighetsbegränsningar och revision.

Vad ska en A2A MCP-revisionslogg innehålla? Användar-ID, agent-ID, uppgifts-ID, föräldrauppgifts-ID, verktygsanrop, policybeslut, artefakter och tidsstämplar korrelerade med spår-ID:n över gateway-, agent- och MCP-lager.

Källor

Prenumerera

Få nya inlägg om system, infrastruktur och AI-ingenjörskonst.