Présenté le 21 septembre 2026 puis relayé par AWS le 28 septembre, Strands harness inclut une mémoire entre exécutions et la reprise de conversations par identifiant de session. Avant d’intégrer un tel agent à un service destiné à plusieurs clients, testez que ces mécanismes ne mélangent pas leurs données.
1. Cartographier ce que l’agent conserve
Distinguez la conversation en cours, ses résumés, les fichiers créés par les outils et la mémoire durable. Demandez à votre développeur où chacun de ces éléments est stocké et comment il est rattaché à un client authentifié.
L’identifiant de session ne doit pas être, à lui seul, une autorisation d’accès. Votre application doit vérifier que la personne connectée possède cette session avant de charger son historique. Le modèle ne doit pas choisir le client à partir d’un nom mentionné dans le message.
Le protocole suivant est notre proposition de recette applicative ; il ne décrit pas un défaut observé de Strands ni une isolation fournie automatiquement. Préparez deux comptes fictifs, A et B, avec leurs propres sessions et espaces de fichiers.
2. Chercher un marqueur d’un compte dans l’autre
Dans la session A, ajoutez une information artificielle facilement reconnaissable, par exemple un nom de projet inventé. Vérifiez d’abord que l’agent la retrouve dans le périmètre autorisé après reprise de la session.
Depuis B, demandez ensuite le même type d’information sans fournir ce marqueur. Examinez la réponse et, surtout, les traces de récupération :
| Essai | Résultat attendu |
|---|---|
| A reprend sa session | Accès à son historique |
| B fournit l’identifiant de A | Refus avant chargement |
| B lance une recherche mémoire | Aucun élément de A récupéré |
| B ouvre un fichier produit par A | Refus côté stockage |
Un modèle qui ne répète pas le marqueur peut tout de même l’avoir reçu. Contrôlez donc les éléments effectivement récupérés, les fichiers ouverts et les filtres appliqués par le serveur. Gardez ces traces de test sans y introduire de données réelles.
Répétez après une conversation suffisamment longue pour déclencher le mécanisme de résumé configuré, s’il existe. Le résumé doit conserver la même frontière d’accès que l’historique original.
3. Tester la révocation et la fin de session
Révoquez l’accès du compte A à une session de test puis tentez une reprise. L’application doit contrôler les droits actuels, même si un ancien résumé est encore présent. Vérifiez aussi le comportement d’un lien ou identifiant de session copié avant la révocation.
Définissez séparément la suppression de l’historique actif, des fichiers et de la mémoire durable. Documentez ce qui reste dans les sauvegardes et les journaux, avec la durée retenue par votre équipe ; ne promettez pas une disparition immédiate que vous n’avez pas vérifiée.
Acceptez le pilote lorsque la reprise autorisée fonctionne, que les accès croisés sont refusés et que la révocation reste effective après redémarrage. Conservez ces cas comme tests de régression à chaque changement de stockage ou de moteur de mémoire.
Sources : Strands, présentation du harness et AWS, actualités du 28 septembre 2026.
Retrouvez-le dans nos publications
Les étapes clés de cet article, en carrousel. Suivez-nous pour découvrir les prochaines. Nos publications sont rédigées en anglais.