Sari la conținut

Configurează guardrail-urile

Acest ghid arată cum să configurezi guardrail-urile: regulile care decid dacă acțiunea unui agent rulează, cere mai întâi o aprobare sau este refuzată.

Guardrail-urile acoperă cele treisprezece clase de efect pe care le declară fiecare instrument care modifică starea. Ele se aplică pe server, în momentul în care instrumentul este apelat, niciodată printr-o instrucțiune dintr-un prompt.

  1. Mergi la Setări → Spațiu de lucru → Permisiuni agent
  2. Alege un domeniu de aplicare cu controlul segmentat: Spațiu de lucru, Agent (apoi alege agentul) sau Spațiu (apoi alege spațiul)
  3. Pe rândul clasei de acțiune, alege Permite, Întreabă întâi sau Refuză
  4. Pentru a elimina o regulă pe care ai setat-o, apasă butonul de resetare care apare la sfârșitul acelui rând (Revino la moștenit) — decizia revine la domeniul mai larg

Fiecare rând arată decizia efectivă ca etichetă de stare și un badge pentru de unde provine: Acest domeniu, Moștenit sau Implicit încorporat. Matricea se rezolvă în modul Agent (chat), așa că Presetare de mod nu apare niciodată aici — folosește sonda „ce-ar fi dacă” cu un mod doar pentru citire selectat ca să vezi acel strat.

Scrierea unei reguli necesită rolul admin. Citirea matricei, nu.

Punct de control: setează Push către un remote pe Refuză la domeniul spațiului de lucru, apoi rulează sonda „ce-ar fi dacă” de mai jos pe git push origin main. Rezultatul arată deny cu sursa workspace.

Rezolvarea este întâi după specificitate, apoi după restrictivitate:

  1. Regulile de spațiu, apoi cele de agent, apoi cele de spațiu de lucru. Primul domeniu cu o regulă potrivită decide, iar rezolvarea se oprește
  2. Dacă nicio regulă nu se potrivește, se aplică presetarea de mod — un mod doar pentru citire (Plan, Revizuire, Orchestrează) refuză unsprezece dintre cele treisprezece clase
  3. Dacă modul nu are nimic de spus, se aplică implicitul încorporat

În interiorul unui singur domeniu, o regulă de comandă se rezolvă după cel mai lung prefix care se potrivește, iar un conflict la fel de specific se rezolvă cât mai restrictiv — refuzul învinge întrebarea întâi, care învinge permiterea. O acțiune care declară mai multe clase le rezolvă pe fiecare independent, apoi le combină cât mai restrictiv.

O decizie Întreabă întâi afișează o singură cerere de aprobare care acoperă toate clasele rezolvate în prompt. Fără un aprobator conectat, este refuzată, atât pentru comenzile shell, cât și pentru apelurile de instrumente ale harness-ului. Acest lucru este deliberat: o rulare necontrolată este mai rea decât una refuzată.

Clasă de acțiune Implicit încorporat
Șterge un fișier Întreabă întâi
Scrie în afara worktree-ului Permite
Creează un commit Permite
Push către un remote Întreabă întâi
Deschide un pull request Întreabă întâi
Publică o revizuire sau o fuziune Întreabă întâi
Scrie într-un tracker extern Întreabă întâi
Accesează rețeaua Permite
Citește un secret Permite
Instalează un pachet Permite
Rulează un proces Permite
Modifică structura spațiului de lucru Permite
Conduce un mediu izolat (stație) Permite

Taxonomia este închisă. Un instrument nou care ajunge în producție fără să-și declare clasele pică un test cu clichet în CI, așa că nimic nu sosește cu un set de efecte gol în silențiu.

Înainte de a schimba o regulă, verifică modul în care politica actuală o rezolvă deja.

  1. Pe aceeași pagină, derulează până la Ce-ar fi dacă?
  2. Alege o Acțiune (una dintre cele treisprezece clase)
  3. Completează opțional Comandă (de exemplu git push origin main), Agent, Spațiu și Mod
  4. Citește rezultatul: decizia, motivul și Sursă:

Sonda rulează același rezolvitor pe care îl folosește calea de aplicare, împotriva regulilor tale active, așa că răspunsul este exact. Dacă te surprinde, schimbă o regulă în matricea de mai sus și sondează din nou.

Cadranul este per agent per spațiu și se compune cu regulile, în loc să le înlocuiască.

  1. Deschide spațiul
  2. Deschide Gestionează participanții din antetul spațiului
  3. La Autonomie, pe rândul agentului, alege un nivel:
Nivel Efect
Implicit Nicio setare de spațiu — se comportă ca Acționează cu aprobare
Doar propune Fiecare instrument controlat este refuzat direct, cu un mesaj care îi spune agentului să propună acțiunea în schimb
Acționează cu aprobare Acțiunile riscante ajung la poarta de aprobare cu închidere la eșec
Acționează liber Pre-aprobă orice nu s-a rezolvat într-un refuz strict

Cadranul ajunge doar la harness-ul încorporat. Adaptorul Claude Code își rulează propriile instrumente în afara acestei porți.

Tabelul Unde sunt aplicate regulile din partea de jos a aceleiași pagini este versiunea din aplicație a acestui lucru: pentru fiecare clasă de efect, spune dacă fiecare runner o prinde la poarta de politică, o lasă în seama sandbox-ului sau nu o poate intercepta deloc.

  • Adaptorul Claude Code este controlat doar parțial pentru propriile apeluri de instrumente. Claude Code este lansat cu --dangerously-skip-permissions, așa că apelurile lui de citire, scriere și editare nu trec niciodată prin gardă. Comenzile lui bash ajung la ea printr-un hook care clasifică linia de comandă, iar push-urile lui trec prin gateway-ul de push ca ale oricărui agent. Sunt controlate și suprafața de instrumente MCP în care apelează înapoi și comanda shell pe care Control Center o pornește ca să îl lanseze.
  • Verbul de ieșire propriu al unui mod (submit_plan, propose_orchestration) este fixat și nu poate fi niciodată refuzat — altfel un mod ar fi structural incapabil să își producă singurul livrabil.
  • Dacă sandbox-ul susține aceste reguli depinde de gazdă. Acolo unde cc_server găsește un backend, el învelește CLI-ul Claude Code și instrumentul bash al harness-ului, așa că o regulă pe care nu ai scris-o are totuși un prag de sistem de operare sub ea. Pe Windows nu există niciunul, iar pe Linux sau WSL2 fără bwrap și socat nu există niciunul — acolo, guardrail-urile plus suprafața de instrumente a modului sunt întreaga aplicare, nu o a doua linie a ei. Verifică în ce situație te afli cu Configurează politicile de sandbox.