Donnez aux agents des outils aux limites claires.
Placez les contrôles de politique au périmètre de l’action : écriture système, modification d’accès ou export de données. Contrôlez ce que l’agent peut faire avec les outils auxquels il peut accéder.
L’action à gouverner
Créer un bon de commande
Un identifiant fonctionnel valide peut autoriser plus que ce que l’activité exige.
Un agent peut avoir besoin d’accéder à un système d’achats pour préparer une commande. L’entreprise a toujours besoin de limites concernant le fournisseur, le montant et la soumission finale. Ces règles appartiennent au point où l’appel d’outil devient une modification du système.
Le bon de commande est prêt. Le fournisseur doit être examiné.
Un agent d’achats demande un bon de commande pour un fournisseur hors liste approuvée. Au point de contrôle de l’outil connecté, KLA évalue l’action proposée avant que le système d’achats ne la reçoive.
Créer un bon de commande
Le fournisseur proposé ne figure pas dans la liste approuvée.
- Demandé par
- Agent d’achats
- Destination
- Système d’achats
- État du fournisseur
- Non approuvé
Règle applicable
Les bons de commande doivent utiliser un fournisseur approuvé.
Bloqué
Le bon de commande n’est pas soumis. Le fournisseur doit être examiné avant toute nouvelle demande.
Définissez le périmètre de l’outil, de l’action et de la destination.
L’accès à l’outil constitue une partie de la politique. Les paramètres de l’action et la destination déterminent ce que cet accès signifie en pratique.
Équipe plateforme
Le parcours d’exécution
Connectez l’appel d’outil pertinent au parcours gouverné et vérifiez la limite en aval.
Responsable métier
L’action autorisée
Définissez les fournisseurs autorisés, les limites de montant et les actions qui nécessitent un réviseur.
Équipe sécurité
Le périmètre d’accès
Limitez les identifiants et l’accès aux données aux systèmes et opérations nécessaires à l’agent.
Execution Lineage
Inspectez l’action derrière la réponse.
Execution Lineage relie la demande à la décision de politique et au résultat en aval. Un appel bloqué doit être aussi explicable qu’un appel autorisé.
Explorer Lineage Explorer- Qu’est-ce que l’agent a demandé ?
- L’outil, les paramètres de l’action et le contexte d’exécution associé.
- Quelle règle s’est appliquée ?
- La politique évaluée et son résultat autoriser, avertir, approbation requise ou bloquer.
- Qu’est-ce qui est parvenu au système ?
- Le résultat en aval d’un appel exécuté ou le refus enregistré d’un appel bloqué.
Définissez ce qu’une évaluation réussie doit démontrer.
Apportez un workflow, l’action à contrôler et les personnes responsables de ses règles. Convenez avec KLA du périmètre d’intégration et des critères d’acceptation.
Discuter de votre workflow- Une demande autorisée atteint l’outil prévu avec les paramètres attendus.
- Un fournisseur ou une action interdits sont bloqués avant toute modification du système.
- L’équipe vérifie la couverture et recherche les parcours autour du contrôle configuré.
Pouvons-nous gouverner des agents que nous utilisons déjà ?
Commencez par cartographier le runtime de l’agent, les interfaces d’outils, les identifiants et le parcours d’exécution. L’approche d’intégration dépend de ces limites. Examinez le parcours pris en charge avec KLA avant de vous engager dans un déploiement.
KLA gouverne-t-il automatiquement chaque appel d’outil ?
La couverture dépend du parcours d’exécution connecté et de ses contrôles d’accès. Un outil non connecté ou un parcours direct vers le système cible nécessite sa propre intégration et vérification.
Certains appels d’outil peuvent-ils continuer avec un avertissement ?
Oui. Le modèle de politique comprend autoriser, avertir, approbation requise et bloquer. Configurez le résultat de chaque action et testez les demandes autorisées et restreintes.