Skip to main content

openclaw policy

Polecenie openclaw policy jest udostępniane przez dołączoną wtyczkę Policy. Stanowi warstwę zgodności klasy korporacyjnej nad istniejącymi ustawieniami OpenClaw, a nie drugi system konfiguracji. Wymagania definiuje się w pliku policy.jsonc; OpenClaw traktuje aktywny obszar roboczy jako materiał dowodowy; Policy zgłasza odchylenia za pośrednictwem doctor --lint. Policy nie wymusza wywołań narzędzi ani nie modyfikuje zachowania środowiska wykonawczego podczas obsługi żądania oraz nie poświadcza magazynów danych uwierzytelniających poszczególnych agentów, takich jak auth-profiles.json. Policy sprawdza skonfigurowane kanały, serwery MCP, dostawców modeli, zabezpieczenia sieci przed SSRF, dostęp przychodzący i dostęp do kanałów, ekspozycję Gateway oraz zasady dotyczące poleceń węzłów, dostęp agentów do obszaru roboczego, zabezpieczenia piaskownicy, zasady obsługi danych, stan dostawców sekretów i profili uwierzytelniania oraz metadane nadzorowanych narzędzi (TOOLS.md). Należy go używać, gdy obszar roboczy wymaga trwałej, możliwej do sprawdzenia deklaracji, takiej jak „Telegram nie może być włączony” lub „nadzorowane narzędzia muszą deklarować metadane ryzyka i właściciela”. Jeśli potrzebne jest wyłącznie zachowanie lokalne, bez poświadczania ani wykrywania odchyleń, wystarczy zwykła konfiguracja.

Szybki start

Wtyczka pozostaje włączona nawet wtedy, gdy brakuje pliku policy.jsonc, dzięki czemu doctor może zgłosić brakujący artefakt zamiast po cichu pomijać kontrole. Plik policy.jsonc należy utworzyć ręcznie; nie jest generowany na podstawie bieżących ustawień. Każda sekcja najwyższego poziomu jest przestrzenią nazw reguł: kontrola jest uruchamiana tylko wtedy, gdy znajduje się w niej konkretna reguła (nieobsługiwane sekcje lub klucze powodują błąd policy/policy-jsonc-invalid, zamiast być po cichu ignorowane). Minimalny przykład obejmujący wszystkie obsługiwane sekcje:
Uwagi przekrojowe, które nie wynikają bezpośrednio z poniższych tabel reguł:
  • Pominięcie gateway.bind przy jednoczesnym zakazaniu powiązań innych niż local loopback oznacza akceptację wartości domyślnej środowiska wykonawczego; aby zapewnić ścisłą zgodność, ustaw gateway.bind: "loopback".
  • W przypadku agenta z dostępem tylko do odczytu ustaw mode piaskownicy na all lub non-main w odpowiednich ustawieniach domyślnych albo ustawieniach agenta, a workspaceAccess na none lub ro. Brak trybu piaskownicy lub ustawienie go na off nie spełnia zasad dostępu tylko do odczytu.
  • agents.workspace.denyTools przyjmuje wartości exec, process, write, edit, apply_patch. Grupy blokowania narzędzi w konfiguracji: group:fs (modyfikowanie plików) i group:runtime (powłoka/procesy) spełniają równoważne wymagania.
  • Kontrole zatwierdzania wykonywania odczytują aktywny artefakt exec-approvals.json tylko wtedy, gdy istnieje reguła execApprovals; brakujący lub nieprawidłowy artefakt stanowi niemożliwy do zaobserwowania materiał dowodowy, a nie domniemane zaliczenie kontroli.
  • Materiał dowodowy dotyczący sekretów i profili uwierzytelniania rejestruje wyłącznie stan dostawcy lub źródła oraz metadane SecretRef, nigdy wartości nieprzetworzone. Policy nie odczytuje ani nie poświadcza magazynów danych uwierzytelniających poszczególnych agentów, takich jak auth-profiles.json.
  • Materiał dowodowy dotyczący obsługi danych obejmuje wyłącznie stan na poziomie konfiguracji (tryb redagowania, przełącznik przechwytywania telemetrii, tryb utrzymania sesji, ustawienie indeksowania transkrypcji). Nie sprawdza logów, eksportów telemetrii, transkrypcji ani plików pamięci, a poprawny wynik nie dowodzi, że nie zawierają one danych osobowych ani sekretów.

Dokumentacja reguł Policy

Każda poniższa reguła jest opcjonalna; kontrola jest uruchamiana tylko wtedy, gdy reguła jest obecna. Obserwowany stan pochodzi z istniejącej konfiguracji OpenClaw lub metadanych obszaru roboczego.

