Przejdź do głównej treści
Masz politykę, którą chcesz postawić przed produkcją. Strachem nie jest sama polityka — to przełączenie jej i odkrycie, że blokuje narzędzie, którego twój agent faktycznie potrzebuje, lub maskuje pole, od którego zależy twoja aplikacja. Naprawą nie jest więcej testowania w piaskownicy; to wdrażanie wobec prawdziwego ruchu w postawie, która nie może niczego zepsuć, potem zaostrzanie dopiero, gdy zobaczysz, co odpala. Ten przepis to to wdrożenie: obserwuj → cień → egzekwuj, z autonomią balanced przed tight. Zostajesz w konsoli (lub REST API) przez całą drogę; agent dalej woła https://api.orcarouter.ai/v1/... dokładnie jak wcześniej.
Nowy w modelu? Przeczytaj Tryby egzekwowania dla tego, co każda postawa robi mechanicznie, oraz bazę Secure Agents dla tego, co ustawia każdy poziom autonomii. Ta strona to sekwencja — kolejność, w której przełączasz przełączniki.

​
1. Wdrożenie bezpieczeństwa AI w trzech ruchach

Całe wdrożenie wymienia autonomię na bezpieczeństwo w trzech krokach, każdy zweryfikowany wobec żywego ruchu przed następnym:

Obserwuj

Pozwól na wszystko, loguj wszystko. Niepokryte wywołania narzędzi lądują w Discovered Tools; reguły guardrailu flag rejestrują dopasowania bez zmiany ruchu. Poznajesz prawdziwy kształt swojego agenta.

Cień

Prawdziwa polityka ewaluuje każde wywołanie, ale każdy egzekwujący werdykt jest degradowany do audit i logowany [shadow] would …. Widzisz dokładnie, co by zablokowało — z niczym faktycznie zablokowanym.

Egzekwuj

Cień wyłączony. deny blokuje, mask redaguje, pending_approval wstrzymuje. Autonomia idzie od szerokiej (balanced) do ciasnej (tight), a twój agent jest zarządzany.
Dyscyplina jest sednem: nigdy nie egzekwujesz reguły, której najpierw nie obserwowałeś, jak odpala w cieniu wobec twojego własnego ruchu.

​
2. Ruch pierwszy — obserwuj (autonomia = permissive)

