guardrails-md: en beslutsmodell i hooken

Eve Chen
Eve Chen

Infrastruktur- och plattformsingenjör

guardrails-md: en beslutsmodell i hooken

En kodagent med tillgång till Bash kan förstöra din databas, skriva ut dina hemligheter eller strunta i ditt teams regler, allt medan den följer instruktioner. guardrails-md, som släpps idag som öppen källkod, är en gate som poängsätter varje kommando mot repots GUARDRAILS.md innan något körs. När ett kommando hamnar över tröskeln blockeras anropet och agenten får veta varför, så att den kan välja en annan väg. Bedömningen tar cirka 100 ms.

Den två minuter långa förklaringsvideon ovan visar hela pipelinen, och den korta versionen följer nedan.

Pipelinen

Vid sessionsstart läser gaten GUARDRAILS.md en gång (bara de första 2 000 tecknen) och fryser den. Agenten får redigera filen senare som vilken fil som helst, men ändringen träder i kraft först nästa session, efter att ha granskats som vilken annan ändring som helst.

När agenten anropar Bash fångar hooken kommandot innan något körs. Den bygger en statustext: själva kommandot, innehållet i de skriptfiler det pekar på, och de frysta guardrailsen. Sedan ställer den fyra fasta frågor till beslutsmodellen, i ett enda anrop:

  • destructive. Förstör kommandot data, databaser eller infrastruktur oåterkalleligt?
  • credentials. Innehåller, skriver ut eller skickar det hemligheter, nycklar eller tokens?
  • guardrails_violation. Bryter det mot teamets GUARDRAILS.md?
  • policy_exception. Nämner guardrailstexten uttryckligen det här kommandot som tillåtet?

Varje svar är en poäng mellan 0 och 1 som jämförs mot ett tröskelvärde (0,7 som standard). När poängen ligger över tröskeln blockeras anropet och skälet returneras till agenten som verktygets resultat:

SystemOne-gate: blocked command — destructive=0.98 > 0.7
  rm -rf ./important-data

Varför en beslutsmodell

En mönsterbaserad blocklista känner till rm -rf, men inte din policy. Att be en andra LLM granska varje kommando känner till policyn, men kan övertalas, och kostar en hel generering per kommando. Gaten använder i stället berget/bev, den System One-beslutsmodell vi beskrev när vi lanserade System One: fasta frågor in, poäng ut, ett enda framåtpass. Avgörande är att den bedömer kommandot och reglerna, aldrig konversationen som ledde till dem. Vad den styrande modellen än har övertalats om ser gaten kommandot för vad det är.

Delarna som inte förhandlar

  • Destructive och credentials är skyddsnätet. En guardrails_violation kan hävas genom att kommandot namnges i MAY-avsnittet i GUARDRAILS.md; destructive och credentials kan inte hävas, vad filen än säger.
  • Att försöka igen kostar eftersom varje blockering fördubblar väntan före nästa bedömning: några sekunder i början, en och en halv timme vid den tjugonde blockeringen. Varianter av samma kommando hjälper inte.
  • Gaten stänger vid fel, och det är medvetet: kan ändpunkten inte nås blockeras kommandon tills den svarar igen. Interaktiva användare kan välja bort det med SYSTEMONE_FAIL_OPEN=1. Ingen snabbväg, ingen prefix-lista, ingen override-fil som agenten skulle kunna skriva.
  • Vissa filer är helt skyddade: filredigeringsverktygen vägrar röra GUARDRAILS.md och harnessens konfiguration. Vägran är deterministisk: inget modellanrop, inget tröskelvärde, ingen nedkylning.

Undantagen tillhör människan

För att ändra policyn redigerar du GUARDRAILS.md i en pull request; det är den varaktiga lösningen på en falsk positiv. För att justera gaten höjer du tröskelvärdet. För att köra en session utan den startar du om harnessen med SYSTEMONE_GATE=off. Alla tre är saker en människa gör, och en omstart läser in policyn på nytt och nollställer nedkylningen.

Även vid commit

Samma bedömning fungerar som en git pre-commit hook: varje staged diff poängsätts innan den hamnar i repot. Personuppgifter (GDPR) och hemligheter blockeras; ert teams egna namn i bylines och författarfält går igenom.

De ärliga begränsningarna

Gaten är en tränad modell, inte en regelmotor. Den klarar cirka 96 % av våra held out-tester, men 74 % av red team-kommandona, och den kommer ibland att bedöma ett kommando fel i båda riktningarna, blockera något säkert eller släppa igenom något riskabelt. Den avkodar inte kodade payloads. Behandla den som ett lager bland begränsade rättigheter, sandlådor och mänsklig granskning, inte som en sandlåda. Den fullständiga utvärderingstabellen och metodiken finns i repot.

Testa

Tre steg, ungefär en minut.

  1. Lägg till en GUARDRAILS.md i ditt repo som säger vad ditt team tillåter:

    ## The agent MUST NOT
    
    - Push directly to main
    - Run irreversible operations against shared systems
    
    ## The agent MAY
    
    - Run tests, lint, and builds locally
  2. Installera gaten i din harness:

    • opencode: lägg till "plugin": ["@bergetai/guardrails-md"] i opencode.json
    • pi: kör pi install npm:@bergetai/guardrails-md
    • Claude Code: kör /plugin install guardrails-md --marketplace berget-ai/guardrails-md
  3. Är du redan inloggad på Berget AI i opencode eller pi behövs ingen nyckel. Annars sätter du BERGET_API_KEY och startar om harnessen.

Fullständig installation, konfiguration och pre-commit hooken finns i README:n. Kommandon bedöms av Berget AI:s API, där inget som poängsätts lagras (vi behåller ingen data). Gate-anrop är små nog att €5 i gratis kredit räcker länge.