Nakładki o ograniczonym zakresie

Użyj scopes.<scopeName>, gdy określeni agenci lub kanały wymagają bardziej rygorystycznych zasad niż bazowe zasady najwyższego poziomu. Nazwa zakresu jest tylko etykietą; dopasowywanie odbywa się przy użyciu selektora wewnątrz zakresu. Nakładki są addytywne: reguła globalna nadal jest uruchamiana, a reguła zakresowa może dodać własne ustalenie na podstawie tego samego materiału dowodowego. Jeśli wpis agentIds nie występuje w agents.list[], OpenClaw ocenia regułę zakresową względem odziedziczonego globalnego lub domyślnego stanu dla tego identyfikatora agenta środowiska wykonawczego, zamiast ją pomijać.
Ten sam agent może występować w wielu zakresach, jeśli każdy zakres nadzoruje inne pole, jak w powyższym przykładzie. Powtórzone pole zakresowe dotyczące tego samego agenta musi być równie lub bardziej restrykcyjne; słabsza, powielona deklaracja jest odrzucana (listy dozwolonych wartości muszą być podzbiorami, listy zabronionych wartości — nadzbiorami, a wymagane wartości logiczne są stałe). Reguły stanu kontenerów (sandbox.containers.*) są sprawdzane wyłącznie względem materiału dowodowego, który może udostępnić backend piaskownicy dopasowanego agenta. Jeśli backend nie może obserwować włączonej dla niego reguły, Policy zgłasza policy/sandbox-container-posture-unobservable zamiast zaliczyć kontrolę; reguły kontenerów należy ograniczyć do grup agentów, które korzystają z backendu zdolnego je udostępnić. Reguła najwyższego poziomu ingress.session.requireDmScope pozostaje globalna; session.dmScope nie stanowi materiału dowodowego, który można przypisać do kanału, dlatego nie można ograniczyć jej za pomocą channelIds. Każdy zakres obecny w policy.jsonc musi być prawidłowy i możliwy do wyegzekwowania.

Kanały

Serwery MCP

Dostawcy modeli

Sieć

Dostęp przychodzący i dostęp do kanałów

Gateway

gateway.nodes.denyCommands jest dokładną, uwzględniającą wielkość liter regułą nadzbioru zakazów. Użyj jej, gdy zasady muszą wykazywać, że uprzywilejowane polecenia węzła są jawnie zabronione przez konfigurację OpenClaw. Wdrożenie, które celowo zezwala na uprzywilejowane polecenie węzła, powinno po przeglądzie zaktualizować policy.jsonc, zamiast polegać wyłącznie na gateway.nodes.allowCommands.

Obszar roboczy agenta

Stan piaskownicy

Zasady traktują brak sandbox.mode jako jego niejawne ustawienie domyślne off, dlatego sandbox.requireMode zgłasza nową lub nieskonfigurowaną piaskownicę jako nienależącą do listy dozwolonych, takiej jak ["all"].

Obsługa danych

Sekrety

Zatwierdzenia wykonywania

Kontrole zatwierdzeń wykonywania odczytują artefakt środowiska uruchomieniowego exec-approvals.json: domyślnie ~/.openclaw/exec-approvals.json lub $OPENCLAW_STATE_DIR/exec-approvals.json, gdy ustawiono OPENCLAW_STATE_DIR. Reguły stanu w execApprovals.defaults.* lub execApprovals.agents.* wymagają dowodu w postaci możliwego do odczytania artefaktu; brakujący lub nieprawidłowy artefakt jest zgłaszany jako dowód niemożliwy do zaobserwowania, zamiast uzyskiwać akceptację na zasadzie najlepszej próby. Gdy artefakt jest możliwy do odczytania, pominięte pola dziedziczą wartości domyślne środowiska uruchomieniowego: brak defaults.security oznacza full, a brak zabezpieczeń agenta powoduje odziedziczenie tej wartości domyślnej. Dowód obejmuje defaults, agents.*, agents.*.allowlist[].pattern, opcjonalne argPattern, efektywny stan autoAllowSkills oraz źródło wpisu — nigdy ścieżkę ani token gniazda, commandText, lastUsedCommand, rozpoznane ścieżki ani znaczniki czasu. Przykład: wymagaj artefaktu zatwierdzeń, zabroń liberalnych wartości domyślnych i zezwalaj tylko na zatwierdzony stan zatwierdzania wykonywania dla wybranych agentów.

Profile uwierzytelniania

Metadane narzędzi

