Bezpieczeństwo agentów AI: krytyka MCP i terminala w opracowywaniu

Kryzys bezpieczeństwa agentów AI: dlaczego obecne podejścia prowadzą w ślepą uliczkę

Współczesne agenty AI, zbudowane na gotowych protokołach jak MCP i powłokach shell, wykazują fundamentalne luki w bezpieczeństwie i architekturze. Zamiast tworzyć solidne produkty, branża mnoży „półśrodki”, które nie są gotowe do wydania dla masowego użytkownika. Główne problemy to iluzja bezpieczeństwa przez guardrails, niekontrolowane serwery MCP i niebezpieczna zależność od terminala.

Architektoniczne błędy status quo

Obecne podejście do rozwoju agentów przypomina budowę linii Maginota: kosztowne, ale bezużyteczne zabezpieczenia, które łatwo obejść. Claude Code, mimo popularności wśród deweloperów, to przykład produktu niebezpiecznego dla zwykłych użytkowników. Jego paradygmat pracy z repozytoriami git jako „spadochronem” nie skaluje się na odbiorców bez technicznego tła. Usuwanie krytycznych plików, wycieki danych i niekontrolowane wykonywanie komend – typowe ryzyka.

Główne niedociągnięcia architektoniczne obejmują:

• Terminal jako interfejs: LLM świetnie radzą sobie z tekstem, ale shell to zbyt potężne i niebezpieczne narzędzie. Ograniczenie komend jak rm wymaga skomplikowanej infrastruktury (parsowanie AST, filtrowanie syscall), co słabo skaluje się na tysiące komend i ich kombinacji.
• Protokół MCP: Daje kontrakt na interakcję, ale ignoruje identyfikację, co otwiera wektory ataków tool poisoning (TPA). Atakujący serwer MCP może zaktualizować opis narzędzi, zmuszając LLM do niezauważonego przekazania kluczy lub haseł.
• Guardrails jako iluzja: Próby filtrowania toksyczności, prompt injection lub PII przez regexpy i klasyfikatory przypominają implementację timera w grze przez spadające przezroczyste obiekty – skomplikowanie, nieefektywnie i zostawia dziury.

Dlaczego MCP to ślepa uliczka dla agentów desktopowych

MCP tworzy pięć krytycznych problemów dla produktów ogólnego przeznaczenia:

• Bezpieczeństwo: Protokół nie zapewnia identyfikacji działań, pozwalając LLM na wykonywanie operacji bez wyraźnej zgody użytkownika. Luki tool poisoning czynią system podatnym na ukryte ataki.
• Wydajność: Każdy serwer MCP uruchamia się w oddzielnym procesie. Deweloper agenta nie kontroluje, ile takich procesów uruchomi użytkownik, co może prowadzić do degradacji wydajności maszyny.
• Utrata kontroli: Deweloper nie może zarządzać obcymi serwerami MCP, dopisywać obsługi błędów ani widzieć logów, co wyklucza budowę transparentnego systemu.
• Kolizje narzędzi: Różne serwery MCP mogą nakładać się na siebie funkcjonalnie, dodając narzędzia z tymi samymi nazwami, co prowadzi do nieokreślonego zachowania.
• Wzrost kosztów: Zwiększenie zużycia tokenów na walidację, rozrost bazy kodu i ryzyko wycieków pamięci.

Alternatywne podejście: od ogólnych agentów do wyspecjalizowanych narzędzi

Zamiast tworzyć „uniwersalne agenty” z dostępem do wszystkiego przez MCP, należy rozwijać wyspecjalizowane narzędzia (funkcje) z izolowanym kontekstem. To zmniejsza powierzchnię ataku i poprawia kontrolę.

Kluczowe zasady nowej architektury:

• Interpreter zamiast terminala: Własny interpreter z ograniczonym zestawem komend daje lepszy tradeoff między bezpieczeństwem a możliwościami. Na przykład, narzędzia na ls i rm można zrealizować z różnymi poziomami potwierdzenia (callback dla rm, bez potwierdzenia dla ls).
• Sandbox wokół interpretera, nie agenta: Izolacja powinna być stosowana do środowiska wykonania narzędzi, a nie do agenta jako całości. Pozwala to bezpiecznie wykonywać kod bez radykalnego ograniczania funkcjonalności.
• Transparentność dla dewelopera: Agent powinien zapewniać pełne logi, śledzenie wywołań i możliwość debugowania, eliminując czarne skrzynki jak serwery MCP.
• Testy End-to-End: Prompty i modele się zmieniają, ale testy na krytyczne scenariusze (np. „nie usuwaj plików systemowych”) muszą pozostać stabilne.

Co ważne

• Obecne agenty AI na bazie MCP i terminala nie są bezpieczne do wydania masowym użytkownikom.
• Rozwiązania architektoniczne jak guardrails na regexpach tworzą iluzję ochrony, ale łatwo je obejść.
• Wyspecjalizowane narzędzia z izolacją są preferowane ponad uniwersalne serwery MCP.
• Bezpieczeństwo powinno być wbudowane na poziomie interpretera i sandboxu, a nie przez nakładane filtry.
• Deweloperzy potrzebują pełnej transparentności i kontroli nad wykonywaniem narzędzi do debugowania i audytu.

Implementacja bezpiecznego agenta: praktyczne kroki

• Rezygnacja z powłoki shell: Zamień terminal na interpreter z ograniczonym API. Zdefiniuj zestaw bezpiecznych komend i zrealizuj je jako narzędzia z wyraźnymi kontraktami.
• Izolacja przez sandbox: Użyj konteneryzacji lub wirtualizacji do uruchomienia interpretera w izolowanym środowisku. Zapobiegnie to niepożądanemu dostępowi do systemu plików lub sieci.
• Wprowadzenie testów End-to-End: Stwórz testy na krytyczne scenariusze (np. przetwarzanie danych użytkownika, wykonywanie destrukcyjnych operacji). Automatyzuj je w CI/CD.
• Logowanie i śledzenie: Zaimplementuj system logów, który zapisuje wszystkie wywołania narzędzi, prompty i odpowiedzi LLM. Jest to konieczne do audytu i debugowania incydentów.
• Specjalizacja narzędzi: Zamiast podłączać zewnętrzne serwery MCP, rozwijaj narzędzia pod konkretne zadania (praca z plikami, API, bazami danych). Zmniejszy to ryzyko kolizji i wycieków.

Kategoryczny imperatyw rozwoju agentów

Twórz agenty, których nie boisz się wydać. Oznacza to:

• Niezawodność i bezpieczeństwo na poziomie tradycyjnych aplikacji.
• Brak konieczności ustawiania Dockera, otwierania terminala lub konfiguracji MCP przez użytkownika.
• Oszczędność tokenów – proste operacje nie powinny kosztować setek złotych.
• Transparentność działania dla dewelopera i możliwość szybkiego reagowania na incydenty.

Tylko takie podejście pozwoli wyjść poza niszowe narzędzia dla deweloperów i stworzyć produkty dla globalnej audiencji.

— Editorial Team