Dział Endpoint Detection and Response przez dwie dekady dobrze odpowiadał na jedno pytanie: czy proces ten wykonuje coś, co zrobiłby złośliwy kod? Sprawdza podpisy, obserwuje nietypowe zachowania i sygnalizuje nieautoryzowaną eskalację uprawnień. Agent sztucznej inteligencji posiadający dostęp do narzędzi łamie założenie tej kwestii nie dlatego, że jest złośliwym kodem, ale zaufanym programem, którego można nakłonić do niewłaściwego wykorzystania własnego, całkowicie legalnego dostępu.
Wersja tego problemu sprzed AI ma już nazwę
Używanie legalnego, podpisanego programu do zrobienia czegoś złośliwego nie jest niczym nowym. MITER ATT&CK kataloguje to jako Wykonywanie binarnego serwera proxy systemu (T1218): „pliki binarne podpisane zaufanymi certyfikatami cyfrowymi zazwyczaj można uruchamiać w systemach Windows chronionych przez weryfikację podpisu cyfrowego” i właśnie dlatego umieszczanie na liście dozwolonych i sprawdzanie podpisów mają trudności, gdy to zaufany plik binarny sam w sobie odgrywa rolę. Agent AI rozszerza tę samą słabość na program, który w ogóle nie musi być wstępnie ładowany złośliwym kodem: może zostać przekierowany w czasie wykonywania, za pomocą przeczytanego tekstu.
Porwany agent to zdezorientowany zastępca
Stosowanym tutaj terminem jest zdezorientowany problem zastępcy: „program komputerowy, który inny program (z mniejszymi uprawnieniami lub mniejszymi prawami) oszukał w celu niewłaściwego wykorzystania swoich uprawnień”. Daj agentowi prawdziwe narzędzia, a następnie pozwól mu przeczytać treści, których nie sprawdziłeś, i może na ich podstawie poinstruować. To jest dokładnie wzorzec Wpis Prompt Injection OWASP opisany i został już zademonstrowany, a nie tylko teoria: Raport z 26 maja 2025 r firmy Invariant Labs pokazało agenta kodującego, czytającego zwyczajnie wyglądający problem z GitHubem w publicznym repozytorium, postępując zgodnie z zawartymi w nim ukrytymi instrukcjami w celu ujawnienia danych z prywatnego repozytorium, używając narzędzi, które zostały mu legalnie przyznane. Wniosek badaczy: „nie jest to błąd w samym kodzie serwera MCP GitHub, ale raczej podstawowy problem architektoniczny, który należy rozwiązać na poziomie systemu agenta”.
process: python3 agent_worker.py --tool-socket 8443
user: developer (normal UID, no privilege escalation)
network: HTTPS POST to a domain the process has contacted before
signature: none matched, no known-bad hash
behaviour: consistent with routine developer tooling
# The same log line is produced whether agent_worker.py just fetched
# documentation the developer asked for, or was redirected by injected
# instructions to read a private file and POST it out.To jest właściwie martwy punkt: nie jest to luka w żadnym pojedynczym produkcie, ale fakt, że wpis w dzienniku „agent wykonał swoją normalną pracę” i „agent został porwany w celu niewłaściwego wykorzystania swojej normalnej pracy” może być identyczny na poziomie procesu. Nic w systemie binarnym się nie zmieniło. Nic we wzorcu wywołań systemowych nie jest nowe. Zmieniła się jedynie intencja stojąca za żądaniem, a intencja nie jest polem w dzienniku procesu.
Co faktycznie to zmniejsza, a co nie
Warto być precyzyjnym, co tak naprawdę poleca osoba, która nazwała ten wzór. Simon Willison, który opisał „zabójcza trifecta” dostępu do prywatnych danych, ujawniania niezaufanych treści i komunikacji zewnętrznej w jednym agencie, wyraźnie stwierdza, że unikanie tej kombinacji to prawdziwe rozwiązanie, a nie dodatkowa poręcz: „Jedynym sposobem na zachowanie bezpieczeństwa jest całkowite uniknięcie tej śmiercionośnej kombinacji trifecta”. Jest otwarcie sceptyczny wobec produktów, które twierdzą, że po fakcie niezawodnie wychwytują wprowadzone instrukcje, zauważając, że „nadal nie wiemy, jak w 100% niezawodnie temu zapobiec” oraz że 95-procentowy wskaźnik wychwytywania to „w dużym stopniu niedostateczna ocena” w przypadku kontroli bezpieczeństwa.
- Najpierw zaprojektuj: zapewnij agentowi najwęższe narzędzia i dostęp do danych, jakich potrzebuje, aby udany zastrzyk miał mniej możliwości nadużyć (poprawka architektoniczna, na którą wskazują zarówno Willison, jak i Invariant Labs).
- Treść przeczytaną przez agenta, której nie napisałeś ani nie sprawdziłeś, problemy, pobrane strony, pobrane pliki, w zasadzie za każdym razem, traktuj jako niezaufane dane wejściowe.
- Tam, gdzie projekt i przegląd nie wystarczą, jedynym krokiem, którego nie można pominąć przy próbie eksfiltracji danych, jest przerwanie połączenia sieciowego. Obserwowanie lub ograniczanie tego w każdym procesie nie chroni agenta przed oszukaniem, ale jest to rzeczywista, niezależna warstwa, która nie zależy w pierwszej kolejności od rozpoznania wstrzykniętej instrukcji.
Jaką rolę odgrywają FireAI i HisnLabs
No firewall makes a hijacked agent safe on its own, but the data it tries to send out still has to leave through a socket, and that is the one step FireAI watches regardless of which trusted binary the agent is running inside of.
FireAI to własny produkt HisnLabs: zapora sieciowa z AI działająca bezpośrednio na Macu. Pokazuje prostym językiem każde połączenie nawiązywane przez twoje aplikacje i pozwala ci decydować, co opuszcza twojego Maca — jej AI działa lokalnie, więc twój ruch nigdy nie jest wysyłany do nas ani do nikogo innego. Zespół badań nad bezpieczeństwem HisnLabs dba o to, by te decyzje pozostały trafne: kataloguje, które domeny to zwykła telemetria, a które prawdziwa usługa, śledzi kraj i sieć stojące za połączeniem oraz trenuje lokalny model (funkcję Autopilot) na rzeczywistych wzorcach ruchu — a nic z tego nie opuszcza twojego Maca.
Możesz przeczytać o decyzjach technicznych, które za tym stoją, albo wypróbować FireAI przez 17 dni na FireAI od HisnLabs.