Tryb narzędzi

Uruchamianie kontroli

Podczas tworzenia uruchamiaj kontrole ograniczone do polityki:
Polecenie policy check uruchamia wyłącznie zestaw kontroli polityki i generuje materiał dowodowy, ustalenia oraz skróty poświadczenia. Te same ustalenia pojawiają się również w wyniku polecenia openclaw doctor --lint, gdy Plugin Policy jest włączony. Porównaj plik polityki operatora z utworzoną konfiguracją bazową:
Polecenie policy compare sprawdza składnię pliku polityki względem składni pliku polityki; nie sprawdza stanu środowiska uruchomieniowego, materiału dowodowego, danych uwierzytelniających ani sekretów. Używa tych samych metadanych reguł, które zarządzają nakładkami zakresowymi: listy dozwolonych muszą pozostać takie same lub węższe, listy blokowanych muszą pozostać takie same lub szersze, wymagane wartości logiczne muszą zachować swoją wartość, uporządkowane ciągi mogą przesuwać się wyłącznie w kierunku bardziej restrykcyjnego końca skonfigurowanej kolejności, a dokładne listy muszą być zgodne. Konfiguracja bazowa może być polityką utworzoną przez organizację; sprawdzana polityka może dodawać bardziej restrykcyjne wartości lub dodatkowe reguły. Reguła najwyższego poziomu w sprawdzanej polityce może spełniać zakresową regułę bazową, jeśli jest równie restrykcyjna lub bardziej restrykcyjna. Nazwy zakresów nie muszą być zgodne między plikami; porównanie jest kluczowane według selektora (agentIds/channelIds) i pola. Pomyślne porównanie (--json):
Pomyślny wynik policy check --json zawiera stabilne skróty, które operator lub system nadzorujący może zapisać:

Konfigurowanie polityki

Konfiguracja polityki znajduje się w plugins.entries.policy.config.
Ustaw plugins.entries.policy.config.enabled na false, aby wyłączyć kontrole polityki dla obszaru roboczego, pozostawiając Plugin zainstalowany.

Akceptowanie stanu polityki

Przykładowy wynik JSON:
attestation.policy.hash identyfikuje utworzony artefakt reguł. Pole evidence rejestruje obserwowany stan OpenClaw użyty przez kontrole, a workspace.hash identyfikuje ten ładunek materiału dowodowego. findingsHash identyfikuje dokładny zestaw ustaleń. checkedAt rejestruje czas uruchomienia kontroli. attestationHash identyfikuje stabilne oświadczenie (skrót polityki, skrót materiału dowodowego, skrót ustaleń oraz stan pomyślny/niepomyślny) i celowo wyklucza checkedAt, dzięki czemu ten sam stan polityki zawsze generuje ten sam skrót poświadczenia. Te cztery wartości razem tworzą krotkę audytową pojedynczej kontroli polityki. Jeśli Gateway lub system nadzorujący używa polityki do blokowania, zatwierdzania lub opisywania działania środowiska uruchomieniowego, powinien zapisać skrót poświadczenia z ostatniej pomyślnej kontroli. Pole checkedAt pozostaje w wyniku JSON na potrzeby dzienników audytu, ale nie jest częścią stabilnego skrótu. Cykl akceptowania stanu polityki:
  1. Utwórz lub zweryfikuj policy.jsonc.
  2. Uruchom openclaw policy check --json.
  3. Jeśli kontrola zakończy się pomyślnie, zapisz attestation.policy.hash jako expectedHash.
  4. Zapisz attestation.attestationHash jako expectedAttestationHash.
  5. Ponownie uruchom openclaw doctor --lint w CI lub bramkach wydania.
Jeśli reguły zasad zmieniono celowo, zaktualizuj oba akceptowane skróty na podstawie czystego sprawdzenia. Jeśli zmieniają się tylko ustawienia obszaru roboczego (zasady pozostają bez zmian), zwykle zmienia się tylko expectedAttestationHash. Włączenie lub uaktualnienie reguł agents.workspace dodaje dowody agentWorkspace do skrótu obszaru roboczego i skrótu atestacji; po włączeniu przejrzyj nowe dowody i odśwież akceptowane skróty atestacji. Włączenie lub uaktualnienie reguł stanu narzędzi dodaje dowody toolPosture w ten sam sposób. Polecenie openclaw policy watch ponownie uruchamia sprawdzenie i zgłasza, gdy bieżące dowody przestają odpowiadać wartości expectedAttestationHash:
Użyj --once w CI lub skryptach wymagających pojedynczej oceny rozbieżności. Bez --once polecenie domyślnie odpytuje co dwie sekundy; użyj --interval-ms, aby zmienić interwał.

