AWS blokuje dzikie agenty AI. Firewall dla AgentCore

AWS opublikował instrukcję konfiguracji Network Firewall, która pozwala zablokować agentom AI w usłudze AgentCore dostęp do wszystkich domen poza wcześniej zatwierdzoną listą allowlist.

SNI jako bramkarz dla agentów

Mechanizm działa na poziomie inspekcji SNI (Server Name Indication) — fragmentu nagłówka TLS, który agent wysyła jeszcze przed szyfrowaniem połączenia. AWS Network Firewall odczytuje tę informację i decyduje, czy przepuścić ruch, czy go zablokować. Nie trzeba deszyfrować całej sesji. To szybkie i stosunkowo tanie obliczeniowo.

Dzięki temu administrator definiuje listę dozwolonych domen — np. api.openai.com, własne endpointy czy zatwierdzone źródła danych — i agent po prostu nie ma jak trafić nigdzie indziej. Próba połączenia z nieznaną domeną kończy się ciszą.

Dlaczego AgentCore w ogóle potrzebuje smyczy?

Agenci AI działają autonomicznie. Dostają cel, a nie instrukcję krok po kroku. W praktyce oznacza to, że agent może samodzielnie odpalić zapytanie do dowolnego URL-a — czy to szukając danych, czy wykonując narzędzia (tool calls). Bez ograniczeń sieciowych agent działający w firmowej infrastrukturze mógłby:

• wysłać dane do zewnętrznego serwera kontrolowanego przez atakującego (exfiltration),
• pobrać złośliwy payload z internetu,
• uderzyć w API, za które firma płaci per-request, generując nieplanowane koszty,
• zostać zmanipulowany przez prompt injection z zewnętrznej strony.

Kontrolowanie domen na poziomie sieci to obrona niezależna od logiki agenta — nawet jeśli model „zdecyduje” nawiązać podejrzane połączenie, firewall po prostu je zerwie.

AWS traktuje to jako warstwę pierwszą, nie jedyną

AWS wprost zaznacza, że filtrowanie domen przez SNI to tylko pierwsza warstwa defense-in-depth. Co to oznacza w praktyce? Że sama lista dozwolonych domen nie wystarczy, jeśli atakujący kontroluje domenę znajdującą się na allowlist, albo jeśli agent zostanie skłoniony do nadużycia uprawnień w ramach dozwolonego serwisu.

Kolejne warstwy to m.in. IAM z zasadą least privilege, monitorowanie logów CloudTrail, szyfrowanie danych w ruchu i w spoczynku oraz izolacja środowisk przez VPC. AWS nie opisuje ich szczegółowo w tym poście — zapowiada kolejne materiały.

Czy to rozwiązuje problem zaufania do agentów?

Nie do końca. Allowlistowanie domen rozwiązuje konkretny, wąski problem: niekontrolowany dostęp sieciowy. Nie odpowiada na pytanie, co agent robi z danymi już po ich pobraniu z dozwolonej domeny. Jeśli agent ma dostęp do S3 i bazy danych RDS, a jednocześnie może komunikować się z zewnętrznym LLM-em na allowliście — zakres możliwych nadużyć wciąż jest szeroki.

Firmy wdrażające agentów w środowiskach produkcyjnych muszą osobno definiować uprawnienia IAM dla każdego agenta, audytować jakie narzędzia ma do dyspozycji oraz stosować guardrails na poziomie samego modelu. Firewall to higiena sieci, nie kompleksowa polityka bezpieczeństwa agentów.

Konfiguracja nie jest trywialna

AWS Network Firewall to usługa zarządzana, ale jej konfiguracja wymaga znajomości Suricata rule groups (format reguł używany przez tę usługę) oraz architektury VPC z odpowiednim routingiem przez endpoint firewalla. Nie jest to kliknięcie w przycisk w konsoli — trzeba zaplanować topologię sieci tak, żeby cały ruch wychodzący z AgentCore przechodził przez firewall, zanim trafi do internetu.

Cena Network Firewall zaczyna się od 0,395 USD za godzinę działania endpointu plus 0,065 USD za każdy przetworzony gigabajt — przy intensywnym użyciu agentów koszty mogą szybko urodzić niespodziankę w rachunku.

AWS nie podał, kiedy AgentCore osiągnie ogólną dostępność (GA) — usługa wciąż jest w fazie preview.”, “coverImageAlt”: “Ilustracja przedstawiająca agenta AI za kratami zapory sieciowej z ikonami domen