Przejdź do głównej treści
Najbezpieczniejsza postawa dla autonomicznego agenta to default-deny: blokuj domyślnie każde narzędzie, potem wyraźnie zezwól tylko na garstkę, której twój agent ma używać. Wszystko nowe, co agent podejmie — skill społecznościowy, źle skonfigurowany serwer MCP, narzędzie, do którego jailbreak namówił model — jest odmówione, bo nigdy tego nie włączyłeś, a nie dlatego, że pamiętałeś, by je zablokować. Ta strona to wzorzec listy dozwolonych narzędzi dla agentów na api.orcarouter.ai: werdykt domyślny deny plus jedna lub więcej reguł allow kluczowanych na tool_name_glob. Dla pełnego języka dopasowania stojącego za tymi regułami zobacz Reguły Firewall.
Listy dozwolonych są pisane w konsoli pod Security → Firewall lub przez trasy zarządzania /api/workspace/firewall/* (twoja sesja / token dostępu — nie klucz relay sk-orca-…). Tylko wywołania /v1/* twojego agenta używają klucza relay. Tworzenie lub edycja polityki to akcja Developer+.

​
1. Dlaczego default-deny dla agentów

Lista blokad („odmów shell.exec, odmów db.delete, …”) jest zawsze tylko tak kompletna jak ostatnie zagrożenie, o którym pomyślałeś. Lista dozwolonych odwraca ciężar dowodu: brama odmawia wszystkiego, czego polityka wyraźnie nie zezwala, więc nieznane narzędzie jest zamknięte z konstrukcji.

Werdykt domyślny = deny

Podłoga polityki. Bez dopasowania reguły każde wywołanie narzędzia jest blokowane.

Reguły allow włączają narzędzia z powrotem

Każda reguła allow nazywa narzędzia, których faktycznie używasz — po dokładnej nazwie lub po globie.
Silnik przechodzi reguły polityki w kolejności priorytetów i wygrywa pierwsze dopasowanie; jeśli nic nie pasuje, spada do default_verdict polityki. Więc lista dozwolonych to po prostu: wysokopriorytetowe reguły allow dla twoich prawdziwych narzędzi, z podłogą deny wychwytującą całą resztę.

​
2. Jeden przykład: lista dozwolonych narzędzi agenta badawczego

Powiedzmy, że twój agent potrzebuje kiedykolwiek tylko przeszukiwać sieć i czytać z bazy wiedzy — narzędzi nazwanych web.search i kb.read. Wszystko inne (shell, zapisy plików, mutacje bazy danych, dowolne narzędzie, które prompt-injection mógłby wyczarować) musi być odmówione. Zbuduj politykę jako domyślne deny + dwie reguły allow:
1

Utwórz politykę z domyślnym deny

Security → Firewall → Policies → New policy. Nazwij ją, zostaw Enabled włączone i ustaw werdykt domyślny na deny. To zamknięta podłoga — zobacz Utwórz politykę.
2

Dodaj regułę allow na rodzinę narzędzi

W edytorze reguł dodaj dwie reguły, obie verdict = allow:
prioritytool_name_globverdict
10web.searchallow
20kb.*allow
web.search to dokładne dopasowanie; kb.* to glob przedrostka, który zezwala na kb.read, kb.search i dowolne przyszłe narzędzie kb.* bez ponownej edycji polityki.
3

Przypnij ją do klucza twojego agenta

Ustaw firewall_policy_id klucza na tę politykę (lub uczyń ją domyślną dla przestrzeni roboczej). Ciało żądania twojego agenta jest niezmienione.
Teraz web.search i kb.read przechodzą; wywołanie shell.exec nie dopasowuje żadnej reguły allow, trafia w podłogę deny i wraca jako HTTP 400 z kodem firewall_blocked na powierzchni inbound — zobacz jak wygląda block.
Pisz reguły allow jako dokładne nazwy lub wąskie przedrostki (kb.*), nie szerokie sufiksy. Luźny *.read zezwoliłby na kb.read i secrets.read — przeciwieństwo tego, do czego służy lista dozwolonych. Trzymaj glob tak zacieśniony, na ile pozwala nazewnictwo narzędzi.

​
3. Glob na jednym ekranie

tool_name_glob to mała gramatyka z rozróżnianiem wielkości liter — bez regexa, czas liniowy. Kształty, które mają znaczenie dla listy dozwolonych:
WzorzecZezwala
web.searchDokładnie to narzędzie.
kb.*Przedrostek — kb.read, kb.search (nie samo kb).
*.searchSufiks — web.search, kb.search i samo search.
*.tools.*Wrostek — byo.tools.fetch i podobne.
Dla pełnej gramatyki (reguły wrostka, przypadki brzegowe, globy nazw skilli) zobacz Składnia globów i referencję Reguł Firewall.
Glob *.suffix dopasowuje też gołe, nieprzestrzenione czasowniki — *.search zezwala na narzędzie nazwane dosłownie search, nie tylko web.search. Dostawcy i nieprzestrzeniające serwery MCP wystawiają narzędzia pod gołymi czasownikami, więc sufiks na liście dozwolonych jest szerszy, niż wygląda. Preferuj dokładne nazwy lub przedrostki, gdy chcesz zacieśnioną listę dozwolonych.

​
4. Wytocz to bez psucia twojego agenta

Default-deny to postawa najbardziej skłonna zablokować narzędzie, o którym zapomniałeś, że go potrzebujesz. Wprowadzaj ją etapami:
Włącz tryb cienia. Polityka ewaluuje i loguje dokładnie tak, jak robiłaby to na żywo, ale degraduje każde deny do audit z powodem poprzedzonym przedrostkiem [shadow] would …. Uruchom prawdziwy ruch, potem odczytaj strumień zdarzeń.
Wykryte narzędzia wymieniają każde narzędzie, które przestrzeń robocza widziała, oznaczone covered lub gap. Zdarzenia „would-deny” trybu cienia plus luki mówią ci dokładnie, których reguł allow wciąż potrzebujesz.
Piaskownica Test robi dry-run polityki wobec przykładowego wywołania narzędzia i zwraca werdykt, dopasowaną regułę i powód — nic dyspozytowanego, nic persystowanego. Potwierdź, że web.search zezwala, a shell.exec odmawia, potem wyłącz cień.
Odmówione wywołanie inbound kosztuje zero tokenów modelu — jest blokowane, zanim uruchomi się model nadrzędny — i jest oznaczone skip-retry, więc zablokowane narzędzie nie spali budżetu ponawiania, ponownie blokując. Zobacz Werdykty.

​
5. Dokąd dalej

Blokuj konkretne narzędzia

Odwrotność — zachowaj podłogę default-allow i odmawiaj nazwanych narzędzi.

Walidacja argumentów

Zezwól na narzędzie, ale tylko z bezpiecznymi argumentami (db.query, ale nie DROP TABLE).

Priorytet reguł

Jak first-match-wins porządkuje twoje reguły allow nad podłogą deny.

Werdykty

allow, audit, deny, sanitize, pending_approval, cap_cost.
Dla zagrożenia, któremu zaradza ten wzorzec, zobacz nadmierną sprawczość i niebezpieczne wywołania narzędzi. Dlaczego default-deny to baza agentowa, zobacz dlaczego zero trust.