Przejdź do głównej treści
Każde żądanie docierające do OrcaRouter niesie klucz API. Ten klucz to nie tylko poświadczenie — to deklaracja zakresu: które modele wywołujący może używać, które IP mogą go prezentować, ile może wydać i dokładnie który guardrail i polityka firewalla zarządzają jego ruchem. Ta strona wyjaśnia trójpoziomową hierarchię i jak polityki rozwiązują się w czasie żądania.

​
1. Trzy zakresy

Trzy koncepcje zagnieżdżają się w sobie:
  • Przestrzeń robocza — granica najemcy. Każdy członek przestrzeni roboczej współdzieli ten sam katalog guardrails i polityk firewalla. Nic nie przekracza granic przestrzeni roboczej — polityka napisana w przestrzeni roboczej A jest niewidoczna dla przestrzeni roboczej B.
  • Polityka — nazwany, w zakresie przestrzeni roboczej zestaw reguł (guardrail albo polityka firewalla). Edycja polityki wchodzi w życie na każdym powiązanym z nią kluczu przy następnym żądaniu, bez ponownego wdrożenia.
  • Klucz — tożsamość plus dołączenia. Klucz niesie własne ograniczenia i wskazuje na polityki, które nim zarządzają.
Przestrzeń robocza jest zewnętrzną granicą; polityki są zasobami współdzielonymi wewnątrz niej; klucze to tożsamości per agent, które łączą ograniczenia i polityki razem.

​
2. Co klucz ze sobą niesie

Każdy klucz API to pakiet limitów i dołączeń. Ustaw je w edytorze kluczy (/console/token) — tworzenie lub edycja kluczy wymaga roli Developer lub wyższej.
PoleCo ograniczaMinimalna rola do ustawienia
model_limitsOgranicza klucz do konkretnej listy modeli — każde wywołanie spoza tej listy jest odrzucane, zanim opuści bramę.Developer
allow_ipsLista dozwolonych IP. Żądania z jakiegokolwiek nielisteowanego adresu są odrzucane na warstwie auth. Puste oznacza, że wszystkie IP są dozwolone.Developer
credit_limit_usdLimit wydatków w USD. 0 oznacza bez limitu. Brama egzekwuje to wobec dożywotnich wydatków klucza.Developer
expired_timeBezwzględny znacznik czasu wygaśnięcia. -1 oznacza, że klucz nigdy nie wygasa.Developer
environmentDowolna etykieta (np. prod, staging, dev) do organizowania kluczy i filtrowania logów.Developer
guardrail_idDołącza konkretny guardrail do tego klucza. Każde wywołanie tego klucza jest sprawdzane przez ten guardrail.Developer
firewall_policy_idDołącza konkretną politykę firewalla do tego klucza. Każde wywołanie narzędzia przez ten klucz jest ewaluowane przez tę politykę.Developer
is_firewall_gatewayOznacza klucz jako token z zakresem gateway — wymagany do wywołania tras dyspozycji MCP i hooka evaluate. Zwykły klucz dostaje 403 na tych trasach. Odczyt plaintext klucza gateway wymaga Admin.Admin (do włączenia i odczytu plaintext)
Klucze są maskowane na wyświetleniu w konsoli. Plaintext jest pokazywany raz przy tworzeniu; klucze z zakresem gateway wymagają Admin do ponownego pobrania.

​
3. Kolejność rozwiązywania polityk

Dla każdego żądania OrcaRouter rozwiązuje aktywny guardrail i politykę firewalla niezależnie:
  1. Dołączenie klucza — jeśli klucz ma jawne guardrail_id (lub firewall_policy_id) i ta polityka istnieje i jest włączona, ma zastosowanie.
  2. Domyślny przestrzeni roboczej — jeśli klucz nie ma dołączenia, stosuje się włączony guardrail is_default (lub polityka) przestrzeni roboczej.
  3. Brak egzekwowania — jeśli żadne nie jest ustawione, żądanie przechodzi bez sprawdzania treści lub egzekwowania wywołań narzędzi.
