Przejdź do głównej treści
Agent kodujący to rzecz o najwyższej dźwigni w twojej przestrzeni roboczej i najbardziej niebezpieczna. Uruchamia shell.exec, edytuje pliki, pobiera URL-e i ładuje skille społecznościowe — każde z nich może rm -rf wolumen, przeczytać .env lub wyeksfiltrować do hosta atakującego. Ten przepis blokuje tę powierzchnię Firewallem: odmów destrukcyjnego shella, waliduj argumenty wywołań, które jednak dopuszczasz, ogrodź egress i wstrzymaj prawdziwie ryzykowne operacje dla człowieka. Nic z tego nie dotyka kodu twojego agenta — polityka żyje w bramie i jest egzekwowana przy następnym wywołaniu.
Wszystko poniżej jest konfigurowane w konsoli (Firewall → Posture / Policies). Te trasy zarządzania używają twojej sesji konsoli, nie klucza relay. Tylko wywołania /v1/*, które robi twój agent, niosą klucz sk-orca-…. Edycje polityki wymagają roli Developer.

1. Zacznij od obserwacji, nie blokowania — baza bezpiecznego agenta kodującego

Nie pisz reguł na ślepo. Daj agentowi jego klucz sk-orca-…, potem otwórz Firewall → Posture i zastosuj poziom autonomii balanced (poziom autonomii). W jednej transakcji audytuje to każde wywołanie narzędzia, flaguje PII i odmawia destrukcyjnego shella — więc najgorsza akcja jest już ogrodzona, gdy poznajesz resztę zachowania agenta z prawdziwego ruchu. Pozwól mu działać, potem przeczytaj Firewall → Discovered tools: każde narzędzie, które przestrzeń robocza widziała, oznaczone covered (reguła ma zastosowanie) lub gap (żadna nie ma). Ta lista to szkic twojej listy dozwolonych. Gdy strumień wygląda dobrze, przejdź do tight (domyślna odmowa) lub napisz celowaną politykę poniżej.
balanced to rekomendowana postawa początkowa; permissive niczego nie blokuje, ale dalej wszystko loguje; tight to domyślna odmowa plus presety secrets i SSRF. Zobacz bazę, by zobaczyć dokładnie, co każdy z nich materializuje.

2. Odmów destrukcyjnego shella — nienegocjowalna podłoga

Najważniejsza pojedyncza reguła dla agenta kodującego to brak destrukcyjnego shella. Poziomy autonomii balanced i tight już dostarczają to jako preset Block destructive shell, który materializuje prawdziwe, edytowalne reguły deny pokrywające zarówno nazwy narzędzi w przestrzeni roboczej (shell.*, bash, cmd.*, powershell.*, exec.*), jak i formy w przestrzeni nazw MCP, które wystawia zarejestrowany serwer (*.shell.*, *.cmd.*, …). Jeśli wolisz ograniczyć to ciaśniej niż „odmów całego shella”, napisz jedną regułę, która odmawia tylko destrukcyjnych poleceń, a resztę audytuje. Reguła dopasowuje się na globie nazwy narzędzia plus opcjonalnym predykacie argumentu (JSONPath wobec argumentów wywołania):
W Firewall → Policies dodaj regułę ponad swoją domyślną:
  • Glob narzędzia: shell.exec
  • Args match (klauzula JSONPath):
{
  "clauses": [
    { "path": "$.command", "op": "regex", "value": "(?i)\\brm\\s+-[a-z]*[rf]" }
  ]
}
  • Werdykt: deny
Operatory argumentów są zamkniętym zbiorem — eq, contains, regex, in, cidr_match, gt, lt. Wywołanie, którego $.command pasuje do regex, jest blokowane; wszystko inne przepada do następnej reguły.
Odrzucone wywołanie na powierzchni inbound zwraca HTTP 400 z kodem błędu firewall_blocked i komunikatem nazywającym narzędzie i powód. Wywołanie dyspozytowane przez bramę MCP wraca jako błąd narzędzia (firewall deny: …), więc model może zareagować, zamiast się wysypać. Bloki inbound odpalają przed wywołaniem modelu nadrzędnego, więc nie kosztują tokenów modelu.
Zobacz Reguły firewalla dla pełnego języka dopasowania (globy narzędzi, klauzule argumentów, sekwencje, limity kosztu).

3. Waliduj argumenty na narzędziach, które zachowujesz

Dopuszczenie narzędzia to nie to samo, co dopuszczenie każdego jego argumentu. Ten sam predykat JSONPath, który zawęża deny, pozwala ci ograniczyć kształt dozwolonego wywołania — więc db.query nie może nieść DROP, a file.write nie może uciec z katalogu.

Zablokuj SQL DROP

Glob db.query, klauzula {"path":"$.sql","op":"regex","value":"(?i)\\bdrop\\b"}, werdykt deny.

Zredaguj sekret w argumentach

Werdykt sanitize redaguje dopasowane podłańcuchy z argumentów wywołania narzędzia, zanim wywołanie zostanie przesłane. Nigdy nie dotyka tego, co narzędzie zwraca; na powierzchni inbound (bez argumentów czasu wywołania) eskaluje do bloku.
Firewall sanityzuje argumenty wywołania narzędzia, nie wyniki narzędzia. Aby zatrzymać sekret przed wejściem do żądania w pierwszej kolejności, dołącz guardrail Secrets Blocker do klucza — to prześwietla sam tekst promptu, zanim model go zobaczy. Dwie płaszczyzny się komponują: guardrails prześwietlają tekst, Firewall zarządza akcją.

4. Kontroluj egress — ogrodź, dokąd agent może sięgnąć

Agent kodujący, który może pobierać URL-e, może zostać skierowany w SSRF (uderzanie w cloud-metadata lub wewnętrzny host 10.x) lub użyty do eksfiltracji. Poziom autonomii tight dostarcza preset SSRF, który odmawia nazw narzędzi w kształcie fetch (http_fetch, web_search, fetch_url, request oraz ich formy <server>.*) wprost. Dla kontroli na poziomie celu napisz regułę egress. Reguły egress zakresują po hoście lub CIDR z wpisami allow / deny, ewaluowane na powierzchni egress:
{ "deny": ["169.254.169.254", "10.0.0.0/8", "*.internal"] }
To odpala na dowolnym celu wychodzącym zgłoszonym przez narzędzie, który ląduje w zakresie prywatnym, na IP cloud-metadata lub na wewnętrznej nazwie hosta — przepuszczając cele publiczne, jednocześnie ogradzając niebezpieczne.
Żaden preset nie dostarcza reguł egress opartych na CIDR — preset SSRF dopasowuje nazwy narzędzi w kształcie fetch. Powyższa denylista host/CIDR to taka, którą piszesz sam. Zobacz Zatrzymaj eksfiltrację dla pełnego wzorca.

5. Wstrzymaj ryzykowne operacje dla człowieka (HITL)

Niektóre operacje nie powinny być auto-dozwolone ani auto-odmówione — deploy, git push, destrukcyjna migracja. Dla nich użyj werdyktu pending_approval. Wywołanie jest wstrzymane, agent dostaje odpowiedź „wstrzymane” z id zatwierdzenia, a recenzent rozstrzyga je poza pasmem:
  1. Napisz regułę (np. glob deploy.*, werdykt pending_approval).
  2. Wstrzymane wywołanie zwraca HTTP 400 firewall_approval_pending z id zatwierdzenia.
  3. Recenzent zatwierdza je z konsoli (Developer+) lub przez podpisany HMAC webhook callback.
  4. Agent odpytuje zatwierdzenie, potem ponownie wysyła oryginalne wywołanie z jednorazowym nagłówkiem X-OrcaRouter-Firewall-Approval — a brama przepuszcza je ten jeden raz.
Wdrażaj każdą nową politykę najpierw w trybie cienia. Polityka ewaluuje i loguje dokładnie tak, jak robiłaby to na produkcji, ale każdy egzekwujący werdykt jest degradowany do audit z powodem [shadow] would … — więc możesz udowodnić, że odpala na tym, czego oczekujesz, zanim zepsuje build.

6. Zarządzaj skillami i serwerami MCP, które ładuje

Agenty kodujące wciągają zdolności w czasie wykonywania — skille społecznościowe, własne serwery MCP. Firewall zarządza oboma w bramie:
  • Skille są skanowane do pasma ryzyka z trybem egzekwowania (allow / quarantine / block). Auto-wykryty skill jest poddany kwarantannie — wstrzymany do zatwierdzenia — dopóki recenzent go nie zatwierdzi. Zobacz Skille.
  • Serwery MCP, które rejestrujesz, dyspozytują każde tools/call przez bramę, która ewaluuje każde z nich na powierzchni mcp przed dyspozycją. Poświadczenia są przechowywane zaszyfrowane; sonda zdrowia raportuje ok / degraded / down. Zobacz Serwery MCP oraz Utwardź agenta MCP.

7. Zweryfikuj i obserwuj

Zanim polegniesz na polityce, przepuść ją na sucho. Zakładka Test ewaluuje przykładowe wywołanie narzędzia wobec bieżącej polityki i pokazuje werdykt, dopasowaną regułę i powód — nic nie jest dyspozytowane, nic persystowane. Gdy jest na żywo, Firewall → Events / Runs to zapis każdej ewaluacji, filtrowalny po werdykcie, powierzchni, narzędziu i uruchomieniu, a strumień anomalii flaguje skoki tempa/kosztu wobec wyuczonej bazowej linii przestrzeni roboczej, retry_loop oraz nigdy wcześniej niewidziane ścieżki narzędzi.

Podsumowanie

Referencja Firewall

Pełna płaszczyzna polityki — powierzchnie, werdykty, rozwiązywanie, autonomia.

Reguły firewalla

Język dopasowania: globy, klauzule argumentów, egress, sekwencje.

Niebezpieczne wywołania narzędzi

Zagrożenie, przed którym broni ten przepis.

Nadmierna sprawczość

Dlaczego nadmiernie uprawnione agenty to rdzenne ryzyko agenta.

Przepis na agenta autonomicznego

Zablokuj w pełni autonomiczną pętlę agenta od początku do końca.

Zatrzymaj eksfiltrację

Wzorce egress i śmiertelnej triady w głąb.