Comment des agents IA concurrents entrent en collision sur des comptes de production

Deux exécutions autonomes sur un même compte de production ne deviennent pas sûres parce que chacune possède une description de tâche différente. Elles partagent un système modifiable, et chaque plan peut devenir obsolète avant l'appel d'API suivant. Si les deux peuvent modifier la même ressource, il vous faut une limite de propriété appliquée par le service.

La défaillance est généralement plus discrète qu'une panne spectaculaire. Un agent ajoute un membre à un groupe pendant qu'un autre remplace la liste complète des membres à partir d'une lecture plus ancienne. Les deux requêtes renvoient un succès. La seconde supprime le membre ajouté par la première. Chaque exécution a suivi ses instructions. C'est votre API qui a accepté une séquence invalide.

Traitez une exécution d'agent comme un client concurrent non fiable, disposant de véritables identifiants et soumis à un calendrier imparfait. Donnez-lui une zone de propriété étroite, rendez les écritures conditionnelles à la version lue et consignez suffisamment de contexte pour expliquer plus tard une modification acceptée ou rejetée. La revue humaine reste utile, mais elle ne peut pas remplacer un destinataire capable de détecter un état obsolète.

Séparez la limite de tâche de la limite d'écriture

Une limite de tâche indique ce qu'un agent doit accomplir. Une limite d'écriture indique quels objets modifiables il peut changer. Ce sont deux notions différentes, et les équipes rencontrent des problèmes lorsqu'elles les traitent comme interchangeables.

« Mettre à jour le déploiement de staging » semble précis. Pourtant, cela peut toucher un tag d'image partagé, un pointeur de version, une règle de trafic, un enregistrement DNS, un registre de migrations de base de données et un canal de notification. Un agent peut respecter le texte de la tâche tout en entrant en conflit avec une exécution de version qui possède l'un de ces objets.

Définissez la propriété avec des éléments que le service destinataire peut vérifier. Les bonnes limites désignent des identifiants de ressources durables, pas une catégorie de travail vague :

• un environnement et un enregistrement de déploiement
• un locataire ou un compte client
• une pull request et sa branche
• un ticket d'incident et les ressources mentionnées dans son ensemble de modifications
• une fenêtre de maintenance avec une liste explicite de cibles

Évitez des limites comme « travail backend » ou « nettoyage de production ». Ce sont des étiquettes destinées aux personnes. Elles n'indiquent pas à une API quelle écriture doit échouer.

Un enregistrement de propriété utile contient l'ID d'exécution, l'ID de la ressource, l'opération autorisée et la date d'expiration. Conservez-le près du service qui possède la ressource. Si un contrôleur de déploiement possède le pointeur de version, c'est à lui de vérifier qui peut le faire avancer. Un tableur, un message de chat ou une instruction dans un prompt ne peut pas bloquer une requête reçue après le départ de la personne qui l'a rédigée.

Établissez une petite carte des conflits avant d'accorder un accès en écriture

Pour chaque tâche automatisée, recensez les ressources qu'elle lit, écrit, supprime et utilise comme valeur partagée par défaut. Marquez ensuite chaque paire de tâches qui peut écrire le même identifiant, ou dont l'entrée peut être modifiée par l'autre. Ce n'est pas de la bureaucratie. Cela révèle des collisions que les autorisations fondées sur les rôles dissimulent.

Par exemple, un agent qui fait tourner un jeton de service et un agent qui met à jour la configuration d'une intégration peuvent ne jamais appeler le même point d'accès. L'agent qui écrit la configuration peut lire la référence du jeton actuel, puis publier son document de configuration complet après que la rotation a modifié cette référence. Le conflit se situe dans la version du document, pas dans une commande identique.

Si vous ne pouvez pas décrire l'ensemble des écritures d'une exécution, ne lui accordez pas un accès étendu en écriture à la production. Demandez-lui de préparer une proposition ou limitez-le à un espace de noms de ressources jusqu'à ce que vous puissiez décrire la limite.

Une réponse positive peut quand même effacer une modification correcte