Dwie płaszczyzny różnią się, gdy dołączona polityka jest wyłączona:
  • Wyłączone lub usunięte dołączenie guardrail oznacza, że klucz nie dostaje żadnego guardrail — wyłączenie go to przełącznik off; nie wraca do domyślnego przestrzeni roboczej.
  • Wyłączone dołączenie firewalla wraca do domyślnej polityki firewalla przestrzeni roboczej — więc wyłączenie dołączenia firewalla przywraca klucz do domyślnego przestrzeni roboczej, a nie wyłącza egzekwowania.
Brakujące (0/nieustawione) dołączenie zawsze wraca do domyślnego przestrzeni roboczej; żadne nie ustawione oznacza brak egzekwowania.
Co najwyżej jeden guardrail i jedna polityka firewalla na przestrzeń roboczą może być domyślna w dowolnym czasie. Promowanie nowego domyślnego degraduje stary w tej samej transakcji — nigdy nie możesz przypadkowo mieć dwóch domyślnych.

​
4. Klucze z minimalnymi uprawnieniami — jeden klucz per agent

Najbezpieczniejszą konfiguracją jest danie każdemu agentowi własnego, wąsko zakresowego klucza, zamiast współdzielenia jednego klucza przestrzeni roboczej między wszystkimi wywołującymi. Dobrze zakresowy klucz dla agenta, który wywołuje tylko jeden model i uruchamia zaplanowane zadania, może wyglądać tak:
  • model_limits: ["openai/gpt-4o-mini"] — agent nie może przełączyć się na droższy lub bardziej zdolny model.
  • allow_ips: CIDR egress schedulera — żadne inne źródło nie może prezentować tego klucza.
  • credit_limit_usd: tygodniowy pułap budżetu — rozbiegana pętla nie może wyczerpać salda przestrzeni roboczej.
  • expired_time: koniec sprintu lub cyklu wdrożenia — klucz wygasa automatycznie i nie może być ponownie użyty.
  • guardrail_id: guardrail specyficzny dla wrażliwości danych tego agenta — bardziej rygorystyczny niż domyślny przestrzeni roboczej.
  • firewall_policy_id: polityka, która tylko-listuje dozwolone narzędzia, których ten agent legalnie potrzebuje.
Gdy ten agent jest skompromitowany przez prompt injection, promień wybuchu jest ograniczony: może wywołać tylko jeden model, tylko z jednego zakresu IP, tylko do swojego limitu wydatków i tylko narzędzia, na które zezwala jego polityka firewalla. Reszta przestrzeni roboczej jest nienaruszana.
Twórz klucze z zakresem gateway (is_firewall_gateway) tylko dla powierzchni dyspozycji MCP lub hooka evaluate — nigdy dla ogólnego ruchu wnioskowania. Klucz gateway na ścieżce wnioskowania daje wywołującemu dostęp do tras /api/v1/firewall/*, co jest szerszą zdolnością niż potrzebuje. Jeden klucz, jeden cel.

​
5. Gdzie tworzone są polityki

Guardrails i polityki firewalla mają oba zakres przestrzeni roboczej i są współdzielone przez wszystkich członków, ale zmiany wymagają właściwej roli:
  • Odczyt dowolnego guardrail, polityki lub klucza — każdy członek przestrzeni roboczej.
  • Tworzenie lub zmiana guardrails, polityk firewalla, serwerów MCP, poziomów autonomii, akcji zatwierdzenia i zwykłych kluczy API — Developer+.
  • Włączanie is_firewall_gateway na kluczu; odczyt plaintext klucza gateway — Admin+.
Przestrzeń robocza jest granicą współpracy: każdy może zobaczyć katalog polityk; tylko Developerzy i wyżsi mogą go zmieniać; tylko Adminowie mogą wydawać poświadczenia gateway.

​
6. Następne kroki

Baza Secure Agents

Rekomendowana postawa startowa — jeden przełącznik poziomu autonomii, potem dostrajanie na podstawie rzeczywistego ruchu.

Uzyskaj klucz API

Utwórz swój pierwszy klucz i dołącz guardrail lub politykę firewalla w konsoli.
Zakres jest fundamentem stosu kontrolnego. Im węższy zakres każdego klucza, tym mniejszy promień wybuchu, gdy jakikolwiek agent jest skompromitowany — i tym jaśniejszy ślad audytu, który pokazuje, do czego każdy agent był autoryzowany.