Luka w serwerze MCP Azure DevOps pozwala przejąć agenta AI recenzującego kod

Firma Manifold Security opisała lukę w oficjalnym serwerze MCP Azure DevOps od Microsoftu, która pozwala przejąć kontrolę nad agentem AI recenzującym pull requesty. Wystarczy ukryty komentarz w opisie zgłoszenia, niewidoczny dla człowieka w interfejsie, ale odczytywany przez agenta wprost z API.

Mechanizm ataku jest prosty i nie wymaga żadnego złamania zabezpieczeń w klasycznym rozumieniu. Azure DevOps pozwala formatować opisy pull requestów w Markdown, a Markdown obsługuje komentarze HTML w formacie ukrytym przed użytkownikiem. Taki komentarz nie wyświetla się w przeglądarce, ale REST API Azure DevOps zwraca go w całości, łącznie z treścią, którą programista nigdy nie zobaczył na ekranie.

Jak działa przejęcie

Gdy programista prosi swojego agenta AI o recenzję pull requesta, agent pobiera opis zgłoszenia przez serwer MCP i traktuje jego treść jako część własnego kontekstu poleceń. Jeśli w opisie ukryto instrukcję, agent wykonuje ją tak samo jak polecenie wydane przez człowieka, bo z jego perspektywy nie ma różnicy między tekstem od użytkownika a tekstem pobranym z zewnętrznego źródła.

W przykładzie opisanym przez Manifold Security ukryta instrukcja kazała agentowi zatwierdzić pull request, uruchomić potok budowania w zupełnie innym projekcie o nazwie 'Payments', odczytać tam poufną stronę wiki, a następnie przesłać jej treść z powrotem jako komentarz w pull requeście, widoczny dla atakującego. Agent miał też nie informować o tym reweranta.

Kluczowy problem polega na tym, że agent działa z uprawnieniami recenzenta, czyli osoby, która poprosiła go o pomoc. Atakujący może w ten sposób sięgnąć do zasobów, do których sam nie ma dostępu, bo to nie jego konto wykonuje operacje, lecz konto ofiary działające przez agenta.

Dziura w zabezpieczeniach, które już istniały

Microsoft wcześniej wdrożył w serwerze MCP Azure DevOps mechanizm nazywany 'spotlighting', czyli opakowywanie niezaufanej treści zewnętrznej w wyraźne znaczniki, które pomagają modelowi odróżnić dane od poleceń. Problem w tym, że zabezpieczenie zastosowano niekonsekwentnie. Narzędzia zwracające treść potoków budowania i stron wiki mają je wdrożone, ale narzędzie zwracające opis pull requesta, czyli dokładnie ten punkt, który wykorzystali badacze, zostało pominięte.

To pokazuje typowy problem przy zabezpieczaniu agentów AI przed wstrzykiwaniem poleceń: wystarczy jedno niepokryte miejsce w interfejsie programistycznym, żeby cała reszta ochrony straciła sens. Manifold Security zgłosiło lukę do Microsoft Security Response Center, które potwierdziło i zaklasyfikowało problem, ale na dzień publikacji raportu nie wydano ani łatki, ani numeru CVE.

Kolejny przypadek w rosnącej fali

To już kolejne w ostatnich tygodniach doniesienie o technikach wstrzykiwania poleceń wymierzonych w agenty kodujące, obok wcześniej opisywanych ataków wykorzystujących ukryte instrukcje w plikach graficznych czy fałszywe metadane. Wspólnym mianownikiem jest to, że agenci AI z dostępem do repozytoriów, systemów CI/CD i dokumentacji firmowej stają się nowym, atrakcyjnym celem, bo łączą szerokie uprawnienia z ograniczoną zdolnością odróżnienia zaufanej treści od złośliwej.

Manifold Security podkreśla, że rozwiązaniem nie może być samo ograniczanie uprawnień agenta, bo w tym przypadku każda z wykonanych czynności była zgodna z nadanymi prawami dostępu. Firma rekomenduje zamiast tego bieżący nadzór nad tym, co agent faktycznie robi w danej sesji, a nie poleganie wyłącznie na modelu uprawnień ustalonym z góry.

Co to oznacza dla firm w Polsce

Azure DevOps jest jednym z popularniejszych narzędzi do zarządzania kodem w polskich firmach korzystających z ekosystemu Microsoftu, a integracje z agentami kodującymi, od Copilota po narzędzia oparte na Claude czy GPT, przybywają w tym samym tempie co w innych krajach. Zespoły, które podłączyły agenta AI do recenzowania pull requestów przez MCP, powinny traktować tę lukę jako sygnał do sprawdzenia, jakie uprawnienia faktycznie ma taki agent i czy jego działania są logowane w sposób pozwalający wykryć nietypową sekwencję operacji.

Do czasu wydania łatki jedynym praktycznym zabezpieczeniem pozostaje ograniczenie zaufania do treści pull requestów pochodzących od zewnętrznych współpracowników oraz ręczna weryfikacja, zanim agent AI otrzyma polecenie zatwierdzenia zmian lub uruchomienia potoku budowania w innym projekcie.