W skrócie: inżynieria uprzęży agenta i jej ukryta powierzchnia ataku
Inżynieria uprzęży agenta to praktyka polegająca na budowaniu wszystkiego wokół modelu sztucznej inteligencji (instrukcji, narzędzi, uprawnień, pamięci i pętli sprzężenia zwrotnego), co przekształca go w działającego agenta. To właśnie uprząż, a nie model, jest obecnie źródłem największego zagrożenia dla bezpieczeństwa.
- Zmiana: Zespoły przestały dostrajać polecenia i zaczęły projektować uprzęże. Agent = model + uprząż.
- Problem: Uprząż znajduje się w plikach zwykłego tekstu (zasady, umiejętności, konfiguracje MCP), które są przeglądane jak dokumentacja, jeśli w ogóle.
- Dowód: Backdoor w pliku Rules File i prawdziwe luki CVE w MCP pokazują, że atakujący już mają je na celu.
- Poprawka: Potraktuj uprząż jak kod. Zinwentaryzuj ją, sprawdź i zeskanuj przed wysyłką.
Każda rozmowa o bezpieczeństwie sztucznej inteligencji ostatecznie dotyczy modelu. Czy da się go zhakować? Czy będzie miał halucynacje? Czy dostawca trenuje na naszych danych?
Słuszne pytania. Ale coraz częściej są one błędne. Kiedy agent AI usuwa tabelę produkcyjną, wprowadza backdoor lub wysyła listę klientów e-mailem do nieznajomego, model rzadko jest przyczyną awarii. Model robił dokładnie to, na co pozwalały mu jego uprawnienia.
Agent = model + uprząż
W ciągu ostatniego roku branża po cichu zmieniła znaczenie budowania z wykorzystaniem sztucznej inteligencji. Szybka inżynieria ustąpiła miejsca inżynierii kontekstowej, a inżynieria kontekstowa ustąpiła miejsca czemuś większemu: inżynieria uprzęży agenta.
Pomysł jest prosty. Model sam w sobie jest maszyną rozumującą bez rąk. Uprząż to wszystko, co daje mu ręce i pracę: instrukcje, które wykonuje, narzędzia, które może wywołać, uprawnienia, które posiada, pamięć, którą przechowuje, oraz kontrole, które wychwytują jego błędy. Strona Martina Fowlera opisuje inżynierię uprzęży jako pracę, którą obecnie wykonują użytkownicy agentów kodujących, aby uczynić agentów niezawodnymi, i ramy akademickie opublikowane w tym roku dzieli zakres odpowiedzialności na jedenaście, począwszy od dostępu do narzędzi i pamięci projektu, aż po uprawnienia i weryfikację.
Wyniki są realne. Zespoły zajmujące się inżynierią uprzęży agentów donoszą, że zmiana samej uprzęży, przy zachowaniu tego samego modelu pod spodem, może radykalnie zmienić wyniki agenta. To porusza niewygodną kwestię dla każdego, kto zajmuje się bezpieczeństwem: skoro uprząż decyduje o zachowaniu agenta, to uprząż decyduje również o tym, jak można go nadużyć.
Weźmy na przykład coś tak zwyczajnego, jak instalacja zależności. Programista zatrzymuje się, aby sprawdzić nazwę pakietu. Agent z odpowiednim narzędziem po prostu uruchamia polecenie, a jeśli pakiet jest złośliwy, nic w modelu go nie zatrzyma. Właśnie to omawiamy w tym odcinku SafeDev Talks: co się zmienia, gdy agenci AI instalują zależności samodzielnie i dlaczego inżynieria wykorzystania agentów stała się po cichu problemem łańcucha dostaw.
Jak wygląda inżynieria uprzęży agenta w repozytorium
Otwórz repozytorium, w którym programiści korzystają z agentów AI, a narzędzie będzie dostępne od razu, w plikach, których prawdopodobnie nigdy nie skanowałeś:
- Pliki zasad i instrukcji (
AGENTS.md,.cursorrulesInstrukcje drugiego pilota, które informują agenta, jak ma się zachowywać. - Pliki umiejętności pakiet wielokrotnego użytku funkcji, który agent ładuje na żądanie.
- Konfiguracje serwera MCP łączące agenta z narzędziami, bazami danych i interfejsami API.
- Monity systemowe i szablony monitów osadzone w kodzie aplikacji.
- Okablowanie agenta:do jakich narzędzi może dotrzeć agent, jakie dane może pobrać i czy pomiędzy nimi znajduje się bariera ochronna.
Wszystko to jest zwykłym tekstem. Wszystko to jest committed wraz z kodem. I wszystko to jest przeglądane tak, jak przegląda się dokumentację: szybkie spojrzenie, zatwierdzenie, scalenie. Jednak każdy z tych plików może po cichu nadpisać to, co agent ma zrobić i czego może dotknąć.
Oto prawdziwa konsekwencja inżynierii uprzęży agentów: najpotężniejsza konfiguracja w oprogramowaniu jest teraz najmniej sprawdzana.
Atakujący już to zauważyli
To nie jest teoretyczna obawa. Uprząż ma krótką, ale wymowną historię incydentów.
- Tylne wejście do pliku zasad. W marcu 2025 roku badacze ujawnili atak, w którym ukryte znaki Unicode w pliku reguł instruowały asystentów kodowania AI do wstawiania kodu z ukrytymi drzwiami, bez wspominania o tym w widocznej odpowiedzi. Recenzent czytający plik nie zauważył niczego niezwykłego. Obecnie jest on skatalogowany jako Studium przypadku MITRE ATLAS AML.CS0041.
- Zatrute narzędzia MCP. Do 2025 roku badacze wielokrotnie wykazali, że agenci bezwarunkowo ufają opisom narzędzi, więc złośliwy serwer MCP może sterować agentem, po prostu opisując siebie we właściwy sposób. W tym samym roku CVE-2025-6514 w powszechnie pobieranym kliencie MCP umożliwiono zdalne wykonywanie poleceń podczas łączenia się z niezaufanym serwerem, oceniono na 9.6 w serwisie CVSS.
- Nadmierna sprawczość. OWASP Top 10 dla aplikacji LLM Nadmierna sprawczość jest wymieniana jako główne ryzyko: agenci otrzymują więcej narzędzi, uprawnień lub autonomii, niż wymaga zadanie. To nie jest wada modelu. To projekt uprzęży.cisjonowy.
Zwróć uwagę na schemat. Żaden z tych ataków nie niszczy modelu. Niszczą one uprząż, a model wiernie wykonuje resztę.
Dlaczego Twój stos zabezpieczeń tego nie widzi
I tu pojawia się niewygodna część. Większość organizacji korzysta już z dobrych narzędzi AppSec, a prawie żadne z nich nie zostało stworzone dla tej warstwy.
Analiza statyczna rozumie kod, ale nie wie, czym jest model ani dlaczego niezaufany tekst wpływający do monitu systemowego ma znaczenie. Analiza kompozycji inwentaryzuje pakiety, ale nie wylicza serwerów MCP ani plików umiejętności. Skanery sekretów mogą nie zauważyć klucza API znajdującego się w pliku konfiguracyjnym agenta. Żadne z tych narzędzi nie jest wadliwe. Zostały one po prostu stworzone do świata, w którym konfiguracja nie wydaje poleceń.
Inżynieria uprzęży agenta działa szybko, a bezpieczeństwo weryfikuje to, co widzi: model i kod. Uprząż znajduje się pomiędzy.
Pięć nawyków dotyczących zabezpieczania uprzęży
Inżynieria uprzęży agenta zabezpieczającego nie wymaga nowego zespołu. Potrzeba kilku nawyków, które traktują uprząż jako to, czym jest: wykonalną intencją.
| Nawyk | Dlaczego jest to ważne | Co robić: |
|---|---|---|
| 1. Zrób inwentaryzację każdej uprzęży | Nie możesz zabezpieczyć agentów, nikt się nie zgłosił. | Znajdź każdy model, agenta, serwer MCP, umiejętność i monit w swoich repozytoriach, korzystając z kodu i plików konfiguracyjnych, a nie z ankiety. |
| 2. Przejrzyj pliki uprzęży, takie jak kod | Reguły, umiejętności i konfiguracje MCP mogą zmienić sposób działania agenta, mimo to są one przeglądane jak dokumentacja. | Daj im to samo pull request kontrola jako logika aplikacji, w tym sprawdzanie ukrytych znaków. |
| 3. Przypnij to, co ładuje agent | Monit lub model odwołujący się do zmiennej etykiety można zmienić bez konieczności zmiany kodu. | Przypinaj monity i modele do niezmiennych wersji. |
| 4. Zamontuj barierkę ochronną przy każdym zlewie | Pobrane dokumenty, dane wyjściowe narzędzi i treści użytkownika mogą zawierać wstrzykiwane do modelu instrukcje. | Umieść barierkę ochronną na ścieżce wszędzie tam, gdzie zawartość będzie mogła dotrzeć do modelu. |
| 5. Nie ujawniaj danych uwierzytelniających | Klucze dostawcy sztucznej inteligencji w plikach monitowych i konfiguracjach agentów to łatwy cel dla atakującego. | Usuń je i kontynuuj skanowanie plików w poszukiwaniu sekretów. To proste rozwiązanie. |
Zabezpieczenie uprzęży, nie tylko modelu
Bezpieczeństwo sztucznej inteligencji Xygeni Zaczyna się tam, gdzie inżynieria uprzęży agenta pozostawia swój ślad: w Twoich repozytoriach. Odkrywa zasoby sztucznej inteligencji w Twojej bazie kodu (modele, agenci, serwery MCP, umiejętności, monity, guardrails(oraz narzędzia do kodowania sztucznej inteligencji w użyciu) z kodu, zależności i plików konfiguracyjnych pozostawianych przez te narzędzia.
Następnie analizuje pliki umiejętności, pliki reguł i konfiguracje MCP jako artefakty bezpieczeństwa, a nie dokumentację, i wykrywa zagrożenia klasy „wstrzyknięcia promptu” w okablowaniu agenta, takie jak niezaufana zawartość docierająca do promptu systemowego lub ujścia pobierania bez zabezpieczenia. Skanowanie sekretów Xygeni oznacza poświadczenia dostawcy AI w promptach i plikach konfiguracyjnych agenta, a zależności stosu AI są wykrywane w taki sam sposób, jak wszystko inne, zanim powstanie sygnatura.
FAQ
Czym jest inżynieria uprzęży agenta?
Inżynieria uprzęży agenta to dziedzina projektowania środowiska wokół modelu sztucznej inteligencji (instrukcje, narzędzia, uprawnienia, pamięć, kontekst i pętle weryfikacji), tak aby zachowywał się jak niezawodny agent. Model dostarcza wnioskowania; uprząż decyduje, co agent może zobaczyć i wykonać.
Czym inżynieria uprzęży agenta różni się od inżynierii natychmiastowej?
Inżynieria promptów kształtuje pojedynczą instrukcję. Inżynieria uprzęży agenta kształtuje cały system, w którym działa agent, w wielu krokach, narzędziach i sesjach. Prompt to jeden plik w uprzęży.
Dlaczego uprząż stanowi zagrożenie bezpieczeństwa?
Ponieważ kontroluje uprawnienia agenta i jest przechowywany w plikach tekstowych, które rzadko są analizowane jako artefakty bezpieczeństwa. Wystarczy skompromitować plik reguł lub konfigurację MCP, aby kontrolować agenta bez ingerencji w model.
Kto powinien posiadać agenta, który zapewni bezpieczeństwo?
Bezpieczeństwo aplikacji, współpraca z inżynierami, którzy budują i konfigurują agenty. Harmonogram jest częścią oprogramowania, które dostarczasz, więc należy go uwzględnić w tych samych procesach przeglądu, skanowania i inwentaryzacji, co resztę kodu.