Le comportement du dernier écrivain gagnant devient une politique de perte de données lorsque les clients envoient des représentations complètes. Il semble inoffensif dans les démonstrations, car chaque client lit puis écrit immédiatement. Les agents passent souvent plusieurs minutes à examiner les journaux, préparer un plan, demander une approbation et relancer un appel après un délai d'attente.

Prenons un service doté d'une ressource notification-policy. Il renvoie cette représentation à l'agent A :

{
  "id": "prod-alerts",
  "version": 41,
  "destinations": ["[email protected]"],
  "severity": "high"
}

L'agent A prévoit d'ajouter une destination de secours. Pendant la revue, l'agent B modifie severity, de high à critical, et écrit avec succès la version 42. L'agent A envoie ensuite un remplacement complet fondé sur la version 41 :

{
  "destinations": ["[email protected]", "[email protected]"],
  "severity": "high"
}

Si le point d'accès accepte cette requête, il annule silencieusement la modification de B. Aucun agent n'a besoin d'être défectueux. L'API a permis à une observation ancienne d'écraser un fait plus récent.

Les mises à jour partielles réduisent la surface d'écriture, mais ne suppriment pas le problème. Un patch qui ajoute une destination peut encore violer un nouveau quota, une politique de routage mise à jour ou une suppression intervenue après la lecture. Le service doit décider si le patch reste valide par rapport à l'état actuel.

C'est pourquoi « nous autorisons uniquement PATCH pour les agents » ne constitue pas une conception de la concurrence. C'est seulement une forme d'écriture plus limitée. Il faut toujours une condition reliant l'écriture à l'état observé par l'agent.

Rendez chaque requête qui modifie l'état conditionnelle

Le contrôle optimiste de la concurrence est généralement la première défense à mettre en place pour les écritures des agents. Le client lit une version, un ETag, un numéro de génération ou un jeton de révision. Il le renvoie avec la mise à jour souhaitée. Le service n'accepte l'écriture que si la valeur actuelle correspond toujours.

La RFC 9110 définit If-Match précisément pour ce type de requête. Le serveur évalue la condition avant d'appliquer la méthode. Si l'ETag ne correspond plus, il rejette la méthode avec 412 Precondition Failed. Ce n'est pas un désagrément lié à l'API. Le serveur refuse de faire comme si un plan obsolète était toujours correct.

Une mise à jour HTTP conditionnelle peut ressembler à ceci :

GET /v1/notification-policies/prod-alerts

HTTP/1.1 200 OK
ETag: "41"
Content-Type: application/json

{"destinations":["[email protected]"],"severity":"high"}

L'agent reprend cet ETag dans son écriture :

PATCH /v1/notification-policies/prod-alerts
If-Match: "41"
Content-Type: application/json
Idempotency-Key: run-7f3c-add-backup

{"destinations":["[email protected]","[email protected]"]}

Si un autre écrivain a produit l'ETag "42", renvoyez un rejet explicite :

HTTP/1.1 412 Precondition Failed
Content-Type: application/json

{
  "error": "stale_version",
  "resource": "notification-policy/prod-alerts",
  "expected_etag": "41",
  "current_etag": "42",
  "retryable": false
}

Ne qualifiez pas cette erreur de relançable si l'agent peut renvoyer aveuglément le même corps. Une nouvelle tentative doit commencer par une lecture récente et une nouvelle décision. Elle peut révéler que le résultat souhaité existe déjà, que la politique actuelle rend la modification invalide ou qu'une personne doit choisir entre deux résultats concurrents.

Pour les bases de données, utilisez le prédicat équivalent directement dans la mutation. Une mise à jour classique vérifie la version dans la clause WHERE et traite zéro ligne modifiée comme un conflit :

UPDATE notification_policy
SET destinations = :destinations,
    version = version + 1
WHERE id = :id
  AND version = :observed_version;

Ne lisez jamais une version, puis n'effectuez une mise à jour inconditionnelle dans une seconde opération. La vérification et la modification de l'état doivent avoir lieu ensemble auprès de l'autorité qui stocke cet état.

L'idempotence évite les doublons, pas les désaccords