Ustalenia

Ustalenie może zawierać zarówno pole target (zaobserwowany element obszaru roboczego, który nie jest zgodny), jak i requirement (zdefiniowaną regułę, która spowodowała utworzenie ustalenia). Obecnie oba są ciągami adresowymi oc://, ale nazwy pól opisują rolę w zasadach, a nie format adresu. Przykładowe ustalenia:

Naprawa

doctor --lint i policy check działają tylko do odczytu. doctor --fix edytuje ustawienia przestrzeni roboczej zarządzane przez zasady tylko wtedy, gdy opcja workspaceRepairs jest jawnie włączona; w przeciwnym razie kontrole zgłaszają, co zostałoby naprawione, i pozostawiają ustawienia bez zmian. W tej wersji naprawa może wyłączać kanały zabronione przez channels.denyRules oraz stosować wymienione poniżej automatyczne naprawy zawężające. Włącz opcję workspaceRepairs dopiero po sprawdzeniu pliku zasad, ponieważ prawidłowa reguła może zmienić konfigurację przestrzeni roboczej:
  • ustawić tools.elevated.enabled=false, gdy zasady globalne zabraniają narzędzi z podwyższonymi uprawnieniami
  • dodać brakujące identyfikatory narzędzi, których użycie musi być zabronione, do tools.deny lub agents.list[].tools.deny, gdy zasady wymagają zablokowania tych narzędzi
  • ustawić niezabezpieczone przełączniki gateway.controlUi.* na false
  • ustawić gateway.mode=local, gdy zasady zabraniają zdalnego trybu Gateway
  • ustawić zgłoszone ścieżki gateway.http.endpoints.*.enabled na false, gdy zasady zabraniają punktów końcowych HTTP API Gateway
  • ustawić zgłoszone ścieżki przychodzącego ruchu kanału groupPolicy na allowlist, gdy zasady zabraniają otwartego przychodzącego ruchu grupowego
  • ustawić zgłoszone ścieżki przychodzącego ruchu kanału requireMention na true, gdy zasady wymagają wzmianek w grupach
  • ustawić logging.redactSensitive=tools, gdy zasady wymagają redagowania poufnych danych w dziennikach
  • ustawić diagnostics.otel.captureContent=false albo diagnostics.otel.captureContent.enabled=false dla ustawień przechwytywania telemetrii w postaci obiektu, gdy zasady zabraniają przechwytywania treści telemetrii
Naprawy narzędzi z podwyższonymi uprawnieniami o ograniczonym zakresie są obsługiwane wyłącznie w trybie wykrywania. Naprawy obsługi danych o ograniczonym zakresie są również pomijane, gdy znalezisko zgłasza współdzieloną konfigurację dzienników lub telemetrii, ponieważ zmiana współdzielonego ustawienia wpłynęłaby na więcej elementów niż tylko cel zasad o ograniczonym zakresie. Naprawy wymaganych blokad o ograniczonym zakresie są pomijane, gdy znalezisko zgłasza odziedziczone główne tools.deny, ponieważ dodanie wymaganego narzędzia do głównej konfiguracji wpłynęłoby na więcej elementów niż tylko cel zasad o ograniczonym zakresie. Lokalne dla agenta naprawy wymaganych blokad mogą aktualizować zgłoszoną ścieżkę agents.list[].tools.deny. Naprawy przychodzącego ruchu kanału o ograniczonym zakresie są pomijane, gdy znalezisko zgłasza odziedziczone channels.defaults.*, ponieważ zmiana współdzielonej wartości domyślnej kanału wpłynęłaby na więcej elementów niż tylko cel zasad o ograniczonym zakresie. Znaleziska listy dozwolonych adresów pobierania URL przez HTTP Gateway wymagają ręcznej naprawy, ponieważ automatyczna naprawa nie może wybrać prawidłowych wartości listy dozwolonych adresów URL punktu końcowego. Znaleziska dotyczące powiązania Gateway i poleceń Node nadal wymagają sprawdzenia. Gdy policy/gateway-non-loopback-bind lub policy/gateway-node-command-denied można przypisać do ścieżki konfiguracji, doctor --fix zgłasza proponowaną zmianę gateway.bind lub gateway.nodes.denyCommands jako pominięty podgląd wskazówek. Nie stosuje tej zmiany, a znalezisko nie jest uznawane za naprawione, dopóki operator nie sprawdzi i nie zaktualizuje konfiguracji lub zasad.

Kody wyjścia

Powiązane