Zacznij tak szeroko, jak się da. Zastosuj poziom autonomii permissive z Firewall → Posture (Developer+) — lub POST /api/workspace/firewall/autonomy. Włącza on tryb obserwacji przestrzeni roboczej i nie pozostawia żadnej egzekwującej polityki, więc każde wywołanie jest dozwolone, a każde niepokryte wywołanie jest logowane jako luka pokrycia. 
# Console: Firewall → Posture → apply "permissive"
# or, via the REST API on your session token:
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "permissive"}'
Trasy /api/workspace/firewall/* działają na twojej sesji konsoli / tokenie dostępu, nie na kluczu relay sk-orca-.... Zastosowanie poziomu autonomii to zapis przestrzeni roboczej — Developer+. Tylko wywołania modelu /v1/* używają klucza relay.
Teraz skieruj na to prawdziwy ruch i pozwól mu działać. Obserwuj dwa strumienie:
  • Firewall → Discovered Tools (Member) — każde narzędzie, które woła twój agent, oznaczone covered lub gap. To wejście do twoich reguł: za chwilę napiszesz politykę dla ruchu, który faktycznie się dzieje, nie dla hipotez.
  • Guardrails → Matches (Member) — jeśli dodałeś jakiekolwiek reguły na akcji flag, każde dopasowanie, które rejestrują, bez dotykania żądania.
Pozwól mu działać, aż Discovered Tools przestanie wynurzać nowe narzędzia. Ta stabilna lista to twoja specyfikacja autorowania reguł.

​
3. Ruch drugi — cień (prawdziwa polityka, zero blokowania)

Teraz napisz politykę, której faktycznie chcesz — globy narzędzi, klauzule argumentów, listy egress, pułap cap_cost — i włącz shadow_mode, zanim ją dołączysz. (Buduj reguły z reguł firewalla; pełny model polityki jest w referencji Firewall.) 
{
  "name": "prod-rollout",
  "enabled": true,
  "shadow_mode": true,
  "default_verdict": "audit",
  "rules": [
    { "priority": 10, "tool_name_glob": "shell.exec", "verdict": "deny" },
    { "priority": 20, "tool_name_glob": "*",          "verdict": "cap_cost", "cap_cost_cents": 1000 }
  ]
}
Z shadow_mode: true ten deny i ten cap_cost są oba degradowane do audit w czasie ewaluacji — silnik oblicza prawdziwy werdykt, loguje go z przedrostkiem [shadow] would … i przepuszcza wywołanie. Dołącz politykę do kluczy, które wdrażasz (ustaw firewall_policy_id na kluczu) lub uczyń ją domyślną przestrzeni roboczej. Potem przeczytaj Firewall → Events / Runs (Developer+) filtrowane do przedrostka [shadow] i potwierdź obie strony:
Każde wywołanie shell.exec pokazuje [shadow] would deny. Każde uruchomienie, które przekracza twój limit, pokazuje [shadow] would cap_cost. Polityka widzi ruch, dla którego ją zbudowałeś.
Żadne uprawnione narzędzie nie pojawia się z werdyktem byłoby-zablokowane. To sprawdzenie fałszywie dodatnich — powód, dla którego istnieje cień. Jeśli narzędzie, którego potrzebujesz, jest zflagowane, napraw regułę i ponownie obserwuj, zanim kiedykolwiek egzekwujesz.
Guardrails nie mają cienia na poziomie polityki. Odpowiednikiem jest akcja flag per reguła: rejestruje dopasowanie w strumieniu Matches i niczego nie zmienia, więc możesz zmierzyć regułę treści przed przełączeniem jej na block lub mask. Uruchom swoje reguły guardrailu jako flag przez ten sam ruch.

​
4. Ruch trzeci — egzekwuj (autonomia balanced, potem tight)

Gdy log cienia wygląda dobrze, egzekwuj w dwóch etapach, nie jednym. Nie skacz wprost do domyślnej odmowy. Najpierw balanced. To rekomendowana pierwsza egzekwująca postawa: domyślny werdykt firewalla to audit, ale najbardziej destrukcyjne akcje (jak destrukcyjny shell) są odmawiane, a guardrail PII Shield działa tylko-audit — flaguje PII bez maskowania go jeszcze. Teraz blokujesz najgorszą rzecz, jednocześnie wciąż obserwując resztę. Wyłącz shadow_mode na swojej własnej polityce w tym samym ruchu, aby jej werdykty deny / cap_cost weszły na żywo obok bazy. 
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "balanced"}'
Obserwuj Events przez godzinę. Prawdziwe bloki teraz pojawiają się bez przedrostka [shadow]. Odmówione wywołanie narzędzia zwraca HTTP 400 firewall_blocked; jest skip-retry i nie kosztuje tokenów modelu. Potem tight. Gdy balanced jest cichy, przejdź do domyślnej odmowy. Poziom tight odmawia domyślnie, odmawia destrukcyjnego shella oraz egress SSRF i egzekwuje PII Shield + Secrets Blocker — PII jest maskowane na żądaniu, zanim model je zobaczy, a sekrety w twoich żądaniach są blokowane. Zablokowany prompt zwraca HTTP 400 guardrail_blocked, kosztuje zero kwoty i jest skip-retry.
EtapFirewall (akcje)Guardrails (tekst)Co dowodzisz
permissiveObserwuj; nic nie zablokowanetylko flagPrawdziwy kształt ruchu
balancedDomyślny audit; destrukcyjny shell odmówionyPII zflagowaneNajgorszy przypadek jest zatrzymany
tightDomyślna odmowa; shell + narzędzia w kształcie fetch (SSRF) odmówionePII zamaskowane, sekrety zablokowanePełny zero-trust
Zastrzeżenie strumieniowania dla PII. Pod tight PII Shield maskuje PII na żądaniu, zanim model je zobaczy — to jest na żywo. Maskowanie odpowiedzi strumieniowanej po stronie wyjścia nie jest jeszcze na żywo; block na wyjściu jest egzekwowany na strumieniu (skaner tnie strumień). Jeśli zależysz od redagowania wyjścia modelu, zweryfikuj swoją kombinację etapu/strumienia w zakładce Test guardrailu najpierw. Zobacz Guardrails.

​
5. Klapa bezpieczeństwa — cofnięcie jednym kliknięciem

Każda zmiana autonomii to pojedyncza transakcja, która robi migawkę twojej poprzedniej postawy, więc możesz wrócić wprost z Firewall → Posture (lub POST /api/workspace/firewall/autonomy/undo/:audit_id). Możesz też po prostu ponownie zastosować łagodniejszy poziom — zrzucić tight z powrotem do balanced lub balanced z powrotem do permissive — w dowolnym momencie.
Cofnięcie przywraca z migawki audytu najnowszego zastosowania. Jeśli zrobiłeś ręczne edycje polityki od zastosowania, które cofasz, ta migawka nie jest już najnowszą nieużytą, a cofnięcie odmawia, zamiast po cichu odsuwać te edycje. Gdy to się stanie, ponownie zastosuj łagodniejszy poziom zamiast tego — jest zawsze dostępny.

​
6. Skąd biorą się werdykty każdego ruchu

Wdrożenie nigdy nie blokuje czegoś, o co nie poprosiłeś, ponieważ każda postawa mapuje się na wyraźny, obserwowalny mechanizm:
PostawaMechanizmWynik
ObserwujPrzestrzeń robocza firewall_observe_mode włączony + guardrail flagPozwól + loguj luki / dopasowania
CieńPer polityka shadow_modePrawdziwy werdykt obliczony, degradowany do audit, logowany [shadow] would …
Egzekwujshadow_mode wyłączony + autonomia tight/balanceddeny / mask / cap_cost wchodzą na żywo
Cztery terminy — tryb obserwacji, werdykt audit, akcja flag oraz shadow_mode — to odrębne przełączniki, udokumentowane obok siebie w Trybach egzekwowania.

​
7. Następne kroki

Tryby egzekwowania

Mapa mechanizmów stojąca za observe, cieniem i egzekwowaniem.

Baza Secure Agents

Co ustawia każdy poziom autonomii i jak go najpierw zasymulować.

Okiełznaj agenta autonomicznego

Następny krok po egzekwowaniu: limity kosztu, wykrywanie anomalii i zatwierdzenia.

Agent Firewall

Polityki, reguły, werdykty, tryb cienia i brama MCP w całości.
Go-live, któremu możesz ufać, to wdrożenie, nie przełącznik. Obserwuj, co robi twój agent, zacieniuj politykę wobec jego prawdziwego ruchu, potem egzekwuj — balanced przed tight — a każda reguła jest zweryfikowana na produkcji, zanim kiedykolwiek ją zablokuje.