Het regeldocument¶

Het regeldocument bevat de regels die voor elk actief lid van je organisatie gelden, naast de regels van hun rollen. Deze pagina laat zien hoe je het leest en vervangt. Wat het regeldocument is, staat in Rollen en toegang.

Het regeldocument lezen en vervangen kan org-admin. Op het scherm vind je het onder Gebruikersbeheer > Regeldocument; deze pagina laat de API zien. De voorbeelden gebruiken $OS, $TOKEN en $ORG zoals in Groepen beheren.

Wat je ermee doet¶

Elk lid heeft de ingebouwde rol member, die al toestaat dat iedereen de modellen, agents, kennis en tools van de organisatie gebruikt (wat precies). Het regeldocument dient daarom vooral voor twee dingen:

• Beperken voor iedereen of voor een deel. Een forbid weigert, wat elke rol ook toestaat. Een forbid met een voorwaarde op de persoon raakt alleen wie die voorwaarde heeft, zoals de leden van één groep.
• Uitbreiden voor iedereen. Een permit geldt voor elk lid, bijvoorbeeld de gedeelde gesprekken van de eigen afdeling zien.

Wat maar voor sommige leden geldt, zet je meestal beter in een eigen rol.

Het document lezen¶

curl -s -i "$OS/api/v1/organisations/$ORG/rules" -H "Authorization: Bearer $TOKEN"

Het antwoord heeft rules, de regels, en version, die ook in de kop ETag staat. Een organisatie die het document nog nooit schreef, heeft een leeg document met versie 0.

Het document vervangen¶

Je vervangt het document in zijn geheel: stuur alle regels die moeten blijven, plus je wijziging. Noem in If-Match de versie die je las, "0" de eerste keer.

curl -s -X PUT "$OS/api/v1/organisations/$ORG/rules" \
    -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
    -H 'If-Match: "0"' \
    -d '{"rules": [
          {"id": "geen-duur-model", "effect": "forbid", "kind": "model",
           "match": {"names": ["gpt-5*"]}},
          {"id": "stagiairs-geen-finance-agents", "effect": "forbid", "kind": "agent",
           "match": {"labels": {"department": "finance"}},
           "when": [{"atom": "attribute_has", "attribute": "group", "value": "grp_..."}]}
        ]}'

De eerste regel weigert iedereen elk model waarvan de naam met gpt-5 begint. De tweede weigert de leden van één groep (hier de stagiairs, bij id) elke agent met het label department: finance. Hoe je regels schrijft, staat in Soorten en acties.

Na een vervanging gelden de nieuwe regels meteen voor beheer in OS. In de AI-functies gelden ze zodra OS ze daar heeft doorgevoerd; dat gebeurt op de achtergrond, kort na je wijziging.

Voor de hele organisatie¶

Regels over memory_write (geheugen schrijven), share_link (delen via een link), artifact_download (bestanden downloaden die een tool maakte), router (modelrouters) en egress_host (externe adressen) gelden voor iedereen tegelijk. Ze hebben geen voorwaarde op de persoon (when) en staan alleen in het regeldocument, nooit in een rol.

Modelrouters en het downloaden van bestanden die een tool maakte, bereikt standaard elk lid. Geheugen schrijven en delen via een link bereiken niemand, tot het regeldocument ze toestaat; dan bereiken ze iedereen. Zo'n permit schrijf je alleen als je hem zelf hebt: org-admin en operator hebben hem. Zo zet je geheugen schrijven aan voor de hele organisatie:

{"id": "geheugen-aan", "effect": "permit", "kind": "memory_write"}

Neem de regel op tussen de regels die je al had, en vervang het document zoals hierboven. Haal je hem weg, dan staat geheugen schrijven weer uit.

Zonder permit over egress_host roepen de AI-functies geen enkel extern adres aan, ook niet voor API-tools en connectors. Elke permit met match.names staat de adressen toe die hij noemt: een exacte hostnaam, of *. gevolgd door een hostnaam voor elk adres eronder, hooguit 200 tekens. Een forbid haalt adressen weg uit wat de permits toestaan. Een adres dat de omgeving blokkeert, blijft geblokkeerd, ook als je het toestaat.

{"id": "ticketsysteem", "effect": "permit", "kind": "egress_host",
 "match": {"names": ["mcp.example.com"]}}

Eén adres toestaan¶

Om één adres toe te staan hoef je niet het hele document te vervangen:

curl -s -X POST "$OS/api/v1/organisations/$ORG/allowed-hosts" \
    -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
    -d '{"host": "mcp.example.com"}'

OS voegt een permit voor dat adres aan het regeldocument toe (201), of verandert niets als het document het adres al toestaat (200). GET …/allowed-hosts toont de adressen die het document toestaat, en DELETE …/allowed-hosts/mcp.example.com haalt de regel weg die precies dat adres noemt. Alleen org-admin en operator staan een adres toe. Het adres geldt na enkele seconden.

Wat OS controleert¶

• Je hebt wat je toestaat. Elke permit die je toevoegt, moet je zelf hebben (waarom). Regels die al in het document stonden, worden niet opnieuw gecontroleerd, dus je kunt een document bewerken met een regel die een ander toevoegde. Een forbid beperkt en vraagt alleen dat je het document mag wijzigen.
• Geen weigering op beheer. Een forbid over organisation, membership, invitation, group, role, rule of attribute kan niet.
• Grenzen. Hoogstens 500 regels en 2.000 naampatronen samen; elke regel hoogstens 200 naampatronen, 16 labeltests en 16 voorwaarden; elk id maar één keer.
• Bekende eigenschappen. Een voorwaarde noemt role, group, of een eigenschap die je organisatie of een organisatie erboven heeft vastgelegd.
• Vaste waarden. Een voorwaarde attribute_has op een eigenschap met een vaste lijst moet een waarde uit die lijst noemen, ook als een organisatie boven de jouwe de eigenschap vastlegde.
• Wat een soort neemt. Elke soort van de AI-functies neemt alleen bepaalde acties en delen van een regel (welke); een regel met een ander deel weigert OS.

Als OS weigert¶