Tables créées par les agents
Lorsqu'un workflow a besoin de persister un état intermédiaire, il peut créer sa propre table gérée — avec une gouvernance renforcée pour maintenir une chaîne de responsabilité claire.
Les workflows ont parfois besoin de persister un état intermédiaire — une liste d'entités dédupliquées, une matrice de scores, un échantillon d'une exécution de longue durée. Scrydon prend en charge cela via les tables gérées créées par les agents, avec une gouvernance renforcée pour maintenir une chaîne d'acteurs auditable.
Le modèle
Une table créée par un agent se comporte exactement comme une table créée par un utilisateur à tous égards (cycle de vie, classifications, masques, filtres de lignes) — avec trois invariants supplémentaires :
| Invariant | Pourquoi |
|---|---|
Le nom de la table doit commencer par agent_ | Visible dans les listes, la recherche et le journal d'audit — vous pouvez toujours identifier les tables créées par un workflow. |
La classification par défaut est confidential | Les workflows ne disposent pas d'une valeur par défaut publique. Un administrateur peut l'abaisser explicitement. |
| Chaque ligne porte des métadonnées d'acteur | actor_type, deployer_user_id, workflow_id, workflow_run_id — la chaîne de responsabilité jusqu'à l'utilisateur. |
Les tables créées par des utilisateurs ne peuvent pas commencer par agent_. Cette distinction rend la question « est-ce qu'un humain ou un agent a mis ceci ici ? » répondable en un coup d'œil.
Quand un workflow peut créer une table
Le workflow doit :
- S'exécuter pour un déployeur (la personne pour qui le workflow ou l'outil Cortex agit) qui est administrateur ou propriétaire de l'espace de travail — la même règle que pour créer une table depuis les pages de la table.
- Avoir une étape
create-tableexplicite dans sa définition — la création n'est pas implicite. - Passer par la même vérification d'autorisation qu'une création initiée par un utilisateur.
Le service appelant doit détenir la capacité managed-table:agent-create, et la création est alors décidée comme le serait la propre requête du déployeur ; le workflow ne peut pas escalader au-delà de ce que le déployeur est autorisé à faire.
Écrire des lignes et supprimer des tables
La même règle s'applique quand un workflow ou un outil Cortex écrit des lignes dans une table ou en supprime une. Chaque requête est décidée comme si la personne pour qui le workflow ou l'outil agit l'avait faite elle-même. Un lecteur (viewer) de l'espace de travail ne peut ni écrire de lignes, ni créer, ni supprimer une table de cette manière, pas plus qu'il ne le peut depuis les pages de la table. Le refus est le même 403 que celui qu'il y recevrait. Un administrateur ou un propriétaire de l'espace de travail peut faire les trois. Un membre peut écrire uniquement dans les tables qui lui appartiennent et les supprimer, mais ne peut pas en créer, comme depuis les pages de la table.
Les sources de données sont différentes. Leurs lignes sont écrites par la plateforme pour la source et n'agissent pas pour une personne : cette vérification ne s'applique pas à elles.
Colonnes d'identité de l'acteur
Chaque ligne insérée par un workflow comporte cinq colonnes supplémentaires :
| Colonne | Valeur |
|---|---|
_actor_type | Toujours "agent" pour ces tables |
_actor_run_id | L'ID d'exécution du workflow qui a écrit la ligne |
_actor_workflow_id | L'ID de définition du workflow |
_actor_deployer_user_id | L'utilisateur qui a déployé / possède le workflow |
_actor_inserted_at | Horodatage UTC de l'écriture |
Ces colonnes sont réservées — vous ne pouvez pas définir vos propres colonnes avec le préfixe de soulignement initial. Elles sont renseignées automatiquement ; le workflow ne les voit pas et ne les définit pas.
Pourquoi ces colonnes supplémentaires
Une table gérée est un artefact de longue durée. Un workflow qui a écrit une ligne le trimestre dernier peut ne plus exister, et l'utilisateur qui a déclenché l'exécution a peut-être quitté l'organisation. Les colonnes d'acteur donnent aux auditeurs de conformité et aux intervenants en cas d'incident une trace permanente jusqu'au contexte d'origine — quelle définition de workflow, quelle exécution, quel déployeur.
La suppression ou la modification des colonnes d'acteur nécessite une action explicite du propriétaire de l'organisation.
Vous pouvez accorder à un workflow la capacité de créer des tables, mais vous ne pouvez pas lui accorder la capacité de contourner les invariants de création par agent. Un workflow qui tente d'écrire dans une table dont le nom ne commence pas par agent_, ou qui tente de définir _actor_type sur "user", est rejeté par le plan de données.
Lecture depuis les tables créées par les agents
Les lectures suivent la même gouvernance que n'importe quelle autre table gérée. Les colonnes _actor_* sont toujours disponibles pour les administrateurs de l'espace de travail ; la visibilité pour les membres de l'espace de travail dépend des stratégies de masque de la table.
Voir aussi
- Tables gérées — le cycle de vie de base.
- Classification et masquage — comment la valeur par défaut
confidentialse manifeste. - Sécurité → Autorisation — le modèle de droit d'exécution qui conditionne ces écritures.
- Journal d'audit — chaque création / écriture par un agent est enregistrée.