Apprendre à un Agent IA à Demander la Permission : Construire des Opérations Autonomes Sécurisées

Voici la question qui dérange : Feriez-vous confiance à une IA pour arrêter des instances de production sans demander d’abord ?

C’est le défi central des opérations IA autonomes. Les agents IA comme Claude sur Amazon Bedrock peuvent diagnostiquer des problèmes, proposer des solutions et générer les commandes exactes pour résoudre les problèmes. Mais capacité ne signifie pas sécurité.

Considérez ce scénario :

Utilisateur : "Optimiser les coûts sur les serveurs de développement"

IA (pensant) : Instances inactives 80% du temps. Terminer pour économiser.
IA (exécutant) : Terminaison de i-abc123, i-def456, i-ghi789...

Utilisateur : "ATTENDEZ ! Il y avait du travail non sauvegardé !"

Chez Ohlala, nous avons construit SmartOps - un bot Microsoft Teams propulsé par Claude qui exécute des opérations AWS. L’IA peut lire les données librement, mais toute opération d’écriture nécessite une approbation explicite.

Cet article montre comment nous avons implémenté ce workflow d’approbation avec du code réel, des décisions d’architecture et des leçons tirées de l’utilisation en production.

Vue d’Ensemble de l’Architecture

Principes de Conception Clés

1. État côté serveur - Les entrées d’outils sont stockées de manière sécurisée, pas dans les données de carte (empêche la manipulation)
2. Suspension de conversation - Le LLM se met en pause en attendant l’approbation
3. Délai limité - Expiration de 15 minutes empêche les approbations périmées
4. Piste d’audit - Tracer qui a approuvé quoi et quand
5. Détection de commandes dangereuses - Avertissements supplémentaires pour les opérations à haut risque

Le Flux d’Approbation

Lorsqu’un utilisateur demande une opération, voici ce qui se passe :

1. Claude propose une action - Analyse la demande et décide d’exécuter une commande (ex : “arrêter l’instance i-abc123”)
2. MCP intercepte - Détecte qu’il s’agit d’une opération d’écriture nécessitant une approbation
3. Le serveur stocke l’état - Les entrées d’outils sont enregistrées avec un tool_id unique, expire dans 15 minutes
4. Carte envoyée à l’utilisateur - Montre exactement ce qui sera exécuté avec les boutons Approuver/Refuser

5. L’utilisateur approuve - Clique sur le bouton ✅ Approuver, les métadonnées d’approbation sont enregistrées (qui, quand)
6. Opération exécutée - L’API AWS est appelée avec les entrées d’outils stockées
7. Résultats retournés - La conversation reprend naturellement avec les résultats d’exécution

Le flux de conversation est transparent - Claude reçoit les résultats d’outils comme si aucune approbation ne s’était produite, les utilisateurs gardent le contrôle sur les opérations potentiellement perturbatrices.

Détails d’Implémentation Clés

Détection de Commandes Dangereuses

Toutes les opérations ne comportent pas le même niveau de risque. Notre système signale les commandes dangereuses avec des avertissements supplémentaires :

DANGEROUS_COMMAND_PATTERNS = [
    "rm -rf /", "del /f /s /q C:\\", "format c:",
    "shutdown", "reboot", "init 0",
    "killall", "pkill", "taskkill /f",
    "dd if=", "mkfs", "fdisk",
    "drop database", "drop table", "truncate table",
    "iptables -F", "netsh"
]

def _is_dangerous_command(command_text: str) -> bool:
    """Vérifier si la commande contient des patterns dangereux."""
    command_lower = command_text.lower()
    return any(pattern in command_lower for pattern in DANGEROUS_COMMAND_PATTERNS)

Les commandes dangereuses déclenchent :

• Le LLM comprend le risque
• Pas d’exécution de commandes dangereuses
• Message d’avertissement en gras expliquant le risque

Gestion d’État Côté Serveur

Décision de sécurité critique : Ne jamais faire confiance aux données du client.

Au lieu d’intégrer les entrées d’outils dans les données de carte (que les utilisateurs pourraient manipuler), nous :

1. Générons un tool_id unique
2. Stockons les entrées d’outils côté serveur : _pending_tool_inputs[tool_id] = tool_input
3. Ne passons que le tool_id dans les données de carte
4. Récupérons les entrées originales du serveur lors de l’approbation

Cela empêche les utilisateurs malveillants d’intercepter et de modifier les commandes avant approbation.

Gestion de l’Approbation

Lorsqu’un utilisateur approuve :

# Stocker l'approbation avec les informations utilisateur
user_name = getattr(turn_context.activity.from_property, "name", "Unknown")
user_id = turn_context.activity.from_property.id
approval_time = datetime.now().strftime("%Y-%m-%d %H:%M:%S UTC")

