Das Regeldokument¶

Das Regeldokument enthält die Regeln, die für jedes aktive Mitglied Ihrer Organisation gelten, neben den Regeln ihrer Rollen. Diese Seite zeigt, wie Sie es lesen und ersetzen. Was das Regeldokument ist, steht unter Rollen und Zugriff.

Das Regeldokument lesen und ersetzen kann org-admin. Auf dem Bildschirm finden Sie es unter Benutzerverwaltung > Regeldokument; diese Seite zeigt die API. Die Beispiele nutzen $OS, $TOKEN und $ORG wie unter Gruppen verwalten.

Wofür Sie es nutzen¶

Jedes Mitglied hat die eingebaute Rolle member, die bereits erlaubt, dass alle die Modelle, Agents, das Wissen und die Tools der Organisation nutzen (was genau). Das Regeldokument dient deshalb vor allem für zwei Dinge:

• Für alle oder einen Teil einschränken. Ein forbid lehnt ab, was jede Rolle auch erlaubt. Ein forbid mit einer Bedingung an die Person betrifft nur, wer diese Bedingung erfüllt, etwa die Mitglieder einer Gruppe.
• Für alle erweitern. Ein permit gilt für jedes Mitglied, zum Beispiel die geteilten Gespräche der eigenen Abteilung sehen.

Was nur für manche Mitglieder gilt, gehört meist besser in eine eigene Rolle.

Das Dokument lesen¶

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

Die Antwort hat rules, die Regeln, und version, die auch im Header ETag steht. Eine Organisation, die das Dokument noch nie geschrieben hat, hat ein leeres Dokument mit Version 0.

Das Dokument ersetzen¶

Sie ersetzen das Dokument als Ganzes: Senden Sie alle Regeln, die bleiben sollen, plus Ihre Änderung. Nennen Sie in If-Match die Version, die Sie gelesen haben, beim ersten Mal "0".

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": "no-expensive-model", "effect": "forbid", "kind": "model",
           "match": {"names": ["gpt-5*"]}},
          {"id": "interns-no-finance-agents", "effect": "forbid", "kind": "agent",
           "match": {"labels": {"department": "finance"}},
           "when": [{"atom": "attribute_has", "attribute": "group", "value": "grp_..."}]}
        ]}'

Die erste Regel verbietet allen jedes Modell, dessen Name mit gpt-5 beginnt. Die zweite verbietet den Mitgliedern einer Gruppe (hier den Praktikanten, per ID) jeden Agent mit dem Label department: finance. Wie Sie Regeln schreiben, steht unter Arten und Aktionen.

Nach einem Ersetzen gelten die neuen Regeln sofort für die Verwaltung in OS. In den KI-Funktionen gelten sie, sobald OS sie dort übernommen hat; das geschieht im Hintergrund, kurz nach Ihrer Änderung.

Für die ganze Organisation¶

Regeln über memory_write (Gedächtnis schreiben), share_link (Teilen über einen Link), artifact_download (Dateien herunterladen, die ein Tool erstellt hat), router (Modell-Router) und egress_host (externe Adressen) gelten für alle gleichzeitig. Sie haben keine Bedingung an die Person (when) und stehen nur im Regeldokument, nie in einer Rolle.

Modell-Router und das Herunterladen von Dateien, die ein Tool erstellt hat, erreicht standardmäßig jedes Mitglied. Gedächtnis schreiben und Teilen über einen Link erreichen niemanden, bis das Regeldokument sie erlaubt; dann erreichen sie alle. Ein solches permit schreiben Sie nur, wenn Sie es selbst haben: org-admin und operator haben es. So schalten Sie Gedächtnis schreiben für die ganze Organisation ein:

{"id": "memory-on", "effect": "permit", "kind": "memory_write"}

Nehmen Sie die Regel zwischen die Regeln auf, die Sie schon hatten, und ersetzen Sie das Dokument wie oben. Entfernen Sie sie, ist Gedächtnis schreiben wieder aus.

Ohne permit über egress_host rufen die KI-Funktionen keine einzige externe Adresse auf, auch nicht für API-Tools und Connectors. Jedes permit mit match.names erlaubt die Adressen, die es nennt: einen exakten Hostnamen, oder *. gefolgt von einem Hostnamen für jede Adresse darunter, höchstens 200 Zeichen. Ein forbid nimmt Adressen aus dem weg, was die Permits erlauben. Eine Adresse, die die Umgebung blockiert, bleibt blockiert, auch wenn Sie sie erlauben.

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

Eine Adresse erlauben¶

Um eine Adresse zu erlauben, müssen Sie nicht das ganze Dokument ersetzen:

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 fügt dem Regeldokument ein permit für diese Adresse hinzu (201), oder ändert nichts, wenn das Dokument die Adresse schon erlaubt (200). GET …/allowed-hosts zeigt die Adressen, die das Dokument erlaubt, und DELETE …/allowed-hosts/mcp.example.com entfernt die Regel, die genau diese Adresse nennt. Nur org-admin und operator erlauben eine Adresse. Die Adresse gilt nach wenigen Sekunden.

Was OS prüft¶

• Sie haben, was Sie erlauben. Jedes permit, das Sie hinzufügen, müssen Sie selbst haben (warum). Regeln, die schon im Dokument standen, werden nicht erneut geprüft, Sie können also ein Dokument bearbeiten, das eine Regel enthält, die jemand anderes hinzufügte. Ein forbid schränkt ein und verlangt nur, dass Sie das Dokument ändern dürfen.
• Kein Verbot für die Verwaltung. Ein forbid über organisation, membership, invitation, group, role, rule oder attribute ist nicht möglich.
• Grenzen. Höchstens 500 Regeln und 2.000 Namensmuster zusammen; jede Regel höchstens 200 Namensmuster, 16 Label-Tests und 16 Bedingungen; jede id nur einmal.
• Bekannte Attribute. Eine Bedingung nennt role, group oder ein Attribut, das Ihre Organisation oder eine Organisation darüber festgelegt hat.
• Feste Werte. Eine Bedingung attribute_has auf ein Attribut mit fester Liste muss einen Wert aus dieser Liste nennen, auch wenn eine Organisation über Ihrer das Attribut festlegte.
• Was eine Art nimmt. Jede Art der KI-Funktionen nimmt nur bestimmte Aktionen und Teile einer Regel (welche); eine Regel mit einem anderen Teil lehnt OS ab.

Wenn OS ablehnt¶