AgentOps : valider le handoff Foundry vers l'automatisation avant une action production

Un agent Microsoft Foundry devient vraiment utile quand il ne se contente plus de résumer un incident. Il lit les sources, qualifie le symptôme, prépare une action, puis transmet cette action à une automatisation : Azure Automation, AWX, Azure DevOps, Logic App, Function interne ou outil exposé via MCP. C’est aussi le moment où le risque change de nature. Un mauvais résumé reste une erreur de diagnostic. Un mauvais handoff peut déclencher un job sur le mauvais environnement.

Le cas d’usage est un assistant d’exploitation qui aide une équipe on-call. Il peut proposer de relancer un runbook, ouvrir une demande de changement, préparer un rollback applicatif ou collecter des preuves. Avant d’autoriser le handoff vers l’automatisation de production, le runbook doit décider si l’action peut partir, si elle doit rester en brouillon, si elle nécessite une validation humaine supplémentaire ou si l’intégration doit être rollbackée.

Définir le contrat de handoff

Le handoff ne doit pas être un texte libre envoyé à un outil. Il doit être un contrat : intention, environnement, cible, paramètres, identité, mode d’exécution, approbation et rollback attendu. Sans contrat, l’agent peut produire une phrase plausible mais impossible à auditer.

handoff:
agent: ops-assistant-prod
platform: Microsoft Foundry
target_tool: azure-automation-runbook
intent: collect_diagnostics
environment: production
mode: dry_run_then_approved_execution
approval: required_for_state_change

required_fields:
- incident_id
- source_documents
- target_resource
- bounded_action
- parameters
- runtime_identity
- expected_output
- rollback_or_cancel_path
- human_approver

reject_when:
- environment_missing
- target_resource_ambiguous
- action_changes_state_without_approval
- parameters_from_memory_without_source
- rollback_path_missing

Ce contrat doit être compris par l’agent, par l’outil appelé et par l’humain qui approuve. Il réduit l’autonomie floue au profit d’une action explicable.

Séparer diagnostic, proposition et exécution

Un agent peut aider à diagnostiquer sans avoir le droit d’exécuter. Il peut aussi préparer une action sans la lancer. La séparation des étapes est le premier garde-fou opérationnel : lire, proposer, valider, exécuter, vérifier.

Etats du handoff
observed:
  L'agent lit les sources, traces et signaux d'incident.

proposed:
  L'agent propose une action bornée avec justification et paramètres.

prepared:
  L'outil reçoit une demande en mode dry-run ou draft.

approved:
  Un humain confirme l'environnement, la cible et le rollback.

executed:
  L'automatisation s'exécute avec une identité dédiée et des logs.

verified:
  L'agent ou l'équipe vérifie l'effet attendu avec des preuves.

Interdire
Passage direct observed -> executed
Paramètres générés sans source
Exécution sur production sans approbation
Réutilisation d'une ancienne décision mémorisée

Cette machine d’états est volontairement simple. Elle évite que l’équipe confonde “l’agent a raison” avec “l’agent peut agir”.

Prouver l’identité qui agit réellement

Le handoff doit identifier l’identité de l’agent et l’identité de l’automatisation. Dans beaucoup d’architectures, l’agent ne modifie rien directement. Il appelle un outil qui utilise sa propre identité managée, son service connection, son credential AWX ou son contexte MCP. Le contrôle doit porter sur l’identité qui agit réellement.

identity_chain:
conversation_user:
  role: requester
  can_approve: false

foundry_agent_identity:
  role: prepare_handoff
  allowed_actions:
    - read_sources
    - create_draft_action
    - call_dry_run_tool

automation_identity:
  role: execute_bounded_action
  allowed_scopes:
    - resource_group: rg-prod-observability
    - runbook: collect-app-diagnostics
  forbidden_scopes:
    - subscription_owner
    - wildcard_resource_group
    - firewall_policy_write

human_approver:
  role: approve_state_change
  evidence_required:
    - source_trace
    - dry_run_output
    - rollback_path

Si l’identité d’exécution a plus de droits que le contrat de handoff, le problème n’est pas le prompt. C’est une faille d’architecture opérationnelle.

Tester en dry-run avant l’action

Un dry-run utile ne se contente pas de dire “valid”. Il doit retourner ce qui serait ciblé, quelles commandes seraient appelées, quels paramètres seraient utilisés et pourquoi l’action est autorisée. L’agent doit intégrer cette sortie dans la demande d’approbation.

{
"handoffId": "inc-7421-diag-001",
"mode": "dry-run",
"target": {
  "environment": "production",
  "resource": "app-api-prod",
  "scope": "single service"
},
"action": "collect_diagnostics",
"wouldRun": [
  "query application errors for 30 minutes",
  "export dependency failures",
  "attach summary to incident ticket"
],
"willNotRun": [
  "restart service",
  "change firewall rule",
  "modify RBAC"
],
"approvalRequired": false,
"rollback": "delete generated evidence package if wrong incident scope"
}

