Le document de règles¶

Le document de règles contient les règles qui valent pour chaque membre actif de votre organisation, en plus des règles de leurs rôles. Cette page montre comment le lire et le remplacer. Ce qu'est le document de règles est expliqué dans Rôles et accès.

org-admin peut lire et remplacer le document de règles. À l'écran, vous le trouvez sous Gestion des utilisateurs > Document de règles ; cette page montre l'API. Les exemples utilisent $OS, $TOKEN et $ORG comme dans Gérer les groupes.

À quoi il sert¶

Chaque membre a le rôle intégré member, qui permet déjà à tout le monde d'utiliser les modèles, agents, connaissances et outils de l'organisation (ce qui précisément). Le document de règles sert donc surtout à deux choses :

• Restreindre pour tout le monde ou pour une partie. Un forbid refuse, quoi que permette un rôle. Un forbid avec une condition sur la personne ne touche que ceux qui remplissent cette condition, comme les membres d'un seul groupe.
• Étendre pour tout le monde. Un permit vaut pour chaque membre, par exemple voir les conversations partagées de son propre service.

Ce qui ne vaut que pour certains membres se place généralement mieux dans un rôle propre.

Lire le document¶

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

La réponse contient rules, les règles, et version, qui figure aussi dans l'en-tête ETag. Une organisation qui n'a jamais écrit le document a un document vide avec la version 0.

Remplacer le document¶

Vous remplacez le document dans son ensemble : envoyez toutes les règles qui doivent rester, plus votre modification. Indiquez dans If-Match la version que vous avez lue, "0" la première fois.

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_..."}]}
        ]}'

La première règle refuse à tout le monde tout modèle dont le nom commence par gpt-5. La seconde refuse aux membres d'un seul groupe (ici les stagiaires, par identifiant) tout agent portant l'étiquette department: finance. La façon d'écrire des règles figure dans Types et actions.

Après un remplacement, les nouvelles règles valent aussitôt pour la gestion dans OS. Dans les fonctions d'IA, elles valent dès qu'OS les y a appliquées ; cela se fait en arrière-plan, peu après votre modification.

Pour toute l'organisation¶

Les règles sur memory_write (écrire dans la mémoire), share_link (partager par un lien), artifact_download (télécharger des fichiers créés par un outil), router (routeurs de modèles) et egress_host (adresses externes) valent pour tout le monde à la fois. Elles n'ont pas de condition sur la personne (when) et figurent seulement dans le document de règles, jamais dans un rôle.

Les routeurs de modèles et le téléchargement de fichiers créés par un outil sont accessibles par défaut à chaque membre. L'écriture dans la mémoire et le partage par un lien ne sont accessibles à personne tant que le document de règles ne les autorise pas ; ils le sont alors à tout le monde. Vous n'écrivez un tel permit que si vous l'avez vous-même : org-admin et operator l'ont. Voici comment activer l'écriture dans la mémoire pour toute l'organisation :

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

Intégrez la règle parmi celles que vous aviez déjà, et remplacez le document comme ci-dessus. Si vous la retirez, l'écriture dans la mémoire est de nouveau désactivée.

Sans permit sur egress_host, les fonctions d'IA n'appellent aucune adresse externe, ni pour les outils d'API ni pour les connecteurs. Chaque permit avec match.names autorise les adresses qu'il nomme : un nom d'hôte exact, ou *. suivi d'un nom d'hôte pour toute adresse en dessous, 200 caractères au plus. Un forbid retire des adresses de ce que les permits autorisent. Une adresse que l'environnement bloque reste bloquée, même si vous l'autorisez.

{"id": "systeme-de-tickets", "effect": "permit", "kind": "egress_host",
 "match": {"names": ["mcp.example.com"]}}

Autoriser une adresse¶

Pour autoriser une adresse, vous n'avez pas besoin de remplacer tout le document :

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 ajoute un permit pour cette adresse au document de règles (201), ou ne change rien si le document autorise déjà l'adresse (200). GET …/allowed-hosts liste les adresses que le document autorise, et DELETE …/allowed-hosts/mcp.example.com retire la règle qui nomme exactement cette adresse. Seuls org-admin et operator autorisent une adresse. L'adresse s'applique après quelques secondes.

Ce qu'OS vérifie¶

• Vous avez ce que vous autorisez. Chaque permit que vous ajoutez, vous devez l'avoir vous-même (pourquoi). Les règles qui figuraient déjà dans le document ne sont pas revérifiées : vous pouvez donc modifier un document avec une règle qu'un autre a ajoutée. Un forbid restreint et demande seulement que vous puissiez modifier le document.
• Pas de refus sur la gestion. Un forbid sur organisation, membership, invitation, group, role, rule ou attribute n'est pas possible.
• Limites. 500 règles et 2 000 motifs de noms au total ; chaque règle 200 motifs de noms, 16 tests d'étiquette et 16 conditions au maximum ; chaque id une seule fois.
• Attributs connus. Une condition nomme role, group, ou un attribut que votre organisation ou une organisation au-dessus a défini.
• Valeurs fixes. Une condition attribute_has sur un attribut avec une liste fixe doit nommer une valeur de cette liste, même si une organisation au-dessus de la vôtre a défini l'attribut.
• Ce qu'un type accepte. Chaque type des fonctions d'IA n'accepte que certaines actions et certaines parties d'une règle (lesquelles) ; OS refuse une règle avec une autre partie.

Quand OS refuse¶