Przejdź do głównej treści
Zarejestrowany serwer MCP ogłasza dowolne narzędzia, jakie chce — a agent chętnie wywoła którekolwiek z nich. Bezpieczna postawa jest odwrotna: zdecyduj krótką listę narzędzi, których faktycznie potrzebujesz, dopuść dokładnie te i odmów reszcie. To jest lista dozwolonych, a na OrcaRouter budujesz ją z reguł tool_name_glob ewaluowanych na powierzchni mcp. Każde tools/call, które przekracza bramę MCP, przebiega przez twoją politykę firewalla przed tym, jak dotrze do prawdziwego serwera. Więc lista dozwolonych nie jest doradcza — wywołanie narzędzia, którego nie dopuściłeś, nigdy nie dyspozytuje.
Edycja polityki to akcja konsoli. Trasy /api/workspace/firewall/* uwierzytelniają się twoim tokenem sesji / dostępu, nie kluczem relay sk-orca-…. Zapis reguł wymaga roli Developer+; każdy członek przestrzeni roboczej (aż do Viewer) może odczytywać polityki i strumień odkrytych narzędzi.

1. Dlaczego lista dozwolonych z domyślną odmową dla bezpiecznych narzędzi mcp

Lista zabronionych — „blokuj niebezpieczne narzędzia” — zawodzi w chwili, gdy serwer dodaje nowe narzędzie, zmienia nazwę jednego, lub gdy podłączasz drugi serwer. Zbiór niebezpiecznych narzędzi jest otwarty; zbiór, którego zamierzałeś użyć, jest mały i znany. Lista dozwolonych odwraca domyślną wartość, tak by nieznane było odmawiane, a nie wpuszczane:
  • Nowe narzędzia są domyślnie odmawiane. Serwer, który urośnie o narzędzie delete_repo po tym, jak go podłączyłeś, nie może być wywołany, dopóki nie dodasz go do listy dozwolonych.
  • Zakres jest per serwer. Przestrzeń nazw <server>.<tool> pozwala ci dopuścić github.create_issue, odmawiając wszystkiemu innemu pod github.*.
  • Jeden punkt zwężenia. Ta sama polityka zarządza dołączonym serwerem i każdym serwerem BYO za bramą, więc jest jedno miejsce do odczytania listy dozwolonych.
Lista dozwolonych paruje się naturalnie z trybem observe: włącz go najpierw, pozwól prawdziwemu ruchowi zapełnić strumień Odkrytych narzędzi, potem promuj narzędzia, które widzisz, do wyraźnych reguł allow i przełącz domyślną wartość na deny.

2. Dwa elementy

Lista dozwolonych to default_verdict plus uporządkowany zestaw reguł.

default_verdict: deny

Domyślna wartość polityki dla każdego tools/call, którego żadna reguła nie dopasowuje. Ustaw ją na deny, a wszystko, czego wyraźnie nie dopuściłeś, jest blokowane. (Przyjmuje też allow i auditaudit to domyślna wartość.)

reguły allow

Jedna reguła per narzędzie (lub per glob). Każda niesie tool_name_glob i werdykt allow. tools/call dopasowujące glob rozstrzyga się do allow i dyspozytuje; wszystko inne spada do domyślnej odmowy.
Glob jest dopasowywany wobec nazwy narzędzia z przestrzenią nazw — github.create_issue, shell.exec. * dopasowuje dowolne narzędzie (używaj oszczędnie; reguła allow z * cofa całą listę dozwolonych). Wiodące <server>. zawęża glob do jednego serwera.

3. Jeden konkretny przykład

Podłączyłeś serwer github i chcesz, by agenty tylko odczytywały i otwierały zgłoszenia — nigdy nie usuwały ani nie administrowały niczego. W konsoli otwórz Firewall → Policies, ustaw domyślny werdykt polityki na deny i dodaj dwie reguły allow:
Kolejnośćtool_name_globWerdykt
1github.create_issueallow
2github.list_issuesallow
To cała lista dozwolonych. Z domyślną wartością na deny:
  • github.create_issue → dopasowuje regułę 1 → allow, dyspozytuje.
  • github.delete_repo → nie dopasowuje niczego → deny domyślnie.
Odmówione wywołanie MCP wraca do modelu jako błąd narzędzia (firewall deny: …) — w tym samym kształcie, jaki zwraca dowolne zawodzące narzędzie — więc agent może się dostosować, zamiast się wysypać. (Na powierzchni inbound deny jest zamiast tego HTTP 400 z kodem błędu firewall_blocked.)
Reguły są uporządkowane i ewaluowane z góry na dół. Nie umieszczaj szerokiego tool_name_glob: github.* allow nad twoimi konkretnymi regułami deny — wygrywa pierwsze dopasowanie, a wildcard wpuściłby właśnie te narzędzia, które zamierzałeś wykluczyć. W razie wątpliwości trzymaj listę dozwolonych wąską i opieraj się na domyślnej odmowie, nie na wildcardach.

4. Zaostrzanie argumentami

Nazwa narzędzia na liście dozwolonych może wciąż być wywołana ze złymi argumentami. Zawęź dalej, dodając klauzulę args_match (JSONPath + operator jak eq, contains, regex, in lub cidr_match) do reguły, lub nakładając regułę deny nad allow dla konkretnego kształtu argumentu — na przykład dopuść github.create_issue, ale deny go, gdy docelowe repo nie jest na zatwierdzonej liście. Zobacz referencję reguł firewalla po pełny zestaw operatorów.
sanitize redaguje argumenty wywołania narzędzia przed przesłaniem — nigdy nie dotyka tego, co narzędzie zwraca. Po przycinanie zwróconej treści, to inna kontrola; zobacz oczyszczanie wyjścia narzędzia.

5. Wytocz to bezpiecznie

Przełącz całoserwerową domyślną odmowę w produkcji, a ryzykujesz zepsuciem agenta, który po cichu polegał na narzędziu, o którym zapomniałeś. Dwa ustawienia zmniejszają to ryzyko:
Flaga per polityka, która obniża egzekwujące werdykty do audit. Twoja domyślna odmowa i reguły deny logują [shadow] would deny … zamiast blokować, więc możesz zwalidować listę dozwolonych wobec prawdziwego ruchu, zanim ugryzie. Przeczytaj więcej w trybach egzekwowania.
Ustawienie przestrzeni roboczej, które loguje każde nieprzykryte wywołanie jako lukę w strumieniu Odkrytych narzędzi. Uruchom go, zanim napiszesz listę dozwolonych, by dowiedzieć się dokładnie, które narzędzia twoje agenty wywołują, potem promuj każde do wyraźnej reguły allow.
Gdy log shadow jest czysty — żadne legalne wywołanie nie zostałoby odmówione — wyczyść shadow_mode, a lista dozwolonych egzekwuje.

6. Zweryfikuj, że działa

Po egzekwowaniu potwierdź, że odmówione narzędzia faktycznie zostają odrzucone:
  • Dry-run tools/call wobec polityki (Developer+), by zobaczyć werdykt i która reguła — lub domyślna wartość — go wyprodukowała, bez wysyłania prawdziwego ruchu. Przekaż nazwę narzędzia, powierzchnię i przykładowe args; silnik ewaluuje je i zwraca ślad werdyktu bez rejestrowania zdarzenia.
  • Obserwuj zdarzenia. Każde zablokowane wywołanie rejestruje zdarzenie firewalla, które Developer+ może odczytać w konsoli; strona zdarzeń audytu pokrywa strumień i jego pola.
Wolisz nie autorować ręcznie każdej reguły? Preset autonomii tight pisze za ciebie politykę domyślnej odmowy (plus reguły deny dla destrukcyjnych narzędzi shell i nazw narzędzi o kształcie fetch), potem dodajesz z powrotem konkretne narzędzia, których potrzebujesz. Zobacz tryby egzekwowania po to, co instaluje każdy poziom autonomii.

Powiązane

Połącz serwer MCP

Zarejestruj serwer, zanim będziesz mógł stworzyć listę dozwolonych jego narzędzi.

Firewall: serwery MCP

Zachowanie bramy w czasie wykonania i werdykty per wywołanie.

Referencja reguł firewalla

Pełny DSL reguł — globy, args_match, egress, sanitize.

Niebezpieczne wywołania narzędzi

Zagrożenie, do opanowania którego zbudowana jest lista dozwolonych.

Limity egress

Zarządzaj, dokąd dozwolone narzędzie może sięgać.

Guardrails vs. firewall

Kiedy sięgnąć po politykę treści, a kiedy po politykę narzędzi.