Bezpieczeństwo agentów A2A i MCP: tożsamość, delegowanie i ślady audytowe

Iniekcja promptów przyciąga większość uwagi w zakresie bezpieczeństwa systemów LLM i zasługuje na nią, ale nie jest jedynym problemem, gdy agenty zaczynają korzystać z narzędzi i delegować zadania innym agentom.

MCP zapewnia agentom strukturyzowany dostęp do plików, interfejsów API, baz danych i systemów ticketingowych. A2A pozwala jednemu agentowi przesyłać zadania, wiadomości i artefakty do innego agenta, który może należeć do innego zespołu, dostawcy lub środowiska wykonawczego. Te protokoły są przydatne właśnie dlatego, że przekraczają granice zaufania, co oznacza, że tożsamość, autoryzacja, limity delegowania i ślady audytowe stają się kluczowymi elementami architektury, a nie opcjonalnymi zabezpieczeniami.

Ten artykuł jest przewodnikiem referencyjnym dotyczącym bezpieczeństwa protokołów agentów w klastrze Architektura LLM. Omawia modele zagrożeń, tożsamość, bramki, rejestr, delegowanie oraz listy kontrolne produkcyjne. W przypadku walidacji danych wejściowych, filtrowania danych wyjściowych i wzorców bezpieczeństwa promptów zobacz artykuł Bariery ochronne LLM w praktyce.

Bariery ochronne (Guardrails) vs Bezpieczeństwo protokołów vs Polityki czasu rzeczywistego

Te trzy warstwy rozwiązują różne problemy i zawodzą na różne sposoby, gdy są łączone w jedno.

Bariery ochronne LLM (LLM guardrails) operują na danych wejściowych i wyjściowych modelu: blokują wzorce iniekcji, filtrują szkodliwe treści, walidują strukturę JSON i egzekwują reguły dotyczące tonu lub zgodności w generowanym tekście. Chronią warstwę konwersacji.

Bezpieczeństwo protokołów operuje na granicach agentów: kto może wywołać które narzędzie MCP, który agent może delegować zadania do którego odpowiednika, jakie zakresy OAuth są przypisane do zadania i czy agent dalszy może działać w imieniu użytkownika. Chroni warstwę akcji.

Polityka czasu rzeczywistego (Runtime policy) znajduje się między nimi: silnik polityk ocenia żądania względem reguł, niezależnie od tego, czy wyzwoleniem była język naturalny, czy wywołanie strukturyzowanego protokołu. Może wymagać zatwierdzenia przez człowieka przed wykonaniem narzędzia, blokować ruch wychodzący do nieznanych domen lub odrzucać delegowanie, gdy zakres przekracza uprawnienia użytkownika źródłowego.

Moim zdaniem: bariery ochronne bez bezpieczeństwa protokołów tworzą uprzejme czatboty, które nadal eksfiltrują dane poprzez wywołanie narzędzia. Bezpieczeństwo protokołów bez barier ochronnych tworzy dobrze uwierzytelnione agenty, które nadal wykonują złośliwe instrukcje osadzone w artefakcie. Potrzebujesz obu, plus polityki czasu rzeczywistego dla akcji o wysokim ryzyku.

Model zagrożeń dla systemów agentów A2A i MCP

Zacznij od zasobów i przeciwników, a nie od listy zakupu kontroli.

Zasoby wartych ochrony: dane użytkowników w promptach i artefaktach, poświadczenia serwerów MCP, systemy produkcyjne dostępne przez narzędzia, reputacja agentów, konta rozliczeniowe powiązane z użyciem tokenów oraz integralność audytu.

Realistyczne przeciwniki: zewnętrzni użytkownicy nadużywający publicznych punktów końcowych agentów, sfałszowane serwery MCP zwracające zatrute wyniki narzędzi, złośliwe agenty zafałszowujące umiejętności w Karta Agentów (Agent Cards), interni nadmiernie delegujący uprawnienia oraz manipulacje w łańcuchu dostaw metadanych narzędzi, które manipulują zachowaniem modelu.

