Wprowadzenie do problemu / definicja
Amazon Kiro to środowisko IDE wspierane przez sztuczną inteligencję, zaprojektowane z myślą o pracy agentowej nad kodem i zadaniami programistycznymi. Najnowsze ustalenia badaczy bezpieczeństwa pokazują jednak, że w określonych wersjach narzędzia możliwe było wykorzystanie techniki prompt injection do manipulowania zachowaniem agenta i doprowadzenia do nieautoryzowanej transmisji danych lokalnych poza środowisko użytkownika.
Problem dotyczy granic zaufania pomiędzy zawartością repozytorium, konfiguracją IDE oraz mechanizmami automatyzacji udostępnianymi przez Kiro Powers. W praktyce oznacza to, że treść projektu mogła zostać potraktowana jako instrukcja operacyjna, a następnie wykorzystana do wywołania działań prowadzących do wycieku informacji.
W skrócie
- Badacze ujawnili podatność w Amazon Kiro pozwalającą na pośredni prompt injection.
- Atak mógł prowadzić do odczytu lokalnych danych i ich przesłania do zewnętrznego endpointu.
- Scenariusz dotyczył m.in. Kiro IDE 0.7.45 dla Windows.
- Poprawka została wdrożona w wersji 0.8.140.
- Wektor ataku wykorzystywał elementy Kiro Powers, takie jak steering files, konfiguracje MCP i hooki.
Kontekst / historia
Opisana słabość wpisuje się w rosnącą kategorię zagrożeń dotyczących agentowych narzędzi AI dla programistów. W takich rozwiązaniach model językowy nie ogranicza się do generowania odpowiedzi tekstowych, ale korzysta również z narzędzi lokalnych, analizuje konfigurację projektu, modyfikuje pliki i uruchamia określone procesy w aplikacji gospodarza.
Taki model działania zwiększa produktywność zespołów deweloperskich, ale jednocześnie komplikuje kwestie bezpieczeństwa. Każdy element projektu może bowiem pełnić podwójną rolę: zwykłego kontekstu roboczego oraz nośnika instrukcji wpływających na decyzje agenta. W przypadku Kiro problem nie sprowadzał się do pojedynczego pliku, lecz do całego łańcucha przetwarzania — od zawartości repozytorium kontrolowanej przez atakującego po realne działania wykonywane przez IDE.
Sprawa jest o tyle istotna, że wcześniej analizowano już scenariusze, w których instrukcje zapisane w plikach sterujących mogły wpływać na zachowanie systemów AI. Najnowsze ustalenia rozszerzają ten obraz, pokazując bardziej praktyczny i bezpośredni mechanizm eksfiltracji danych z udziałem funkcji wykonawczych zintegrowanych z narzędziem programistycznym.
Analiza techniczna
Sednem podatności był błąd w egzekwowaniu granicy zaufania pomiędzy treścią projektu a operacjami wrażliwymi z perspektywy bezpieczeństwa. Atakujący mógł przygotować złośliwy projekt w taki sposób, aby osadzone w nim instrukcje zostały uznane przez agenta za wiarygodne wskazówki operacyjne. Kluczową rolę odgrywały tu komponenty Kiro Powers, obejmujące konfiguracje serwerów Model Context Protocol, pliki steering, hooki oraz wiedzę kontekstową.
W praktyce scenariusz ataku wymagał spełnienia dwóch warunków. Po pierwsze, ofiara musiała otworzyć projekt przy użyciu pliku workspace, a nie samego katalogu. Po drugie, użytkownik musiał wysłać dowolną wiadomość do agenta. Co ważne, komunikat nie musiał zawierać niczego złośliwego — samo aktywowanie agenta po załadowaniu spreparowanego workspace mogło uruchomić podatny przepływ.
Łańcuch nadużycia można opisać w kilku krokach:
- atakujący umieszcza złośliwe instrukcje w kontrolowanej zawartości projektu,
- agent interpretuje je jako użyteczne polecenia lub kontekst działania,
- narzędzie uzyskuje dostęp do lokalnych danych dostępnych w obszarze roboczym lub kontekście użytkownika,
- pozyskane informacje zostają zapisane albo wplecione w konfigurację istotną operacyjnie,
- kolejne funkcje IDE lub komponenty Kiro Powers powodują wygenerowanie ruchu sieciowego prowadzącego do wycieku danych.
Z perspektywy bezpieczeństwa AI jest to klasyczny przykład pośredniego prompt injection. Model nie zostaje zmanipulowany przez prompt wpisany ręcznie przez użytkownika, lecz przez treść dostarczoną innym kanałem — w tym przypadku przez elementy projektu i konfiguracji. To szczególnie niebezpieczne w środowiskach agentowych, gdzie model może inicjować działania uboczne wykraczające poza generowanie tekstu.
Warto też zwrócić uwagę na niski próg eksploatacji. Użytkownicy często otwierają obce repozytoria, proof-of-concepty, dema i przykładowe projekty pobrane z Internetu. W takim kontekście użycie przygotowanego pliku workspace może nie wzbudzić podejrzeń, mimo że uruchamia niebezpieczny łańcuch zdarzeń.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności była możliwość eksfiltracji lokalnych danych z komputera dewelopera. Mogły to być fragmenty kodu źródłowego, dane konfiguracyjne, sekrety projektowe, tokeny, klucze API, pliki robocze lub inne informacje dostępne agentowi podczas sesji.
Skala ryzyka zależy od zakresu uprawnień przyznanych narzędziu, charakteru otwartego projektu oraz dostępu do zasobów lokalnych i sieciowych. Dla organizacji zagrożenie staje się szczególnie istotne wtedy, gdy środowiska deweloperskie mają dostęp do sekretów CI/CD, systemów produkcyjnych albo wewnętrznych repozytoriów zawierających dane wrażliwe.
- Ryzyko rośnie, gdy deweloperzy regularnie otwierają projekty z zewnętrznych źródeł.
- Zagrożenie zwiększa się, gdy narzędzia AI mają szerokie uprawnienia do plików i konfiguracji.
- Brak kontroli ruchu wychodzącego z IDE ułatwia niezauważoną eksfiltrację.
- Zbyt liberalna polityka zaufania do workspace i rozszerzeń tworzy dodatkową powierzchnię ataku.
Incydent pokazuje również szerszy problem w ekosystemie AI-assisted development. Gdy interpretacja kontekstu łączy się z wykonaniem działań, praktycznie każdy artefakt projektu może stać się nośnikiem złośliwych instrukcji. To oznacza, że klasyczne skanowanie kodu i zależności może nie wystarczać do wykrywania tego typu zagrożeń.
Rekomendacje
Organizacje korzystające z agentowych narzędzi AI powinny traktować repozytoria, pliki workspace, steering files oraz konfiguracje MCP jako potencjalnie nieufne dane wejściowe. W praktyce warto wdrożyć zarówno szybkie działania naprawcze, jak i długofalowe zmiany w politykach bezpieczeństwa.
- Niezwłocznie zaktualizować Amazon Kiro do wersji zawierającej poprawkę lub nowszej.
- Ograniczyć otwieranie projektów z niezweryfikowanych źródeł, szczególnie przez pliki workspace.
- Wdrożyć politykę bezpiecznego użycia agentów AI w środowiskach deweloperskich.
- Monitorować i filtrować ruch wychodzący z narzędzi programistycznych.
- Minimalizować dostęp narzędzi AI do sekretów, danych lokalnych i wrażliwych katalogów.
- Oddzielać środowiska testowe od stacji roboczych mających dostęp do zasobów produkcyjnych.
- Przeglądać pliki steering, hooki i konfiguracje MCP przed otwarciem projektu.
- Stosować rozwiązania EDR i DLP zdolne wykrywać nietypowe odczyty plików oraz połączenia sieciowe inicjowane przez IDE.
- Szkolić deweloperów z zakresu prompt injection, indirect prompt injection i zagrożeń specyficznych dla agentów AI.
Z perspektywy producentów podobnych narzędzi kluczowe jest silniejsze rozdzielanie kontekstu modelu od operacji wykonawczych. Obejmuje to twarde granice zaufania, jawne potwierdzanie działań wrażliwych, izolację konfiguracji bezpieczeństwa od treści repozytorium oraz precyzyjne polityki dostępu do narzędzi i połączeń sieciowych.
Podsumowanie
Przypadek Amazon Kiro pokazuje, że bezpieczeństwo agentowych środowisk IDE nie może być oceniane wyłącznie przez pryzmat klasycznych podatności aplikacyjnych. Wraz ze wzrostem autonomii narzędzi AI rośnie znaczenie subtelnych błędów projektowych związanych z granicami zaufania, interpretacją kontekstu i integracją z lokalnym środowiskiem pracy.
Opisana luka umożliwiała eksfiltrację danych bez potrzeby dostarczania jawnie złośliwego promptu przez użytkownika. Dla zespołów bezpieczeństwa i deweloperów to wyraźny sygnał, że repozytorium obsługiwane przez agenta AI należy traktować jak aktywną powierzchnię ataku, a nie jedynie bierne źródło kodu.
Źródła
- https://thehackernews.com/2026/08/amazon-kiro-prompt-injection-can.html
- https://kiro.dev
- https://mindgard.ai