Przejdź do głównej treści
Budujesz SaaS, w którym wielu klientów-dzierżawców dzieli jedną bazę kodu i jedną przestrzeń roboczą OrcaRouter. Każdy dzierżawca wysyła prompty i uruchamia agenty przez twoją bramę, a trudnym problemem jest promień rażenia: wyciekły klucz dzierżawcy, rozbiegany agent dzierżawcy lub PII jednego dzierżawcy lądujące w logach innego nie mogą przelać się przez granicę. Ten przepis łączy trzy kontrole, które czynią dzieloną bramę bezpieczną dla dzierżawców — klucz o ograniczonym zakresie per dzierżawca, politykę na poziomie przestrzeni roboczej, którą każdy dzierżawca dziedziczy, oraz nadpisania per dzierżawca tam, gdzie jeden potrzebuje więcej — wszystko z konsoli, z zerową zmianą kodu aplikacji.
Wszystko tutaj wiąże się z twoją przestrzenią roboczą i jest konfigurowane z konsoli. Twoja aplikacja dalej woła https://api.orcarouter.ai/v1/chat/completions kluczem sk-orca-... każdego dzierżawcy — zmienia się tylko polityka w bramie. Akcje konfiguracji wymagają ról wskazanych przy każdym kroku; tylko wywołania relay /v1/* używają klucza dzierżawcy.

​
1. Model bezpieczeństwa AI w środowisku wielodzierżawcowym

Brama wielodzierżawcowa ma inny kształt zagrożeń niż pojedyncza aplikacja. Ryzyka, które mają znaczenie, skalują się z liczbą dzierżawców:

Wyciek klucza = promień rażenia jednego dzierżawcy

Wyciekły klucz dzierżawcy nie powinien móc osuszyć twojego konta, wołać modeli, których nigdy nie udostępniłeś, ani sięgać poza budżet tego dzierżawcy.

Przeciek danych między dzierżawcami

PII jednego dzierżawcy lądujące w dzielonych logach lub w odpowiedzi skierowanej do innego dzierżawcy łamie twoją obietnicę izolacji danych.

Hałaśliwy agent dzierżawcy

Agent jednego dzierżawcy zapętlający się na narzędziu lub pobierający dowolne hosty nie powinien degradować bramy dla wszystkich pozostałych.

Zgodność per dzierżawca

Regulowany dzierżawca może potrzebować maskowania PII i rezydencji danych, których reszta twoich dzierżawców nie potrzebuje.
Poniższy model to dwie warstwy: baza przestrzeni roboczej, którą każdy klucz dzierżawcy dziedziczy, plus zakres i nadpisania per klucz, które zaostrzają jednego dzierżawcę bez dotykania pozostałych. Zobacz zakres kluczy, polityk, przestrzeni roboczych dla pełnych reguł rozwiązywania.

​
2. Baza: jedna polityka przestrzeni roboczej, którą każdy dzierżawca dziedziczy

Napisz swoją postawę bezpieczeństwa raz na poziomie przestrzeni roboczej, aby każdy klucz dzierżawcy dziedziczył ją domyślnie — bez duplikacji per dzierżawca.
1

Domyślny guardrail

W Guardrails → New guardrail napisz jedną nazwaną politykę (np. tenant-baseline) i oznacz ją jako domyślną przestrzeni roboczej (is_default). Dodaj regułę PII, etap input, akcja mask, aby żadne żądanie dzierżawcy nie niosło surowego PII do dostawcy nadrzędnego:
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
Każdy klucz dzierżawcy z brakiem wyraźnego dołączenia guardrailu wraca do tej domyślnej. Tworzenie guardrailu wymaga roli Developer.
2

Domyślna polityka firewalla

Jeśli twoi dzierżawcy uruchamiają agenty, zrób to samo na płaszczyźnie akcji: w Firewall → Policies napisz domyślną politykę lub — szybciej — otwórz Firewall → Posture i zastosuj poziom autonomii balanced (poziom autonomii). To audytuje wywołania narzędzi każdego dzierżawcy i flaguje PII w całej przestrzeni roboczej, jednocześnie odmawiając najbardziej destrukcyjnych akcji, więc obserwujesz prawdziwe zachowanie dzierżawcy przed szerokim egzekwowaniem. Rola Developer.
Wdróż bazę w kolejności obserwuj → cień → egzekwuj, aby nowa reguła nie mogła zepsuć dzierżawcy w locie. Polityka firewalla wspiera flagę shadow_mode per polityka (egzekwujące werdykty logują jako [shadow] would …); zacznij reguły guardrailu na akcji flag. Zobacz tryby egzekwowania.