Złośliwe lub sfałszowane narzędzia (MCP)

Serwer MCP to kod i dane narażone na model. Wrogi serwer może zwracać mylące opisy narzędzi, eksfiltrować argumenty przekazywane przez model lub wykonywać działania wykraczające poza intencje użytkownika, gdy host wykonuje wywołania narzędzi bez poświadczeń o określonym zakresie.

Złośliwe lub podszywające się agenty (A2A)

Agent akceptujący zadania może być zły, sfałszowany lub po prostu nadmiernie uprawniony. Karty Agentów opisują możliwości; nie dowodzą tożsamości, chyba że weryfikujesz podpisy, TLS i zaufanie do wystawcy.

Problem „zdezorientowanego pełnomocnika” (Confused deputy)

Agent B ma uprawnienie do dostępu do API finansowego. Agent A, z niższymi uprawnieniami, prosi B o „podsumowanie tego faktura”, ukrywając w artefakcie instrukcję transferu. B wykonuje akcję używając własnych poświadczeń, chyba że zakres delegowania jest egzekwowany end-to-end.

Nadmiernie szerokie uprawnienia i ukryte łańcuchy delegowania

Użytkownik zatwierdza jeden krok. Orkiestrator cicho łączy trzy skoki A2A i pięć wywołań MCP. Użytkownik nie widzi pełnego grafu, ale organizacja jest nadal odpowiedzialna za wynik.

Iniekcja promptów przez artefakty i wiadomości międzyagentowe

Iniekcja to nie tylko problem wiadomości od użytkownika. Artefakt PDF, strona internetowa pobrana przez narzędzie lub wiadomość od Agent C mogą przenosić instrukcje skierowane do modelu Agent D. Traktuj wszystkie treści przenoszone przez protokół jako niezaufane dane wejściowe na granicy modelu.

Zatrute lub mylące Karty Agentów

Opisy i nazwy umiejętności to powierzchnia ataku promptów. Karta reklamująca safe_read_only_analysis (bezpieczna analiza tylko do odczytu), a akceptująca backendy z możliwością zapisu, to warstwa inżynierii społecznej, a nie gwarancja techniczna.

Model tożsamości dla systemów wieloagentowych

Bezpieczeństwo protokołów zaczyna się od jasnych typów tożsamości i tego, co każdy z nich może potwierdzić.

Karta Agentów A2A reklamuje obsługiwane schematy uwierzytelniania (OAuth 2.0, klucze API, mTLS i podobne wzorce zgodne z praktyką OpenAPI) oraz umiejętności z opcjonalnymi wymaganiami bezpieczeństwa. Karta jest metadanymi odkrycia, a nie kotwicą zaufania. Klienci uzyskują poświadczenia poza pasmem i wysyłają je w standardowych nagłówkach HTTP przy każdym żądaniu; serwery muszą je weryfikować przy każdym wywołaniu i zwracać 401 lub 403, gdy autoryzacja lub zakres zawiodą.

Wgledy wewnętrzne vs zewnętrzne tego samego agenta

Producyjni agenty często publikują publiczną Kartę Agentów z ograniczoną listą umiejętności i bogatszą uwierzytelnioną kartę dla wywołujących wewnętrznych. Specyfikacja A2A pozwala na rozszerzone karty dla uwierzytelnionych klientów. Używaj tego podziału świadomie: partnerzy nie powinni widzieć wewnętrznych umiejętności, a wewnętrzni orkiestratorzy nie powinni polegać wyłącznie na publicznym odkryciu w celu autoryzacji.

Uwierzytelnianie i autoryzacja dla MCP i A2A

Uwierzytelnianie odpowiada na pytanie kto wywołuje. Autoryzacja odpowiada na pytanie co mogą robić.

Dostęp do narzędzi MCP

Dla każdego połączenia MCP zdefiniuj:

• który host agenta może się łączyć
• które narzędzia są włączone dla tego hosta
• który użytkownik systemu operacyjnego lub konto usługi wykonuje efekty uboczne
• czy użytkownik ludzki musi zatwierdzić każde wywołanie modyfikujące

Preferuj listy dozwolonych narzędzi (allowlists) zamiast konfiguracji MCP „połącz wszystko”. Agent kodujący nie potrzebuje serwerów MCP do płacy na tym samym profilu co publiczny bot wsparcia.

Dostęp do agentów A2A

Dla każdej relacji między agentami zdefiniuj:

• które ID agentów wywołujących mogą wywoływać które umiejętności
• maksymalną głębokość delegowania
• które typy artefaktów mogą przekraczać granicę
• czy kontekst użytkownika musi być propagowany jako podpisane roszczenia (claims)

Mapuj zakresy OAuth (lub równoważniki) na umiejętności, a nie na ogólny admin agenta. Najmniejsza uprawnienie na warstwie tokena jest lepsze niż nadzieja na warstwie promptu.

Polityka egzekwowana przez bramkę vs polityka per agent

Polityka per agent działa, gdy jeden zespół posiada cały graf i koordynuje wydania. Polityka egzekwowana przez bramkę działa, gdy wiele zespołów, tenantów lub dostawców współdzieli sieć agentów i potrzebujesz jednego miejsca do egzekwowania list dozwolonych, limitów przepływności i audytu.

Bramka A2A jako płaszczyzna kontrolna

Bramka A2A nie jest ściśle wymagana przez protokół, ale staje się konieczna, gdy ruch agentów wymaga scentralizowanego zarządzania.

Bramka typowo obsługuje:

• zakończenie uwierzytelniania i wymianę tokenów
• routing do odpowiedniej usługi agenta według umiejętności lub tenantu
• kontrole polityki przed akceptacją lub przesyłaniem zadań
• negocjacje wersji protokołu
• limitowanie przepływności i wykrywanie nadużyć
• strukturyzowaną emisję audytu przy każdej zmianie stanu zadania

Kiedy bramka jest przesadą, a kiedy konieczna

Bramka jest często przesadą dla pojedynczego orkiestratora i dwóch agentów specjalistów w jednej przestrzeni nazw Kubernetes utrzymywanej przez jeden zespół. Staje się konieczna, gdy partnerzy wywołują Twoje agenty, gdy wiele jednostek biznesowych współdzieli infrastrukturę, gdy compliance wymaga jednolitego logowania lub gdy nie możesz ufać każdej implementacji agenta, że poprawnie egzekwuje politykę.

Połącz bramkę A2A z bramką MCP (lub proxy MCP), aby dostęp do narzędzi otrzymywał takie samo traktowanie: tożsamość, listy dozwolonych, kontrole ruchu wychodzącego i audyt na granicy narzędzia, a nie tylko w interfejsie użytkownika czatu.

Karty Agentów skierowane do partnerów vs wewnętrzne

Publikuj różne metadane odkrycia dla wywołujących zewnętrznych i wewnętrznych. Zewnętrzne karty eksponują wąskie umiejętności i ścisłe autoryzacje. Wewnętrzne karty mogą zawierać umiejętności konserwacyjne lub administracyjne, ale nigdy nie powinny być osiągalne bez silniejszego uwierzytelniania niż sugeruje karta publiczna.

Rejestr agentów i bezpieczeństwo odkrycia

Odkrycie jest częścią powierzchni ataku. Każdy, kto kontroluje, które agenty są „dostępne”, kontroluje, gdzie orkiestratorzy wysyłają pracę.

Rejestr vs dobrze znane adresy URL Kart Agentów

Małe wdrożenia używają dobrze znanych URLi dla każdego agenta (/.well-known/agent-card.json). Wdrożenia enterprise dodają rejestr, który indeksuje ID agentów, wersje, punkty końcowe, właścicieli i tagi polityki. Rejestr to obiekt polityki: wpisy powinny rejestrować, które tenanci mogą odkrywać które agenty, a nie tylko gdzie znajdują się one.