Les équipes ajoutent souvent une clé d'idempotence à un point d'accès, puis déclarent les écritures concurrentes maîtrisées. Une clé d'idempotence empêche une même requête logique de produire deux fois son effet. Elle n'indique pas au service si deux requêtes différentes sont compatibles.

Un délai d'attente réseau rend cette distinction concrète. Un agent envoie une requête pour créer un déploiement, mais perd la réponse. Une nouvelle tentative avec la même clé d'idempotence doit renvoyer le résultat initial au lieu de créer un second déploiement. C'est la suppression des doublons.

Prenons maintenant deux agents qui sélectionnent chacun un candidat de version différent pour le même environnement de production. Ils envoient des corps différents et des clés d'idempotence différentes. Les deux requêtes peuvent être parfaitement idempotentes, alors que l'une doit tout de même perdre parce que le pointeur de version a changé.

Utilisez les deux contrôles sur les points d'accès d'écriture importants :

• Une clé d'idempotence rattache les nouvelles tentatives et les livraisons en double à une seule opération terminée.
• Une précondition de version rejette une écriture dont la décision repose sur un état obsolète de la ressource.
• Un invariant côté serveur vérifie les règles qui doivent rester vraies même pour une écriture actuelle, comme un nombre maximal d'identifiants actifs.

Stockez la clé d'idempotence avec une empreinte de la requête et la réponse terminée. Si l'appelant réutilise la clé avec un corps différent, rejetez la requête. Renvoyer la première réponse pour une autre opération crée un véritable casse-tête de débogage et peut dissimuler un bug côté client.

Soyez strict sur l'expiration. Le service doit conserver une clé assez longtemps pour couvrir son comportement réel lors des nouvelles tentatives, mais un registre d'idempotence n'est pas un historique permanent des commandes. C'est dans le journal d'audit que vous conservez cet historique.

Utilisez des baux uniquement pour les tâches qui ne peuvent pas se chevaucher

Certaines actions durent assez longtemps pour que les seules vérifications optimistes rendent l'expérience médiocre. Une migration de base de données, une tâche de rapprochement destructive ou une bascule peuvent comporter de nombreuses écritures dépendantes. Dans ces cas, donnez à une exécution un bail de courte durée sur la ressource.

Un bail doit avoir un propriétaire, une expiration et une valeur de clôture. Cette valeur est importante, car un processus dont le bail a expiré peut se réveiller et continuer après l'acquisition d'un nouveau bail par un autre processus. Chaque écriture protégée doit porter le jeton monotone du bail, et le service doit rejeter tout jeton plus ancien que le dernier accepté.

Sans clôture, le service de verrous peut indiquer à l'agent A que son bail a expiré, mais il ne peut pas empêcher une requête retardée de A d'atteindre la base de données. C'est au service destinataire de la rejeter. C'est le point que les équipes oublient lorsqu'elles disent disposer d'un verrou distribué.

Gardez les baux ciblés et courts. Ne verrouillez pas « la production » pendant toute une enquête autonome. Verrouillez migration/customer-1842 ou release/prod-eu, et demandez à l'exécution de renouveler son bail uniquement tant qu'elle progresse réellement. Un bail doit expirer sans danger si le processus de l'agent, son ordinateur portable ou son réseau disparaît.

N'utilisez pas de bail pour couvrir des modifications ordinaires de configuration qui prennent en charge les contrôles de version. Les verrous longs transforment les modifications courantes en files d'attente, puis les équipes apprennent à les contourner. Une réponse 412 suivie d'un nouveau plan coûte moins cher qu'une panne provoquée par un détenteur de verrou obsolète.

L'identité de l'agent doit traverser la passerelle

Un jeton de production partagé donne le même nom à toutes les exécutions auprès du service. Après une collision, vous voyez que le jeton a agi, mais vous ne savez pas quel processus a planifié la modification, quelle approbation la couvrait ni quelle exécution arrêter. Le nettoyage devient lent et la révocation trop large.

Donnez à chaque processus d'agent une identité de session distincte, puis transmettez un identifiant de corrélation stable à chaque requête destinée à un service. Le service destinataire doit consigner l'identité, l'ID d'exécution, l'ID de requête, la ressource ciblée, la version observée, le résultat et sa propre version résultante. N'enfouissez pas ces informations dans le texte d'un message de commit.