self.bot._pending_approvals[tool_id] = {
    "approved": True,
    "approved_by_user": user_name,
    "approved_by_id": user_id,
    "approval_time": approval_time,
}

# Enregistrer pour la piste d'audit
logger.info(f"User {user_name} approved {tool_id} at {approval_time}")

# Reprendre la conversation avec l'opération approuvée
await self.bot.resume_conversation_with_approval(turn_context, tool_id)

La conversation se suspend pendant l’attente, puis reprend de manière transparente après l’approbation - Claude voit cela comme une exécution d’outil normale.

Cas Limites Importants

L’Utilisateur Refuse l’Opération

Lorsqu’un utilisateur clique sur “❌ Refuser”, nous devons le gérer avec élégance :

# Empêcher les messages en double si l'utilisateur clique plusieurs fois
if user_id in self.bot._denial_sent:
    return  # Déjà traité

self.bot._denial_sent[user_id] = True

# Effacer tout l'état de conversation
self.bot.clear_conversation_state(user_id)

# Envoyer un message utile
await turn_context.send_activity(
    "❌ **Commandes refusées - Exécution arrêtée**\n\n"
    "J'ai annulé toutes les opérations en attente. Veuillez fournir une demande plus précise."
)

# Réinitialiser le flag de refus après 5 secondes
async def reset_denial_flag():
    await asyncio.sleep(5)
    del self.bot._denial_sent[user_id]

asyncio.create_task(reset_denial_flag())

Cela fournit :

• Protection contre les doublons (l’utilisateur pourrait cliquer nerveusement plusieurs fois)
• Nettoyage d’état clair
• Conseils utiles pour les prochaines étapes
• Réinitialisation temporisée pour permettre de nouvelles demandes

Plusieurs Approbations en Attente

Que se passe-t-il si une demande déclenche plusieurs opérations ?

Utilisateur : "Arrêter tous les serveurs dev inactifs et terminer les load balancers inutilisés"

Nous envoyons des cartes d’approbation séparées pour chaque opération :

for operation in operations:
    tool_id = generate_unique_id()
    self._pending_tool_inputs[tool_id] = operation
    card = create_approval_card(self._pending_tool_inputs[tool_id], tool_id)
    await turn_context.send_activity(MessageFactory.attachment(card))

Les utilisateurs peuvent approuver individuellement - contrôle granulaire sur chaque action.

Prochaines Étapes

Vous souhaitez implémenter votre propre workflow d’approbation IA ?

Option 1 : Utiliser Ohlala SmartOps

Obtenez ce workflow d’approbation clé en main :

• Cartes d’approbation pré-construites pour toutes les opérations AWS
• Journalisation d’audit incluse
• Intégration Microsoft Teams
• Claude sur Bedrock déjà configuré

Commencer avec Ohlala SmartOps → (199$/mois)

Option 2 : Construire le Vôtre

Utilisez cet article comme plan :

1. Configurer Amazon Bedrock avec Claude
2. Implémenter la gestion d’état côté serveur
3. Créer des cartes d’approbation (Adaptive Cards pour Teams, ou équivalent pour Slack)
4. Construire le gestionnaire d’approbation
5. Ajouter la détection de commandes dangereuses
6. Implémenter la journalisation d’audit

Consultez notre documentation pour plus de détails d’implémentation.

Lectures Connexes

Vous souhaitez approfondir la gestion d’infrastructure alimentée par l’IA ?

• Gérer EC2 Sans Scripts - Gestion d’infrastructure en langage naturel
• Dépannage d’Infrastructure IA - Utiliser l’IA pour diagnostiquer les problèmes AWS
• Gestion des Erreurs PowerShell - Construire des scripts d’automatisation robustes
• Utiliser les LLM pour Coder - Meilleures pratiques de développement assisté par IA

Questions ?

• FAQ - Questions courantes sur les opérations alimentées par l’IA
• Documentation - Guides techniques complets
• Réserver une démo - Voir en action

Construire des agents IA autonomes est passionnant, mais la sécurité est primordiale. Les workflows d’approbation ne sont pas une limitation - c’est la fonctionnalité qui rend les agents IA suffisamment fiables pour une utilisation en production.

La clé est de rendre les approbations rapides, transparentes et informatives. Bien fait, les utilisateurs remarquent à peine l’étape d’approbation car elle est si transparente. Mal fait, les utilisateurs contournent le système (dangereux) ou abandonnent complètement les outils IA (gaspillage).

Notre approche équilibre autonomie et contrôle. L’IA peut tout proposer, mais les humains approuvent ce qui compte. Ce n’est pas parfait, mais cela fonctionne de manière fiable en production, aidant les équipes à gérer l’infrastructure AWS en toute sécurité chaque jour.

L’avenir de la gestion d’infrastructure est conversationnel, alimenté par l’IA et contrôlé par l’humain.