Wersjonowanie, wycofywanie i własność

Rekordy rejestru potrzebują właścicieli, historii zmian i dat wycofania. Orkiestrator, który buforuje Karty Agentów, musi odświeżać je zgodnie z TTL i weryfikować podpisy, gdzie są obsługiwane. Przewyższające karty to sposób, w jaki wycofane umiejętności nadal otrzymują ruch długo po naprawieniu podatności.

Wewnętrzne sieci enterprise vs zewnętrzni partnerzy

Wewnętrzne sieci agentów mogą polegać na mTLS i prywatnym DNS. Agenci partnerów potrzebują wyraźnych zasad federacji, umownie zakreślonych umiejętności i silniejszej inspekcji artefaktów, ponieważ nie kontrolujesz ich środowiska wykonawczego.

Delegowanie na granicach agentów

Delegowanie to miejsce, w którym bezpieczeństwo A2A jest wygrywane lub przegrywane. Gdy Agent A wysyła zadanie do Agent B, trzy pytania muszą mieć precyzyjne odpowiedzi:

1. Czyja władza jest wykonywana? Użytkownika, konta usługi A, czy połączonego delegowanego tokena?
2. Co B może zrobić z tą władzą? Analiza tylko do odczytu, czy narzędzia modyfikujące w imieniu A?
3. Kto ponosi odpowiedzialność, jeśli B przekroczy zakres? A, B, polityka bramki, czy człowiek, który zatwierdził niejasny prompt?

Propagowanie intencji użytkownika vs nadmierna delegacja

Przesyłaj podpisane roszczenia delegacji, które zawierają ID użytkownika, oryginalne ID zadania, dozwolone umiejętności, wygaśnięcie i maksymalną liczbę skoków. Agenty dalsze muszą odrzucać zadania, które cicho rozszerzają zakres. Jeśli B potrzebuje wyższych uprawnień niż posiadał A, przejdź do wymagany_wejście (input_required) i uzyskaj wyraźną zgodę człowieka, zamiast niewidocznie podnosić tokeny.

Flows zatwierdzenia człowieka w pętli dla ryzykownego delegowania są omawiane w Strumieniowanie A2A i zadania asynchroniczne dla długotrwałych przepływów pracy agentów, gdzie wymagany_wejście jest stanem zadania pierwszego rzutu, a nie błędem.

Oddzielanie rozumowania od uprawnień wykonawczych

Agent może potrzebować szerokiego dostępu do odczytu do planowania, podczas gdy narzędzia zapisu znajdują się za zatwierdzeniem. Podziel poświadczenia lub użyj odrębnych profili MCP do planowania vs wykonania, aby błąd modelu nie mógł natychmiast zmodyfikować produkcji.

Ślady audytowe i pochodzenie odpowiedzi

Jeśli nie możesz odtworzyć łańcucha delegowania, nie możesz wyjaśnić incydentu, przejść audytu lub zakwestionować anomalii rozliczeniowych.

Loguj na trzech warstwach:

Bramka: wynik uwierzytelniania, decyzja polityki, ID routowanego agenta, ID zadania, ID zadania nadrzędnego, zdarzenia limitowania przepływności.

Agent: zmiany stanu zadania, wysłane/odebrane wiadomości, wywołania modelu/narzędzi (argumenty zredagowane w razie potrzeby), utworzone artefakty, delegowanie na zewnątrz.

Serwer MCP: nazwa narzędzia, ID agenta wywołującego, kontekst użytkownika, sukces/niepowodzenie, opóźnienie, liczba wierszy lub ID zasobów (zgodnie z polityką).

Koreluj z ID śledzenia (trace ID) na wszystkich warstwach. Obserwowalność systemów LLM omawia backendy instrumentacyjne; ten artykuł definiuje co musi być przechwytywane, aby te backendy miały sensowny sygnał.

