Przejdź do głównej treści
Agent, który może sięgnąć do sieci, może stać się rurą danych. Atakujący sadzi instrukcje w dokumencie, który agent czyta — stronie internetowej, pobranym fragmencie, wyniku narzędzia — a te instrukcje kierują agenta, aby POSTował wrażliwe dane do hosta kontrolowanego przez atakującego lub sondował wewnętrzne usługi (SSRF). Agent nigdy nie „decyduje” o eksfiltracji; wykonuje to, co wygląda dla niego jak legalna instrukcja. Ta strona omawia, jak Agent Firewall i Guardrails w OrcaRouter pozwalają ci bronić się przed eksfiltrацją danych AI — bez zmiany kodu agenta.
Firewall widzi egress tylko dla miejsc docelowych kierowanych przez bramę przez ścieżkę dyspozycji MCP lub hook evaluate. Narzędzie, które twój agent wykonuje całkowicie wewnątrz własnego procesu, jest poza jego widokiem. Kieruj wywołania narzędzi sieciowych swojego agenta przez bramę, a będą zarządzane.

​
1. Jak działa atak

Kanonalna ścieżka przez agenta przebiega w trzech krokach:
  1. Injection — agent odczytuje niezaufaną treść niosącą osadzone instrukcje (stronę internetową, pobrany dokument, notatkę CRM).
  2. Zbieranie — wstrzyknięte instrukcje mówią agentowi, aby zebrał wrażliwy materiał — klucze API, wiersze bazy danych, PII użytkownika — używając narzędzi, które już posiada.
  3. Eksfiltracja — agentowi mówi się, aby wysłał ten materiał przez narzędzie w kształcie fetch: http_fetch, web_search, fetch_url lub request. Miejsce docelowe jest kontrolowane przez atakującego.
SSRF ma ten sam kształt skierowany wewnętrznie: zamiast zewnętrznego hosta agent jest kierowany ku 169.254.169.254 (metadane chmury), wewnętrznemu portowi Redis lub innej prywatnej usłudze. Zobacz Prompt injection dla kroku injection; ta strona skupia się na kroku sieciowym.

​
2. Lista dozwolonych egress — blokuj zewnętrzne miejsca docelowe

Najbardziej trwałą obroną jest lista dozwolonych egress: wylistuj hosty, do których twoje agenty mogą legalnie sięgnąć, i odmów wszystkiemu innemu. Reguła egress używa stage: egress i pola egress. Werdykt kontroluje polarność — allow przepuszcza wylistowane miejsca docelowe; catch-all deny o niższym priorytecie blokuje resztę: 
[
  {
    "priority": 10,
    "label": "Allow known API endpoints",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "allow",
    "egress": {
      "allow": [
        "api.openai.com",
        "api.anthropic.com",
        "api.orcarouter.ai"
      ]
    }
  },
  {
    "priority": 20,
    "label": "Deny all other outbound destinations",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
Wpisy pasują jako CIDR, dosłowny IP lub hostname bez rozróżniania wielkości liter. Hostnamy są rozwiązywane w najlepszym wysiłku i ponownie sprawdzane wobec wpisów IP/CIDR, więc miejsce docelowe jak 169.254.169.254 zwrócone przez DNS jest nadal wychwytywane przez wpis deny CIDR 10.0.0.0/8. Zablokowane wywołanie zwraca HTTP 400 z kodem błędu firewall_blocked. Aby odmówić znanych złych zakresów bez jawnej listy dozwolonych, napisz ukierunkowaną regułę deny egress wylistowując endpoint metadanych chmury (169.254.169.254) i prywatne zakresy RFC-1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Warstwuj swoją listę dozwolonych na wierzchu przy niższym numerze priorytetu, aby reguły deny były ewaluowane pierwsze.

​
3. Blokuj narzędzia w kształcie fetch na warstwie nazwy

Zanim zewnętrzne miejsce docelowe zostanie w ogóle ewaluowane, możesz usunąć zdolność całkowicie. Poziom autonomii tight odmawia http_fetch, web_search, fetch_url i request globem nazwy narzędzia jako zabezpieczenie SSRF i eksfiltracji. Jeśli twój agent nie potrzebuje żadnego z tych narzędzi, tight usuwa powierzchnię ataku w jednym kroku: 
POST /api/workspace/firewall/autonomy
{ "level": "tight" }
Aby odmówić narzędziom fetch bez przyjmowania pełnej postawy tight, napisz regułę deny na powierzchni inbound. inbound blokuje narzędzie zanim model może je wybrać — agent nigdy nie otrzymuje zdolności w swojej liście narzędzi: 
{
  "priority": 5,
  "label": "Deny fetch-shaped tools",
  "stage": "inbound",
  "tool_name_glob": "http_fetch",
  "verdict": "deny"
}
Powtórz dla każdej nazwy narzędzia w kształcie fetch, którego używa twój stos agenta.

​
4. Guardrail Secrets Blocker — zatrzymaj poświadczenia na poziomie promptu

Guardrail Secrets Blocker działa na etapie wejściowym, skanując prompt pod kątem kluczy dostępu w stylu AWS, kluczy OpenAI, kluczy Anthropic, tokenów GitHub i podobnych wzorców poświadczeń, zanim żądanie opuści bramę. Jeśli sekret zostanie wykryty, żądanie jest blokowane — poświadczenie nigdy nie dociera do modelu i nigdy nie pojawia się w wywołaniu narzędzia. Włącz go z panelu Guardrails lub jako część poziomu autonomii tight. Jest niezależny od reguł egress firewalla.
ZagrożenieWarstwa, która je zatrzymuje
Prompt niesie klucz APISecrets Blocker (guardrail wejściowy)
Agent wywołuje narzędzie fetch w kierunku hosta atakującegoReguła allow/deny egress
Narzędzie w kształcie fetch ogłoszone modelowiReguła deny inbound lub autonomia tight
Agent sięga do metadanych chmury lub RFC-1918Reguła deny egress wylistowująca te CIDR

​
5. Wdrażaj z trybem cienia

Jeśli nie jesteś pewien, do jakich hostów twój agent legalnie dociera dziś, zacznij w trybie cienia przed egzekwowaniem:
  1. Utwórz reguły egress z zamierzoną listą dozwolonych i ustaw shadow_mode: true na polityce.
  2. Obserwuj strumień Events — wywołania, które by zostały zablokowane, pojawiają się jako [shadow] would deny z miejscem docelowym.
  3. Dostosuj listę allow, aż tylko miejsca docelowe osiągalne przez atakującego zostałyby odmówione, a potem wyłącz tryb cienia, aby zacząć egzekwować.
Żaden ruch nie jest blokowany, gdy tryb cienia jest włączony.

​
6. Co dalej

Referencja reguł firewalla

Kompletny język dopasowania — listy egress, CIDR, klauzule argumentów i wszystkie werdykty.

Przegląd Agent Firewalla

Polityki, powierzchnie, poziomy autonomii i obserwowalność.

Prompt injection

Krok injection, który kieruje agenty ku eksfiltracji.

Zatrucie narzędzi MCP

Złośliwe narzędzia MCP, które rejestrują zdolności w kształcie fetch.