​
3. Jeden klucz o ograniczonym zakresie per dzierżawca

To rdzeń izolacji dzierżawców: nigdy nie dziel klucza między dzierżawcami i nigdy nie wręczaj dzierżawcy klucza obejmującego całe konto. Wybij jeden klucz per dzierżawca, ograniczony dokładnie do tego, co ten dzierżawca może robić. W API Keys → New key ustaw:
Ustaw credit_limit_usd na pułap tego dzierżawcy (0 = bez limitu). To najważniejsza pojedyncza kontrola wielodzierżawcowa: wyciekły lub nadużyty klucz dzierżawcy może spalić tylko budżet tego dzierżawcy, nigdy twoje konto. Zobacz denial-of-wallet.
Włącz model_limits (model_limits_enabled) i wymień tylko model(e), które obejmuje plan tego dzierżawcy — aby wyciekły klucz nie mógł uruchomić kosztownego modelu, za który dzierżawca nigdy nie zapłacił.
Ustaw environment (dowolna etykieta wdrożenia, np. prod / staging), aby ruch dzierżawcy był atrybuowalny w twoich logach i abyś mógł odróżnić klucze produkcyjne od testowych jednym rzutem oka.
Ustaw allow_ips na IP egress backendu tego dzierżawcy, jeśli woła ze stałego serwera, oraz expired_time dla dzierżawców próbnych lub czasowych (-1 = nigdy nie wygasa).
Każdy klucz dzierżawcy automatycznie dziedziczy guardrail tenant-baseline przestrzeni roboczej i domyślną politykę firewalla — wybiłeś klucz o ograniczonym zakresie, a on już jest zarządzany. Klucz jest maskowany na wyświetleniu po utworzeniu, więc skopiuj go raz, gdy provisionujesz dzierżawcę.

​
4. Nadpisania per dzierżawca — zaostrz jednego bez dotykania reszty

Większość dzierżawców jedzie na bazie. Gdy jeden potrzebuje więcej — regulowany dzierżawca, poziom enterprise, dzierżawca na liście próbnej — dołącz ściślejszą nazwaną politykę tylko do tego klucza:
Ustaw na kluczuEfekt dla tego jednego dzierżawcy
guardrail_idPodmienia na ściślejszy nazwany guardrail (np. block-on-PII).
firewall_policy_idPodmienia na ciaśniejszą politykę firewalla (np. domyślna odmowa narzędzi).
Rozwiązywanie różni się między dwiema płaszczyznami — poznaj różnicę:
Wyraźny guardrail_id (gdy istnieje i jest włączony) zawsze ma zastosowanie i nigdy po cichu nie wraca do domyślnej. Jeśli ten dołączony guardrail jest wyłączony, klucz dostaje brak guardrailu — nie spada do domyślnej przestrzeni roboczej. Pozostaw guardrail_id nieustawione (0/null), aby dziedziczyć domyślną tenant-baseline.
Dołączony firewall_policy_id ma zastosowanie, gdy istnieje i jest włączony; jeśli ta polityka jest wyłączona, klucz wraca do domyślnej polityki firewalla przestrzeni roboczej. (To przeciwieństwo zachowania wyłącznika guardrailu — celowo.)
Edycja nazwanej polityki przesuwa każdy klucz do niej dołączony przy następnym wywołaniu. Jeśli wielu dzierżawców dzieli jedną ściślejszą politykę, edycja trafia ich wszystkich naraz. Użyj odrębnej nazwanej polityki per klasę izolacji, nie jednej gigantycznej dzielonej polityki, gdy dzierżawcy potrzebują naprawdę różnych reguł.

​
5. Konkretny przykład dwupoziomowy

