Lead
Firmy coraz częściej pozwalają agentom AI (Copilot, Claude Code) samodzielnie przeglądać kod, pull requesty i dokumentację — bez świadomości, że jedno ukryte polecenie w opisie PR może zamienić agenta w narzędzie wycieku danych. Sprawdź, jak Audyt Podatności CHORS.NET wykrywa tego typu ryzyka, zanim zrobi to atakujący.
Co się właściwie stało: luka w Azure DevOps MCP
Francisco Rosales z Manifold Security opisał 21 lipca 2026 podatność typu „confused deputy" w oficjalnym serwerze Model Context Protocol (MCP) dla Azure DevOps od Microsoft. Atakujący z dostępem współautora do jednego projektu może wstawić niewidoczne instrukcje w opisie pull requesta — ukryte w komentarzu HTML, niewidoczne w interfejsie, ale w pełni czytelne dla API i agenta AI.
Gdy ofiara — zwykle senior developer z szerszym dostępem — poprosi swojego agenta AI o przegląd PR, ukryte instrukcje przejmują kontrolę nad jego działaniem. W dowodzie koncepcji zweryfikowanym na Copilot CLI i Claude Code, przejęty agent uruchomił pipeline w innym projekcie, odczytał poufną stronę wiki, do której atakujący nie miał dostępu, i opublikował jej treść jako komentarz na PR atakującego.
Dlaczego to nie jest problem tylko dla programistów
To scenariusz, który pokazuje, że bezpieczeństwo AI agentów nie jest już domeną wyłącznie działów IT — dotyczy każdej firmy korzystającej z automatyzacji opartej na dużych modelach językowych. Luka wynika z niekonsekwentnego zastosowania mechanizmu obronnego („spotlighting") tylko do części narzędzi MCP, co tworzy furtkę, którą można wykorzystać bez wykrycia.
Mechanizm „confused deputy" w praktyce
Atak wykorzystuje zasadę tzw. „lethal trifecta" opisaną przez badacza Simona Willisona: dostęp do prywatnych danych, ekspozycja na niezaufaną treść i możliwość eksfiltracji informacji. Gdy te trzy elementy występują razem w jednym workflow agentowym, ryzyko przejęcia kontroli nad agentem rośnie niezależnie od tego, jak dobrze zabezpieczony jest sam kod.
Reakcja Microsoftu i brak systemowego rozwiązania
Microsoft potwierdził problem po zgłoszeniu przez Manifold Security, uznając go za znaną klasę ryzyka związanego z AI, jednak według badaczy nie wydał poprawki ani nie przypisał numeru CVE na dzień publikacji. Firma rekomenduje ograniczanie zakresów dostępu do projektów i manualną weryfikację zmian przed pozwoleniem agentom AI na działanie — co w praktyce oznacza, że odpowiedzialność za wykrycie ryzyka spada na same organizacje.
Szerszy trend: agentowe workflow'y jako nowy wektor ataku
Podobną architektoniczną wadę opisali w maju 2025 badacze Invariant Labs w serwerze MCP GitHuba, gdzie złośliwa treść w zgłoszeniach (issues) mogła prowadzić do wycieku kodu z prywatnych repozytoriów. Rosales ostrzega, że ryzyko rośnie wraz ze skalowaniem automatyzacji: przeglądy PR, triage i podsumowania uruchamiane automatycznie bez udziału człowieka oznaczają, że wstrzyknięty opis PR nie czeka na zapytanie — sam staje się punktem wejścia.
„W tym świecie wstrzyknięty opis PR nie czeka, aż ktoś zapyta — to punkt wejścia, który uruchamia się sam."
— Francisco Rosales, Manifold Security
Perspektywa eksperta CHORS.NET
Jak zauważa Marcin Białczyk, operator systemów AI i założyciel CHORS.NET, z własnej praktyki wdrażania agentów takich jak Hermes czy Agent Zero:
„Każdy nowy agent podłączony do firmowych systemów to nowy punkt ekspozycji, który trzeba przetestować, a nie zakładać, że producent to zrobił za nas."
— Inżynier Marcin Białczyk, Founder i Cybersecurity Operator, CHORS.NET
Jak sprawdzić, czy Twoja firma jest narażona
- Zidentyfikuj wszystkie miejsca, w których agenci AI (Copilot, Claude Code, własne MCP) mają dostęp do treści generowanych przez użytkowników zewnętrznych, takich jak opisy PR, zgłoszenia czy komentarze.
- Sprawdź, czy dostawca narzędzia stosuje mechanizmy typu spotlighting konsekwentnie we wszystkich endpointach, nie tylko w wybranych.
- Ogranicz zakres dostępu agentów do zasad least privilege — jeden projekt, jeden zakres uprawnień.
- Zweryfikuj, czy automatyczne triggery (przeglądy PR, triage) mają wgląd w logi działań agenta, umożliwiający wykrycie nietypowego zachowania.
- Zamów Audyt Podatności, który obejmuje ocenę ekspozycji na ryzyka związane z integracjami AI i automatyzacją.
Najczęściej zadawane pytania
Czy ta podatność dotyczy tylko Azure DevOps?
Nie. Mechanizm „confused deputy" i „lethal trifecta" to wzorzec architektoniczny, który wystąpił już w serwerze MCP GitHuba i może dotyczyć każdego narzędzia łączącego agentów AI z niezaufaną treścią zewnętrzną.
Czy moja firma jest narażona, jeśli nie używamy Azure DevOps?
Jeśli korzystasz z jakichkolwiek agentów AI podłączonych do systemów zarządzania kodem, wiki czy ticketów (np. przez MCP, Copilot, Claude Code), ryzyko dotyczy Ciebie niezależnie od konkretnego dostawcy — kluczowe jest, jak skonfigurowane są uprawnienia i filtrowanie treści.
Jak CHORS.NET pomaga w ocenie tego typu ryzyka?
Audyt Podatności CHORS.NET obejmuje analizę konfiguracji integracji, w tym punktów ekspozycji związanych z automatyzacją i AI, oraz dostarcza raport w języku biznesowym z konkretnymi rekomendacjami naprawczymi w 3-7 dni.
Czy wystarczy jednorazowy audyt, czy potrzebuję stałego monitoringu?
Ponieważ narzędzia AI i ich integracje zmieniają się szybko, jednorazowy Audyt Podatności to dobry punkt startowy, ale przy aktywnym korzystaniu z agentów AI w firmowych workflow'ach warto rozważyć Continuous Monitoring dla bieżącej weryfikacji.
Sprawdź ekspozycję swojej firmy już teraz
Nie czekaj, aż ukryta instrukcja w PR lub zgłoszeniu wykorzysta Twojego agenta AI przeciwko Tobie. Zamów Audyt Podatności CHORS.NET i sprawdź, gdzie Twoja firma jest realnie narażona.