Chrome dodał wytyczne dotyczące bezpieczeństwa dla WebMCP – nowego sposobu, w jaki witryny udostępniają narzędzia agentom AI – i wprost nakłada na właścicieli stron odpowiedzialność za bezpieczeństwo tych narzędzi. Wytyczne ostrzegają, że każda strona, która ogłosi się „agent-ready”, otwiera również drogę złośliwym aktorom do przejęcia agentów za pomocą spreparowanych manifestów lub zanieczyszczonych danych wyjściowych.

Dlaczego WebMCP ma teraz znaczenie

Deweloperzy od dawna zadawali pytanie: czy agent AI może przeczytać moją stronę i sfinalizować transakcję? WebMCP zmienia ten scenariusz. Zamiast pozwalać agentowi zgadywać, jak działa proces zakupowy, strona publikuje manifest, który precyzyjnie informuje agenta, jakie działania może on podjąć – sprawdzanie cen, aktualizacja koszyka, pobieranie opinii i tak dalej. Wynikiem jest znacznie bardziej zdolny asystent, ale także nowa powierzchnia ataku: w momencie, gdy strona przekazuje agentowi narzędzie, przekazuje mu zestaw instrukcji, które można podważyć.

Dwa wektory przejęcia, których muszą obawiać się deweloperzy

Złośliwe manifesty – Atakujący wstrzykują ukryte polecenia do nazw lub opisów narzędzi. Ponieważ agenci traktują każdy ciąg tekstowy jako potencjalną instrukcję, sprytnie sformułowana nazwa może nadpisać pierwotne zadanie agenta i zmusić go do wykonania niezamierzonej czynności.

Zanieczyszczone dane wyjściowe – To częstsza droga. Zgodne z prawem narzędzie zwraca dane generowane przez użytkowników – recenzje produktów, posty na forum, komentarze. Jeśli złośliwy użytkownik przemyci polecenie w takiej treści, narzędzie przekaże je bezpośrednio do agenta. Duże modele językowe (LLM) nie rozróżniają w sposób niezawodny danych od instrukcji; traktują cały strumień danych jako pojedynczy prompt.

Praktyczne kroki w celu zabezpieczenia manifestu

Wytyczne Chrome sprowadzają się do trzech zasad konfiguracji, które deweloperzy mogą dodać do swoich plików manifestu WebMCP.

  • Ogranicz dostęp do swoich narzędzi – Użyj reguły exposedTo, aby stworzyć białą listę zaufanych platform agentów. Narzędzie do przetwarzania płatności, na przykład, nie powinno być widoczne dla każdego agenta AI w sieci. Zdefiniuj dokładne źródła (origins), które mogą wywoływać narzędzie, i odrzuć pozostałe.

  • Oznaczaj niepewne treści – Dodaj flagę untrustedContentHint do każdego narzędzia, które zwraca dane pochodzące od użytkowników, takie jak recenzje czy komentarze. Informuje to agenta, że ładunek (payload) może zawierać złośliwe instrukcje, co skłania go do zastosowania surowszych filtrów bezpieczeństwa przed podjęciem działania na podstawie tekstu.

  • Zadeklaruj zachowanie typu read-only – Flaga readOnlyHint pozwala zasygnalizować, czy narzędzie służy wyłącznie do odczytu danych, czy może również zapisywać lub zmieniać stan. Gdy narzędzie jest w trybie read-only, agent może kontynuować działanie bez dodatkowego potwierdzenia użytkownika; gdy może coś zmodyfikować, agent powinien zapytać użytkownika o zgodę przed kontynuowaniem.

Czego deweloperzy mogą się sprzeciwiać

Szersza stawka

Na co warto zwrócić uwagę w przyszłości

Podsumowanie

Sprawienie, by strona była „agent-ready”, nie jest już tylko elementem odhaczanym dla zwiększenia widoczności; to odpowiedzialność za bezpieczeństwo. Poprzez ograniczanie dostępu, oznaczanie niepewnych danych wyjściowych i wyraźne wskazywanie narzędzi typu read-only, deweloperzy mogą zapobiec sytuacji, w której atakujący zmienią pomocnego asystenta AI w kanał do nadużyć. Traktuj manifest jak każde inne publiczne API: audytuj go, wersjonuj i zabezpieczaj, zanim udostępnisz go światu.