Sallyport maintient les identifiants API et SSH hors du processus de l'agent pendant l'exécution de l'action, ce qui aide à préserver une séparation entre le contexte de planification de l'agent et le secret lui-même. Son autorisation par session peut identifier un processus d'agent nouvellement lancé avant le début d'une exécution. Cette autorisation contrôle qui peut agir, mais ne remplace pas les préconditions appliquées par le service destinataire.

Ne laissez pas l'agent choisir lui-même son identité effective dans un en-tête arbitraire. La passerelle ou le service destinataire doit associer cette identité à une session authentifiée. Sinon, une exécution peut prétendre après coup être le coordinateur du déploiement, et vos journaux ne seront qu'une mise en scène.

Pour SSH, le même principe s'applique, même si le protocole réseau diffère. Utilisez des principaux ou des comptes restreints distincts pour les différentes catégories de travail. Faites figurer un identifiant d'exécution dans les journaux des commandes distantes et évitez un compte shell partagé capable de modifier tous les répertoires applicatifs.

Le moment de l'approbation n'est pas celui de la transaction

Une personne peut approuver la demande d'un agent et approuver malgré tout une écriture qui devient incorrecte dix secondes plus tard. C'est normal dans un système concurrent. L'approbation porte sur l'autorité et l'intention au moment de la revue. Elle ne fige pas la ressource.

La conception dangereuse consiste à demander à une personne d'approuver une phrase générale comme « mettre à jour la configuration de production », puis à laisser l'agent effectuer une suite de lectures et d'écritures quand il y arrive. Une conception plus sûre présente la cible et l'effet prévu, puis laisse le service appliquer la version ou le bail au moment de la réception de l'écriture.

Lorsqu'une précondition échoue après l'approbation, ne réutilisez pas automatiquement cette approbation pour un plan modifié. L'agent doit présenter le conflit concrètement : quelle ressource a changé, quelle version il avait observée, quel champ a changé si le service peut le déterminer et si le résultat proposé est toujours nécessaire. Une personne peut alors approuver une nouvelle action, ou l'agent peut effectuer une opération sans effet après une nouvelle lecture.

L'approbation à chaque appel convient aux opérations dont chaque utilisation présente un risque important, comme la suppression d'un identifiant de production ou la modification d'une règle de routage visible de l'extérieur. Pour les lots habituels de petites écritures conditionnelles, une approbation par exécution est souvent plus utile, car elle permet à l'opérateur d'examiner l'identité et le périmètre sans créer un réflexe de validation mécanique.

Ne confondez pas une accumulation d'approbations avec un contrôle. Si les opérateurs ne voient ni l'ID de ressource, ni l'opération, ni le résultat actuel du conflit, ils approuvent une phrase tandis que le service effectue le véritable travail ailleurs.

Une réponse de conflit doit avoir un responsable défini

Une écriture obsolète rejetée est un résultat de sécurité réussi, mais seulement si l'exécution sait quoi faire ensuite. « Réessayer en cas d'erreur » est le mauvais choix par défaut. Cela transforme un désaccord en course automatisée.

Classez chaque chemin d'écriture avant d'autoriser l'exécution autonome. Cette classe détermine qui résout le conflit :

L'objectif n'est pas de rendre les agents timorés. Il s'agit de distinguer le recalcul du jugement. Un agent peut réessayer sans danger un rapport généré à partir d'entrées actuelles. Il ne doit pas choisir entre deux versions de production approuvées, deux décisions d'accès ou deux plans de retour en arrière simplement parce qu'il a reçu un 412.

Rendez les réponses de conflit lisibles par les machines. Incluez l'identité de la ressource, la version actuelle, la catégorie du conflit et indiquez si le point d'accès autorise une nouvelle tentative automatique. Un 409 vague accompagné d'une page d'erreur HTML pousse l'agent à deviner.

Testez la collision que vous vous attendez à voir

N'attendez pas le trafic de production pour vérifier que vos contrôles fonctionnent. Créez un test qui interrompt une exécution entre la lecture et l'écriture, permet à une seconde exécution de modifier la même ressource, puis libère la première. Vérifiez quatre résultats :

