Politique & catalogue d'outils

Chaque décision que prend la passerelle est l’évaluation d’un bundle de politiques signé (des règles Cedar plus un catalogue d’outils), compilé et publié par le plan de contrôle depuis un checkout git. Refus par défaut de bout en bout.

Le catalogue signé fait foi

Un outil que le bundle ne décrit pas est refusé, même si le serveur MCP l’annonce. Un serveur mis à jour, ou compromis, peut publier de nouveaux outils à tout moment ; s’ils ne sont pas au catalogue, personne n’en a approuvé l’usage.

La découverte est filtrée en conséquence : tools/list, resources/list et prompts/list ne montrent que ce que la politique autorise. Un outil invisible n’est jamais tenté ; autant de refus en moins à traiter, et autant de surface en moins offerte à une injection de prompt.

Règles au niveau des arguments

Les règles au niveau de l’outil ne savent pas dire « send_message, mais seulement vers #support ». Les règles sur les arguments, si. Le catalogue déclare, pour chaque outil, quels arguments la politique peut lire (policy_args : un nom, un pointeur JSON, un type, une valeur par défaut optionnelle) ; la passerelle extrait exactement ceux-là et Cedar les voit comme context.args :

@id("support_channel_only")
forbid (principal, action == Action::"tool_call", resource == Tool::"send_message")
when { context.args.channel != "#support" };

Trois propriétés rendent la chose sûre :

• La liste d’autorisation déclarée est la frontière de confidentialité. Les valeurs existent en mémoire le temps de la décision ; le journal conserve args_hash ; un champ que personne n’a déclaré n’est même jamais lu.
• L’extraction est totale. Chaque argument déclaré arrive extrait, doté de sa valeur par défaut, ou bien l’appel est refusé avant que Cedar ne s’exécute. Une forme d’argument fabriquée est un refus enregistré banal, jamais une erreur d’évaluation. Le mode de défaillance reste réservé aux défaillances de la mécanique propre d’Obsign, hors de portée de l’agent.
• Visibilité et permission sont deux questions différentes. tools/list évalue sans arguments : un outil restreint par argument reste donc visible ; le chemin d’appel est le point d’arbitrage.

Les déclarations d’arguments exigent le format de bundle obsign-policy/2 ; le plan de contrôle n’émet /2 que lorsqu’un outil déclare réellement des arguments, si bien qu’une flotte qui n’utilise jamais la fonctionnalité n’est jamais forcée de mettre la passerelle à niveau.

Des identifiants de règles stables, imposés

Cedar numérote ses règles policy0, policy1… par ordre de fichier. Comme cet identifiant est gravé dans le journal, insérer une règle en tête renommerait silencieusement toutes les suivantes et rendrait faux chaque enregistrement antérieur. Chaque règle doit donc porter une annotation @id("...") ; un bundle où il en manque une est rejeté au chargement.

Ce qui passe encore la barrière

• Les canaux de lecture — resources/read, resources/subscribe et prompts/get déplacent des données exactement comme tools/call : ils passent donc par la même barrière (actions Cedar resource_read, prompt_get, refus par défaut). Les URI de ressources sont forgées à l’exécution, si bien que les politiques correspondent exactement (resource == Resource::"docs://runbook") ou par motif (context.target like "docs://*").
• Les complétions — completion/complete réutilise la capacité de ce qu’elle complète (ref/resource relève de resource_read, ref/prompt de prompt_get) : on ne complète que ce qu’on pourrait lire. Laissée sans arbitrage, elle contournerait le filtre de listage.
• Les canaux initiés par le serveur — sampling/createMessage emprunte le modèle de l’agent ; elicitation/create pose une question à l’humain. Les deux sont arbitrés sous leurs propres actions Cedar, accordées par serveur, refus par défaut. En cas de refus, la passerelle répond au serveur à la place de l’agent, et enregistre la tentative.
• Tout le reste — une liste d’autorisation fixe de mécanique protocolaire (initialize, ping, les découvertes, les notifications définies) est relayée telle quelle ; toute autre méthode est refusée avec -32601 et enregistrée, sans policy_id, de sorte qu’un refus de périmètre se lise différemment d’un refus de règle.