Pochodzenie końcowej odpowiedzi powinno odpowiadać: który użytkownik, które zadanie orkiestratora, które agenty specjalistów, które narzędzia, które artefakty wpłynęły na tekst widoczny przez użytkownika i które brany polityki zostały uruchomione w trakcie.

Polityka czasu rzeczywistego, ruch wychodzący i sekrety

Silniki polityki czasu rzeczywistego (OPA, Cedar, własne usługi reguł) oceniają strukturyzowane zdarzenia: „narzędzie X z argumentami Y dla użytkownika Z”. Uzupełniają one bariery ochronne, ponieważ nie polegają na dobrym zachowaniu modelu.

Zatwierdzenie przez człowieka należy do polityki czasu rzeczywistego dla działań nieodwracalnych lub o wysokich kosztach: płatności, e-mail zewnętrzny, zmiany konfiguracji produkcyjnej, przyznawanie uprawnień.

Kontrole ruchu wychodzącego limitują, które domeny mogą wywoływać serwery MCP i agenty. Agent, który może zarówno czytać sekrety, jak i wysyłać POST do dowolnych URLi, to czekająca utrata danych.

Sekrety nigdy nie powinny znajdować się w Kartach Agentów ani w promptach. Hosty MCP powinny wstrzykiwać poświadczenia o krótkim czasie życia w czasie wykonania z menedżera haseł. W przypadku szyfrowania transportu, zarządzania kluczami i podstawowych wzorców bezpieczeństwa infrastruktury zobacz Wzorce architektoniczne zabezpieczania danych.

Webhooki powiadomień push w asynchronicznych przepływach A2A potrzebują tej samej rygorystyczności: weryfikuj tożsamość nadawcy, odrzucaj przeterminowane zdarzenia i nigdy nie traktuj ładunku webhooka jako autoryzacji sam w sobie.

Referencyjna architektura bezpieczeństwa

Poniższy diagram podsumowuje ukierunkowany na produkcję układ dla wdrożeń A2A na zewnątrz, MCP wewnątrz w skali.

Orkiestrator widzi agenty specjalistów przez A2A. Specjaliści widzą narzędzia przez MCP. Użytkownicy nigdy nie otrzymują surowych poświadczeń MCP, a partnerzy nigdy nie otrzymują wewnętrznych powierzchni umiejętności bez przeglądu polityki.

W przypadku koncepcji protokołów (Karty Agentów, zadania, artefakty) zobacz Czym jest protokół A2A?. W przypadku adopcji i ram enterprise zobacz Protokół Google A2A w 2026 roku. W przypadku topologii, gdy wiele agentów koordynuje się, zobacz Wzorce orkiestracji wieloagentowej.

Lista kontrolna produkcyjna dla bezpieczeństwa A2A i MCP

Przed wystawieniem protokołów agentów poza zaufaną piaskownicę, zweryfikuj:

Tożsamość i autoryzacja

• Brak anonimowych agentów w ścieżkach produkcyjnych
• Każde wywołanie MCP i A2A jest uwierzytelniane przy każdym żądaniu
• Zakresy OAuth lub równoważniki są mapowane na umiejętności/narzędzia, a nie na ogólny admin
• Widoki publicznych vs uwierzytelnionych Kart Agentów są zdefiniowane świadomie

Delegowanie i polityka

• Tokeny delegacji zawierają ID użytkownika, ID zadania, zakres, wygaśnięcie, limit skoków
• Agenty dalsze odrzucają rozszerzanie zakresu bez wyraźnego zatwierdzenia
• Narzędzia o wysokim ryzyku wymagają polityki czasu rzeczywistego lub zatwierdzenia przez człowieka
• Rozumowanie i wykonanie używają oddzielnych poświadczeń, o ile to możliwe

Odkrywanie i rejestr

• Wpisy w rejestrze agentów mają właścicieli i historię wersji
• Karty Agentów są odświeżane zgodnie z TTL; podpisy są weryfikowane, gdzie są obsługiwane
• Agenci partnerów są federowani z wyraźnymi listami dozwolonych umiejętności