Powiedzmy, że prowadzisz darmowy poziom i regulowany poziom enterprise na jednej przestrzeni roboczej:
  1. Baza przestrzeni roboczej — guardrail tenant-baseline (maska PII na input, block na karcie/SSN) jako is_default, plus poziom autonomii firewalla balanced. Każdy dzierżawca to dziedziczy.
  2. Klucz dzierżawcy darmowego — brak guardrail_id (dziedziczy bazę), model_limits przypięte do openai/gpt-4o-mini, niskie credit_limit_usd.
  3. Klucz dzierżawcy enterprise — guardrail_id ustawione na ściślejszy guardrail enterprise-pii (PII block, nie maska, na input; secrets block na etapie output), firewall_policy_id z ciaśniejszą listą dozwolonych narzędzi, wyższy limit kredytu i allow_ips przypięte do ich backendu.
Oba poziomy wołają ten sam endpoint /v1/chat/completions własnym kluczem. Brama rozwiązuje właściwą politykę per klucz — twój kod aplikacji jest identyczny dla każdego dzierżawcy.

​
6. Zgodność i rezydencja per dzierżawca

Regulowany dzierżawca często potrzebuje poświadczenia, którego reszta nie potrzebuje. Zgodność działa jako równorzędna płaszczyzna obok guardrails i firewalla:
  • Przeglądanie katalogu frameworków i gotowości jest otwarte dla każdego Membera i bezpłatne — potwierdź pokrycie dla frameworku, o który pyta dzierżawca (soc2, hipaa, gdpr, iso_27001, pci_dss i więcej).
  • Instalacja paczki (POST /api/compliance/packs/:key/install) materializuje pasujące guardrails i polityki firewalla do twojej przestrzeni roboczej; wymaga Admin przestrzeni roboczej i płatnego planu.
  • Rezydencja danych przypina region artefaktu raportu zgodności (us / eu / uk / ap / cn / global) przez PUT /api/compliance/residency (Admin). Odczyty z innego regionu są wstrzymywane.
Rezydencja tutaj zarządza artefaktem raportu zgodności, nie geo-przypinaniem danych inferencji. Co do historii logów żądań: logi przechowują się przez domyślnie 30 dni (twardo ograniczone do 180), a samodzielne usunięcie konta użytkownika uruchamia 30-dniową karencję, potem szorowanie PII, które kaskaduje do dopasowań guardrailu i logów żądań tego użytkownika.
Dla pełnego audytowanego przebiegu dowodów zobacz wygeneruj dowody SOC 2 oraz wdróż dla HIPAA.

​
7. Obserwuj każdego dzierżawcę z jednej przestrzeni roboczej

Cała obserwowalność jest w zakresie przestrzeni roboczej, więc jeden zestaw strumieni pokrywa wszystkich twoich dzierżawców — filtrowalny w dół do jednego:
  • Guardrails → Matches (każdy Member) — każda reguła, która odpaliła u wszystkich dzierżawców: typ, akcja, etap, szczegół. Dopasowany podłańcuch jest rejestrowany tylko wtedy, gdy Log raw content jest włączony dla tego guardrailu (domyślnie wyłączony — postawa konserwatywna względem prywatności, która ma największe znaczenie w środowisku wielodzierżawcowym). Oznacz fałszywie dodatni, aby stroić (Admin).
  • Firewall → Events / Runs (Developer+) — każde wywołanie narzędzia, zwinięte per uruchomienie agenta, więc pętla hałaśliwego dzierżawcy lub nowy egress się wyróżnia.
  • Strumień anomalii (Member) — skoki tempa/kosztu oceniane wobec wyuczonej bazowej linii godziny-tygodnia wychwytują jednego dzierżawcę spalającego poza wzorcem nawet, gdy każde wywołanie z osobna jest dozwolone.
Zablokowane żądanie zwraca HTTP 400 (guardrail_blocked / firewall_blocked), kosztuje tego dzierżawcę zero kwoty i jest oznaczone jako skip-retry — granica utrzymała się bez obciążania dzierżawcy za odrzucenie.

​
8. Gdzie pogłębić

Zakres kluczy, polityk, przestrzeni roboczych

Pełna kolejność rozwiązywania dla dołączenia klucza i domyślnych przestrzeni roboczej.

Referencja Guardrails

Każdy typ reguły, encja PII i nadpisanie per encja w całości.

Referencja Firewall

Werdykty, powierzchnie, poziomy autonomii i płaszczyzna polityki.

Zatrzymaj eksfiltrację danych

Zablokuj egress wychodzący agenta dzierżawcy.