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_repopo 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 podgithub.*. - 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.
2. Dwa elementy
Lista dozwolonych todefault_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 audit — audit 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.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ś serwergithub 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_glob | Werdykt |
|---|---|---|
| 1 | github.create_issue | allow |
| 2 | github.list_issues | allow |
deny:
github.create_issue→ dopasowuje regułę 1 → allow, dyspozytuje.github.delete_repo→ nie dopasowuje niczego → deny domyślnie.
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.)
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:shadow_mode — zobacz odmowy bez egzekwowania
shadow_mode — zobacz odmowy bez egzekwowania
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.tryb observe — wystaw narzędzia, które przeoczyłeś
tryb observe — wystaw narzędzia, które przeoczyłeś
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.
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/callwobec 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.
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.
