Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Rosnąca popularność agentów AI w procesach DevSecOps zwiększa tempo przeglądu kodu, automatyzacji analiz i obsługi pull requestów. Jednocześnie pojawia się nowa kategoria zagrożeń, w której model językowy staje się pośrednikiem wykonującym działania w środowisku deweloperskim z uprawnieniami użytkownika.
Opisana luka w Azure DevOps MCP dotyczy ataku typu pośredni prompt injection. Złośliwa treść może zostać ukryta w opisie pull requestu w sposób niewidoczny dla człowieka, ale nadal czytelny dla modelu AI pobierającego dane przez API. W efekcie agent analizujący zmiany może potraktować taki ukryty komunikat jako instrukcję operacyjną.
W skrócie
Badacze wykazali, że oficjalny serwer Azure DevOps MCP, używany do łączenia agentów AI z zasobami Azure DevOps, mógł przekazywać modelowi nieoznakowaną, nieufną treść zawartą w opisie pull requestu. Atak wykorzystuje ukryty komentarz HTML, który nie jest widoczny w interfejsie webowym, ale pozostaje dostępny w odpowiedzi API.
- atakujący umieszcza ukryty komentarz HTML w opisie PR,
- agent AI pobiera opis przez MCP i analizuje go jako część kontekstu,
- model może wykonać działania zgodne z ukrytymi instrukcjami,
- skutkiem może być dostęp do innych projektów, danych lub narzędzi.
Kontekst / historia
Azure DevOps MCP został zaprojektowany jako warstwa pośrednia umożliwiająca agentom AI pracę na zasobach organizacji, takich jak repozytoria, pipeline’y, wiki czy elementy robocze. Tego rodzaju integracja poprawia produktywność, ale równocześnie rozszerza powierzchnię ataku, ponieważ agent może działać z uprawnieniami użytkownika inicjującego zadanie.
Problem wpisuje się w szerszy trend zagrożeń związanych z agentami AI korzystającymi z narzędzi i danych organizacyjnych. W takich przypadkach nie chodzi o klasyczne obejście autoryzacji, lecz o manipulację kontekstem wejściowym modelu, tak aby wykonał działania zgodne z intencją atakującego.
Szczególnie istotna okazała się różnica pomiędzy tym, co widzi użytkownik w interfejsie, a tym, co trafia do modelu przez API. Producent wdrożył wcześniej mechanizmy oznaczania nieufnej treści dla części ścieżek odpowiedzi, jednak ścieżka odpowiedzialna za pobieranie danych pull requestu nie obejmowała tego zabezpieczenia.
Analiza techniczna
Rdzeń luki dotyczy sposobu obsługi opisu pull requestu. Azure DevOps obsługuje Markdown, a ten umożliwia osadzanie komentarzy HTML. Dla człowieka taki komentarz pozostaje niewidoczny w interfejsie, lecz odpowiedź REST API może zwracać go w niezmienionej postaci.
Jeżeli agent AI zostaje uruchomiony do recenzji pull requestu, serwer MCP pobiera opis i przekazuje go dalej do modelu. Jeżeli ta treść nie zostanie wyraźnie oddzielona od instrukcji systemowych lub poleceń sterujących, model może błędnie uznać ukryty komentarz za wiążące polecenie.
Przykładowy scenariusz ataku wygląda następująco:
- atakujący z prawem zapisu tworzy PR z ukrytym komentarzem HTML,
- recenzent uruchamia agenta AI do analizy zmian,
- agent otrzymuje opis zawierający ukryty ładunek instrukcyjny,
- model interpretuje treść jako polecenie i korzysta z dostępnych narzędzi,
- wynik może zostać zapisany w komentarzu, przekazany do innego zasobu lub użyty do dalszych działań.
W opisywanym proof-of-concept agent został nakłoniony do uruchomienia pipeline’u w innym projekcie, odczytu poufnej treści z wiki oraz opublikowania jej w komentarzu pull requestu. To klasyczny przykład nadużycia modelu jako uprzywilejowanego pośrednika, a nie przełamania natywnych mechanizmów autoryzacji platformy.
Powodzenie ataku zależy od kilku warunków:
- możliwości umieszczenia własnej treści w pull requeście,
- workflow, w którym agent analizuje tę treść,
- szerszych uprawnień recenzenta niż autora PR,
- konfiguracji agenta pozwalającej na działania narzędziowe bez dodatkowej akceptacji.
Konsekwencje / ryzyko
Z perspektywy bezpieczeństwa ryzyko jest istotne, ponieważ naruszona zostaje granica zaufania pomiędzy użytkownikiem, agentem AI i treścią pochodzącą z repozytorium. W środowiskach silnie zautomatyzowanych pojedynczy opis PR może stać się nośnikiem poleceń wykonywanych z uprawnieniami ofiary.
- odczyt kodu źródłowego z innych projektów,
- dostęp do wiki, artefaktów i elementów roboczych,
- uruchamianie pipeline’ów poza zakresem danego projektu,
- wyciek poufnych informacji organizacyjnych,
- lateral movement w środowisku DevOps.
Ryzyko rośnie wraz z poziomem autonomii agenta oraz zakresem przyznanych mu uprawnień. Szczególnie niebezpieczne są konfiguracje, w których agent może wykonywać operacje bez jawnego potwierdzenia użytkownika. Dodatkowym problemem jest trudność wykrycia ataku podczas ręcznej recenzji, ponieważ ukryty komentarz nie jest widoczny w standardowym widoku interfejsu.
Rekomendacje
Organizacje korzystające z agentów AI w Azure DevOps powinny potraktować ten przypadek jako sygnał do przeglądu architektury bezpieczeństwa agentowego. Ochrona nie może opierać się wyłącznie na jakości modelu, ale musi obejmować kontrolę wejścia, narzędzi i uprawnień.
- Ograniczenie uprawnień: tokeny agentów powinny mieć minimalny możliwy zakres i być ograniczone do konkretnych projektów oraz zasobów.
- Segmentacja narzędzi: agent recenzujący kod nie powinien mieć dostępu do funkcji, które nie są niezbędne, takich jak uruchamianie pipeline’ów czy odczyt obcych wiki.
- Zatwierdzanie operacji: działania wykraczające poza pasywną analizę powinny wymagać jawnej akceptacji użytkownika.
- Sanityzacja i oznaczanie treści: dane z PR, issue, wiki i logów muszą być konsekwentnie traktowane jako nieufne i wyraźnie separowane od instrukcji dla modelu.
- Detekcja ukrytych komentarzy HTML: warto wdrożyć reguły wykrywające elementy niewidoczne w UI, lecz obecne w danych źródłowych.
- Monitoring działań agentów: należy analizować nietypowe odczyty zasobów, uruchomienia pipeline’ów oraz publikowanie dużych porcji danych w komentarzach.
- Przegląd automatyzacji: workflow działające bez udziału człowieka powinny zostać ocenione pod kątem nadużyć związanych z prompt injection.
Podsumowanie
Luka w Azure DevOps MCP pokazuje, że bezpieczeństwo agentów AI zależy przede wszystkim od prawidłowego rozdzielania nieufnej treści od poleceń sterujących oraz od rygorystycznego ograniczania uprawnień. Nawet niewidoczny dla człowieka komentarz HTML może wystarczyć, aby model wykonał działania zgodne z intencją atakującego.
Dla zespołów DevSecOps kluczowy wniosek jest jednoznaczny: każda treść pochodząca z repozytorium, zgłoszeń i komentarzy powinna być traktowana jako nieufna. W środowiskach, w których agenci AI mają dostęp do narzędzi wykonawczych, zasada najmniejszych uprawnień, pełna obserwowalność działań oraz spójna sanitizacja danych stają się podstawowym warunkiem bezpiecznej automatyzacji.
Źródła
- The Hacker News — https://thehackernews.com/2026/07/microsoft-azure-devops-mcp-flaw-lets.html
- Microsoft Azure DevOps MCP Server (GitHub) — https://github.com/microsoft/azure-devops-mcp
- PR #1062 in microsoft/azure-devops-mcp (GitHub) — https://github.com/microsoft/azure-devops-mcp/pull/1062
- Microsoft Guidance on Indirect Prompt Injection Attacks — https://www.microsoft.com/en-us/msrc/blog/2025/07/how-microsoft-defends-against-indirect-prompt-injection-attacks/
- Manifold Security — Research on Azure DevOps MCP prompt injection issue — https://www.manifold.security/