1. La première écriture échoue sans modifier la ressource.
2. La réponse identifie une version obsolète plutôt qu'une erreur serveur générique.
3. L'agent ne renvoie pas automatiquement son ancien corps.
4. Vos journaux permettent de relier les deux tentatives à leurs identités d'exécution et à leurs approbations.

Effectuez le même test avec un délai d'attente et une nouvelle tentative pour prouver que le comportement d'idempotence est distinct. Ce sont des chemins d'échec différents, qui nécessitent des résultats attendus différents.

Auditez l'action tentée et l'état résultant

Après une collision entre agents, un compte de production doit conserver deux types d'enregistrements : le chemin de la commande et l'historique faisant autorité de la ressource. Les journaux de la passerelle expliquent qui a demandé l'action et par quelle session approuvée. Les journaux du service expliquent si l'état a changé, quelle version a gagné et pourquoi une requête a échoué.

Ne vous contentez pas d'un événement indiquant « PATCH réussi ». Enregistrez l'identifiant de la ressource, la méthode, l'ID de corrélation de la requête, la précondition envoyée par le client, la clé d'idempotence ou une référence sûre vers celle-ci, le statut de la réponse et l'ETag résultant. Si votre service conserve un historique au niveau des champs, consignez-y les champs modifiés au lieu d'essayer de les déduire de la transcription de l'agent.

Sallyport produit ses journaux Sessions et Activity à partir d'un journal d'audit chiffré et chaîné par hachage. Si vous l'utilisez pour les actions d'agents, lancez cette vérification lors de l'examen d'une séquence contestée :

sp audit verify

La commande vérifie la chaîne hors ligne sur le texte chiffré et n'a pas besoin de la clé du coffre. Elle peut établir que ce journal local est resté intact. Comparez-le avec les journaux de requêtes du service destinataire avant d'affirmer que vous savez ce qui s'est passé.

Les règles de conservation et d'accès comptent aussi. Une transcription d'agent peut contenir un raisonnement défaillant ou des détails opérationnels copiés, tandis qu'un journal de requêtes doit rester un relevé factuel et concis. Conservez les éléments nécessaires pour reconstituer l'autorité et les transitions d'état, puis limitez les personnes qui peuvent les consulter.

Le parallélisme doit s'appliquer à des ensembles de ressources indépendants

Il n'est pas nécessaire d'utiliser une file d'attente globale pour toutes les exécutions autonomes. Il faut une règle qui permette au travail indépendant d'avancer tout en rendant explicite toute modification partagée. Partitionnez par locataire, environnement, branche de dépôt, service ou autre espace de noms que le service peut vérifier.

Une conception de production pratique comprend un coordinateur qui attribue à chaque exécution un ensemble d'écritures et ne lui accorde des identifiants ou un accès à la passerelle que pour cet ensemble. Le coordinateur ne décide pas si chaque modification est judicieuse. Il empêche deux travailleurs d'obtenir par accident une autorité qui se chevauche. Les services destinataires doivent tout de même appliquer les versions et les invariants, car les coordinateurs tombent en panne, les affectations dérivent et des interventions d'urgence sont lancées en dehors du parcours normal.

Lorsqu'une action couvre plusieurs ressources, évitez de la qualifier de modification atomique si les services ne peuvent pas réellement agir dans une même transaction. Enregistrez l'état souhaité, ordonnez les écritures afin que les étapes suivantes puissent valider les précédentes et définissez une compensation avant l'exécution. Une action de compensation doit elle aussi vérifier l'état actuel. Revenir à un ancien instantané peut effacer une modification légitime intervenue après l'exécution initiale.

Le premier test de production doit être volontairement banal : choisissez une ressource de configuration partagée, lancez deux exécutions d'agents depuis la même version et faites-leur proposer des modifications incompatibles. Si le service accepte les deux, corrigez ce point d'accès avant d'accorder à l'une ou l'autre un périmètre plus large. L'autonomie devient moins intéressante après une collision, et c'est précisément pour cela qu'il faut provoquer cette collision dans un test contrôlé.