Pour une action qui change l’état, le dry-run doit au contraire marquer approvalRequired: true. La différence doit venir du contrat, pas d’une décision improvisée par l’agent.

Tracer la source, la décision et l’outil

La trace doit permettre de reconstruire la chaîne complète : demande utilisateur, sources consultées, raisonnement utile, outil choisi, paramètres, approbation, exécution et résultat. Sans cette chaîne, l’équipe ne saura pas si un incident vient d’une source périmée, d’un mauvais mapping de paramètres, d’un outil trop permissif ou d’une approbation trop rapide.

let IncidentId = "INC-7421";
AgentHandoffEvents
| where TimeGenerated > ago(24h)
| where IncidentId == IncidentId
| project TimeGenerated,
        HandoffId,
        AgentName,
        ToolName,
        Intent,
        Environment,
        TargetResource,
        Mode,
        ApprovalState,
        RuntimeIdentity,
        SourceCount,
        TraceId
| order by TimeGenerated asc

Adaptez les noms de tables à votre observabilité. L’important est de chercher un objet de handoff, pas seulement une conversation.

Bloquer les paramètres ambigus

Le risque le plus fréquent n’est pas un outil radicalement dangereux. C’est un paramètre trop large : prod au lieu d’un service, un groupe de ressources entier au lieu d’une ressource, une branche par défaut au lieu d’un commit, un inventaire AWX complet au lieu d’un limit ciblé.

Paramètres à refuser
environment: missing, all, any
target: wildcard, subscription, tenant, all-hosts
action: restart, delete, rotate, open-firewall sans approbation
duration: permanent pour une exception temporaire
source: mémoire agent sans document cité
branch: latest sans commit ou tag approuvé

Paramètres acceptables
environment: production avec approbateur
target: ressource unique ou groupe explicitement listé
action: collecte ou vérification en lecture seule
duration: fenêtre bornée
source: document approuvé avec version ou date
branch: commit, tag ou release validée

Ces règles doivent vivre près de l’outil, pas seulement dans le prompt. L’outil doit refuser une demande trop large même si l’agent la formule poliment.

Décider exécution, brouillon ou rollback

La décision finale doit être explicite. Le handoff peut être exécuté si le contrat est complet, le dry-run cohérent, l’identité bornée, les sources citées et le rollback disponible. Il doit rester en brouillon si l’action est plausible mais manque d’approbation. Il doit être refusé si la cible ou les paramètres sont ambigus. Il doit être rollbacké si le handoff a déjà créé une action au mauvais périmètre.

Executer
Contrat complet
Dry-run lisible
Identité d'exécution bornée
Sources approuvées citées
Validation humaine présente pour changement d'état
Vérification post-action définie

Garder en brouillon
Diagnostic plausible
Paramètres incomplets
Approbateur absent
Fenêtre de changement non confirmée

Refuser
Cible ambiguë
Action trop large
Identité trop permissive
Source non approuvée
Rollback absent

Rollbacker
Action préparée sur mauvais environnement
Ticket ou job créé avec mauvais scope
Approbation attachée au mauvais incident
Trace insuffisante pour auditer l'exécution

Le rollback peut être simple : désactiver l’outil, revenir en mode dry-run obligatoire, annuler un job préparé, fermer une demande de changement ou restaurer la version précédente du contrat MCP.

Valider après activation

Après activation, ne mesurez pas seulement le nombre d’actions réussies. Mesurez les refus, les brouillons, les approbations, les dry-runs et les rollbacks. Un bon handoff doit produire des refus compréhensibles quand le contexte manque.

Validation post-activation
Les handoffs read-only passent sans approbation inutile
Les changements d'état demandent une validation humaine
Les refus expliquent le champ manquant ou dangereux
Les logs relient source, outil, identité et action
Les actions restent bornées à l'environnement demandé
Un rollback peut désactiver l'outil sans perdre les traces

Signal d'alerte
Trop d'actions en mode executed sans dry-run
Paramètres corrigés manuellement après coup
Approbations données hors incident
Outil incapable d'expliquer son refus
Identité d'exécution partagée avec d'autres automatisations

Un agent fiable n’est pas celui qui déclenche le plus d’automatisations. C’est celui qui transmet peu d’actions, mais avec assez de preuves pour que l’équipe sache les accepter ou les refuser vite.

Conclusion

Le handoff entre un agent Microsoft Foundry et une automatisation de production doit être traité comme une frontière d’exploitation. Il faut un contrat, une identité bornée, un dry-run, une approbation humaine pour les changements d’état, des traces et un rollback.

La bonne décision n’est pas toujours d’autoriser l’exécution. Elle peut être de garder l’action en brouillon, de réduire l’outil MCP, de revenir en dry-run obligatoire ou de désactiver temporairement le connecteur. L’objectif est simple : permettre à l’agent d’accélérer l’exploitation sans lui laisser transformer une suggestion plausible en action de production opaque.