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 :

Être déclenché par un utilisateur disposant du droit managed-table:create dans l'espace de travail cible.
Avoir une étape create-table explicite 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 droit d'exécution détenu par le workflow est ce qui permet la création ; le workflow ne peut pas escalader au-delà de ce que l'utilisateur déclencheur avait.

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 confidential se 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.