Audyt i obserwowalność

• Warstwy bramki, agenta i MCP emitują skorelowane zdarzenia audytowe
• Łańcuchy delegowania są logowane z ID zadań nadrzędnych i podrzędnych
• Pochodzenie artefaktów jest rejestrowane dla końcowych odpowiedzi
• ID śledzenia (Trace IDs) są połączone z backendami obserwowalności

Nadużycia i odporność

• Limity przepływności per użytkownik, agent i tenant
• Polityki timeout dla zadanych zadań delegowanych
• Listy dozwolonych dla ruchu wychodzącego na serwerach narzędzi
• Sekrety w menedżerze, a nie w kartach, promptach czy repozytoriach

Podsumowanie

Interoperacyjność A2A i MCP jest potężna, ponieważ agenty i narzędzia mogą się komponować na granicach zespołów i dostawców, ale ta moc jest niebezpieczna bez tożsamości, autoryzacji, limitów delegowania i projektowania audytu. Bariery ochronne chronią konwersację modelu; bezpieczeństwo protokołów chroni działania podejmowane przez agenty w imieniu użytkowników.

Traktuj Karty Agentów jako reklamy, delegowanie jako podpisany kontrakt, narzędzia MCP jako przywilejowaną egzekucję kodu, a dzienniki audytu jako łańcuch dowodów, którego będziesz potrzebować, gdy wydarzy się coś ciekawego o 2:00 w nocy.

Buduj bramkę, gdy governance potrzebuje jednego gardła do duszenia. Dzielić poświadczenia przed podziałem agentów. Loguj każdy skok, aby odpowiedź „model zdecydował” nigdy nie była końcowym raportem incydentu.

Najczęściej zadawane pytania

Jaka jest różnica między barierami ochronnymi LLM a bezpieczeństwem agentów A2A MCP? Bariery ochronne ograniczają dane wejściowe i wyjściowe modelu. Bezpieczeństwo protokołów ogranicza, kto może wywoływać narzędzia, delegować zadania i działać w czyimś imieniu w ramach MCP i A2A, przy użyciu tożsamości, autoryzacji i śladów audytowych.

Jak powinna działać tożsamość agenta w wdrożeniu A2A? Oddziel tożsamości człowieka, usługi agenta i zadania. Weryfikuj poświadczenia przy każdym żądaniu, używaj tokenów o określonym zakresie i traktuj Karty Agentów jako metadane odkrycia, a nie dowód zaufania.

Czym jest problem „zdezorientowanego pełnomocnika” w systemach wieloagentowych? Występuje, gdy uprzywilejowany agent lub narzędzie wykonuje wrażliwą akcję, ponieważ mniej uprzywilejowany wywołujący ukrył instrukcje poprzez delegowanie lub artefakty. Egzekwuj zakres przy każdym skoku.

Czy potrzebujesz bramki A2A w produkcji? Wdrożenia wewnętrzne jednego zespołu mogą egzekwować politykę per agent. Siecie wielotenantowe, wielodostawcze lub skierowane do partnerów zwykle potrzebują bramki do scentralizowanej autoryzacji, routingu, limitów przepływności i audytu.

Co powinien zawierać dziennik audytu A2A MCP? ID użytkownika, ID agenta, ID zadania, ID zadania nadrzędnego, wywołania narzędzi, decyzje polityki, artefakty i znaczniki czasu skorelowane z ID śledzenia na warstwach bramki, agenta i MCP.

Źródła

• Protokół A2A – Tematy bezpieczeństwa enterprise: https://github.com/a2aproject/A2A/blob/main/docs/topics/enterprise-ready.md
• Protokół A2A – Przegląd specyfikacji: https://a2a-protocol.org/latest/specification/
• Protokół A2A – Bezpieczeństwo strumieniowania i powiadomień push: https://a2a-protocol.org/latest/topics/streaming-and-async/