Permissions des nodes
Certains nodes fournis par une intégration installée — Stripe, Sumsub, le module Crédit… — lisent ou écrivent un objet métier dans le cadre de leur propre comportement, au-delà de ce que montrent leurs entrées et sorties. Avant de pouvoir enregistrer un processus qui utilise un tel node, vous devez explicitement autoriser cet accès.
Pourquoi un consentement explicite
La plupart des nodes n'ont besoin d'aucune permission supplémentaire. Quand vous câblez explicitement un node standard à un objet dans l'éditeur — par exemple en reliant la sortie company d'un node à l'entrée d'un autre — ce câblage est lui-même votre autorisation : il est visible dans le graphe et entièrement sous votre contrôle.
Un node fourni par une intégration peut, en revanche, consulter ou modifier un objet métier sans que cela apparaisse dans ses entrées ou sorties déclarées. Par exemple, un node qui décide d'accorder du crédit à une entreprise vérifie et met à jour son exposition de crédit en interne, pas via un paramètre que vous câblez vous-même. Cette opacité justifie un consentement explicite, sur le modèle des permissions d'une application mobile : le node déclare ce qu'il touche, vous acceptez avant que ce soit possible.
Ce consentement fait partie des mécanismes qui encadrent l’accès des intégrations à vos objets métier — voir Accès aux données par les intégrations pour le modèle d’ensemble.
Quand la permission est demandée
- Ajout d'un node depuis la palette ou par glisser-déposer : si le node nécessite un accès qui n'est pas encore accordé pour ce processus, une fenêtre de consentement s'affiche avant que le node soit réellement ajouté au graphe. Refuser annule l'ajout.
- Enregistrement du processus : si le processus contient un node dont l'accès requis n'a pas encore été accordé, l'enregistrement est refusé tant que le consentement n'est pas donné.
- Import ou génération assistée : l'import d'un modèle, la duplication d'un processus ou une génération assistée par IA peuvent introduire plusieurs nodes à la fois. Un écran de consentement groupé récapitule alors chaque permission demandée avant l'enregistrement — voir Import et génération assistée.
Ce que vous autorisez
Une permission porte sur un type d'objet métier (par exemple company, credit_exposure, credit_limit) et un mode d'accès, lecture ou écriture.
Elle est accordée pour un node précis, dans un processus précis. Ajouter un deuxième node du même type dans le même processus ne redemande pas de permission : l'autorisation est partagée par tous les nodes de ce type au sein du processus. Dupliquer un processus ou importer un modèle démarre en revanche sans aucune permission déjà accordée — vous devez consentir à nouveau, indépendamment de ce qui avait été accepté sur le processus d'origine.
Autoriser ou refuser une permission ne demande aucun droit particulier au-delà de celui déjà nécessaire pour modifier la définition de processus concernée.
À ne pas confondre avec l’autorité d’un Agent
Plusieurs mécanismes de sécurité peuvent apparaître dans le même processus, mais ils ne répondent pas à la même question.
| Mécanisme | Question à laquelle il répond |
|---|---|
| Permission de node | Ce node d’intégration peut-il lire ou écrire un objet plateforme en dehors de son câblage explicite ? |
| Tool d’une activité Agent | Quelle capacité l’Agent peut-il appeler pendant ce Run ? Les permissions nécessaires sont dérivées du tool réellement configuré. |
| Consentement de divulgation Agent | Une donnée protégée peut-elle être exposée au modèle en mode raw plutôt que sous sa projection contrôlée ? |
| Classification downgrade | Une donnée protégée peut-elle ressortir ou être stockée avec une classification moins restrictive ? |
Voir Activités, tools et autorité et Protection des données pour ces frontières complémentaires.
Import et génération assistée
Quand une opération introduit plusieurs nodes à la fois — import d'un modèle, duplication, génération assistée par IA — Ormuz n'interrompt pas le flux avec une série de fenêtres successives. Un écran unique récapitule l'ensemble des permissions requises, groupées, mais toujours attribuées à un node précis : vous ne voyez jamais une liste plate de permissions sans savoir quel node les demande.
Accepter cet écran accorde toutes les permissions listées en une seule fois et enregistre le processus. Refuser annule l'opération : le processus n'est pas enregistré avec des nodes dont l'accès n'a pas été autorisé.
Comment la permission est appliquée
Une permission accordée n'est pas une simple mention documentaire : elle est contrôlée à trois moments, jusqu'au point où l'accès a réellement lieu.
- À l'enregistrement — un processus utilisant un node dont l'accès n'est pas autorisé ne peut pas être enregistré.
- Avant chaque exécution du node — le consentement est réévalué à chaque passage, et non figé à la conception.
- Au moment de l'accès — quand le node demande effectivement l'objet, la plateforme revérifie qu'il s'agit bien du node attendu dans le processus en cours, qu'il a déclaré cet accès, que la permission est toujours accordée, et que l'objet appartient au périmètre du processus.
Un node ne peut donc pas accéder à un type d'objet qu'il n'a pas déclaré, ni réutiliser une autorisation accordée à un autre node. Un accès refusé fait échouer l'étape définitivement, sans nouvelle tentative automatique.
Chaque accès de ce type — autorisé comme refusé — laisse une trace exploitable indiquant le processus, l'étape, le node, le type d'objet, le mode d'accès et l'objet visé.
Retirer une permission
Une permission accordée peut être retirée à tout moment. La révocation prend effet immédiatement, dès le prochain accès — y compris pour une exécution de processus déjà en cours, qui échouera sur l'étape concernée.
POST /v1/node-permission-grants/npg_123/revoke
L'historique est conservé : la permission n'est pas effacée mais marquée comme révoquée, avec sa date d'octroi d'origine. Réenregistrer le processus redemandera le consentement.
Attention : retirer une permission n'annule pas les effets déjà produits, et ne supprime pas les correspondances d'objets qui auraient été établies pendant qu'elle était en vigueur. Celles-ci continuent d'autoriser la relecture de leur cible exacte.
Consulter les permissions accordées
Les permissions actuellement en vigueur pour un processus sont disponibles via l'API, avec les mêmes droits que ceux nécessaires pour lire ou modifier la définition de processus concernée.
GET /v1/node-permission-grants?process_definition_id=prd_123
Seules les permissions en vigueur sont retournées : une permission révoquée n'apparaît plus dans cette liste.
Chaque entrée retournée a la forme suivante.
| Champ | Description |
|---|---|
node_id | Identifiant du type de node concerné (par exemple credit.grant_credit). |
platform_object | Type d'objet métier autorisé (company, credit_exposure…). |
access | read ou write. |
granted_at | Date d'octroi de la permission. |
source | Origine de l'octroi enregistrée avec le grant. Les consentements créés via les surfaces publiques actuelles utilisent consent. |
Le consentement peut aussi être enregistré par API plutôt que depuis la Console :
POST /v1/node-permission-grants
{
"process_definition_id": "prd_123",
"grants": [
{
"node_id": "credit.grant_credit",
"object": "credit_exposure",
"access": "write"
}
]
}Pour un processus qui n'existe pas encore, les permissions requises peuvent être envoyées directement dans le corps de POST /v1/processes ou de sa mise à jour, sous le champ node_permission_grants, avec la même forme { node_id, object, access }.