{"schema_version":"1.0","service":"Publicasta","type":"article","id":769,"slug":"aws_agentic_development_security_bulletins_october_2026","title":"Les bulletins de sécurité AWS d’octobre font du développement agentique un sujet de réponse aux incidents","excerpt":"Les bulletins AWS révèlent des failles dans Loom for AWS, un serveur MCP de sécurité, SageMaker Unified Studio et Kiro. Au-delà des correctifs, les équipes doivent inventorier les agents, leurs identités, leurs accès réseau, leurs chemins d’écriture et l’activité cloud récente.","language":"fr","default_language":"en","canonical_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=fr","image":{"url":"https://publicasta.com/storage/projects/17/pages/769/2026/10/623b081b-3f35-486a-999f-b2a9e7cfbe8d.webp","alt":"Poste de travail de sécurité où un ordinateur portable surveille les connexions entre un agent d’IA, des outils, des identifiants, des fichiers et une infrastructure cloud."},"publisher":{"id":17,"slug":"it_today_news","name":"IT Today","url":"https://publicasta.com/it_today_news"},"author":{"name":"Anton R"},"published_at":"2026-10-05T13:52:15+00:00","updated_at":"2026-10-05T13:52:15+00:00","content_markdown":"Les derniers bulletins de sécurité d’AWS signalent une évolution dans la nature du risque lié aux outils de développement. Les produits concernés ne sont pas différentes versions d’une même plateforme et leurs failles n’ont pas une cause technique unique. Ils partagent toutefois un schéma opérationnel : un environnement de développement ou de données assisté par IA peut se situer entre la requête d’un utilisateur et des identifiants, des fichiers, des services réseau internes ou des API cloud. Une vulnérabilité dans cette couche peut donc devenir un incident de sécurité dont le rayon d’action dépasse largement celui d’un défaut classique d’éditeur.\n\n ![Poste de travail de sécurité où un ordinateur portable surveille les connexions entre un agent d’IA, des outils, des identifiants, des fichiers et une infrastructure cloud.](https://publicasta.com/storage/projects/17/pages/769/2026/10/623b081b-3f35-486a-999f-b2a9e7cfbe8d.webp)\n\n Ces derniers jours, AWS a publié ou mis à jour des avis importants concernant Loom for AWS, le serveur MCP open source `security-agent-mcp-server`, SageMaker Distribution dans SageMaker Unified Studio et l’IDE Kiro. Les divulgations portent sur un contournement d’authentification, l’exposition de jetons, des requêtes sortantes dangereuses, l’injection d’arguments, l’exécution de commandes et des écritures agentiques dans la configuration globale. Les bulletins AWS indiquent des versions touchées et des mesures correctives différentes. Une consigne générale comme « mettez à jour vos outils AWS » ne suffit donc pas.\n\n La réaction immédiate reste simple : déterminer si un composant concerné est installé ou déployé, passer à la version corrigée, redémarrer les services lorsque AWS indique que le correctif est appliqué au redémarrage, puis renouveler les identifiants lorsque l’avis précise qu’ils ont pu être exposés. Le travail le plus important est structurel. Les équipes de développement doivent traiter les outils agentiques comme des composants logiciels privilégiés et rendre visibles leurs permissions, leur portée réseau, leur périmètre d’écriture local et leurs traces d’audit auprès des opérations de sécurité.\n\n ## Ce qu’AWS a divulgué\n\n Le bulletin le plus récent du groupe concerne CVE-2026-104019, dans le processus de démarrage des Spaces SageMaker de SageMaker Unified Studio. AWS indique que le script de démarrage valide les connexions réseau disponibles dans un projet. Dans certaines conditions, une désinfection insuffisante des détails de connexion pouvait permettre l’exécution de code dans le Space d’un autre membre du projet. Dans les projets qui utilisent Trusted Identity Propagation, un contributeur ou un utilisateur de niveau supérieur pouvait potentiellement obtenir les identifiants temporaires du rôle d’exécution d’un autre membre et appeler des services en aval en son nom.\n\n AWS indique que le correctif a été déployé mondialement et qu’il est appliqué au redémarrage des Spaces pris en charge. L’avis cite notamment les versions corrigées de SageMaker Distribution 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5 et 4.4.3. Plusieurs branches mineures plus anciennes ne disposent d’aucun correctif parce qu’elles ne sont plus prises en charge. AWS recommande de redémarrer les Spaces exécutant les versions mineures concernées afin qu’ils reçoivent l’image corrigée. Aucun contournement n’est indiqué. Le redémarrage et la vérification de version constituent donc un contrôle opérationnel, et non une action à repousser jusqu’à la prochaine fenêtre de maintenance.\n\n Le bulletin consacré à Loom for AWS est différent et concerne particulièrement les équipes qui expérimentent l’orchestration d’agents. AWS décrit Loom comme une plateforme open source d’AWS Labs destinée à l’orchestration d’agents d’IA. Trois CVE touchent les versions antérieures à 1.7.0. Dans les versions antérieures à 1.6.1, un problème d’authentification pouvait permettre à un client réseau non authentifié d’obtenir des privilèges d’administration sur le plan de contrôle des agents lorsqu’aucun fournisseur d’identité n’était configuré. AWS précise que ces privilèges pouvaient inclure l’enregistrement de serveurs d’outils, la lecture d’identifiants d’intégration stockés et la réécriture des politiques de rôles IAM associées aux rôles d’agents gérés.\n\n Un deuxième problème, présent dans les versions antérieures à 1.7.0, concerne la gestion de la découverte OAuth2. AWS indique qu’un utilisateur authentifié disposant de la portée `mcp:write` ou `a2a:write` pouvait configurer une URL de découverte qui poussait le backend à envoyer des secrets de client OAuth2 ou le jeton d’accès d’un autre utilisateur vers un point de terminaison contrôlé par un tiers. La version 1.6.1 avait bloqué l’accès aux adresses internes, mais n’avait pas entièrement fermé le chemin d’exposition des jetons. Le troisième problème touchait les connexions aux serveurs d’outils et aux agents distants ; il pouvait permettre à un utilisateur authentifié de diriger des requêtes vers des emplacements réseau internes arbitraires, y compris le point de terminaison qui distribue les identifiants du conteneur.\n\n Pour Loom, AWS recommande la version 1.7.0 ; le problème d’authentification distinct est également corrigé dans la version 1.6.1. Le bulletin demande explicitement de renouveler les secrets des clients OAuth2, de révoquer puis réémettre les jetons d’accès actifs pendant la période concernée, et de renouveler les identifiants de session des rôles IAM si des identifiants de conteneur ont pu être consultés. C’est l’exemple le plus net, dans ce groupe, de la différence entre correctif nécessaire et remédiation suffisante : dès qu’un secret a pu franchir une frontière de confiance, il faut aussi rétablir la maîtrise des identités.\n\n Le problème de `security-agent-mcp-server` concerne un périmètre produit plus restreint, mais il est important parce qu’il touche la frontière entre un assistant IA local et le système de fichiers de l’hôte. AWS décrit ce projet comme un serveur MCP open source du dépôt `awslabs/mcp`, utilisé par des assistants pour lancer des analyses de sécurité locales, notamment des analyses différentielles. CVE-2026-97662 touchait les versions allant de 0.1.1 à toute version antérieure à 0.2.0. Une valeur de référence forgée, fournie à l’analyse différentielle, pouvait être interprétée comme une option de ligne de commande plutôt que comme une révision. AWS indique que le résultat pouvait être la création, l’écrasement ou la troncature de fichiers arbitraires en dehors de l’espace de travail prévu, contournant le mécanisme de confinement du serveur.\n\n AWS indique que la version 0.2.0 corrige le problème et qu’il n’existe aucun contournement en dehors de la mise à niveau. En attendant, ses recommandations sont de lancer les analyses différentielles uniquement sur des dépôts de confiance et d’utiliser un compte disposant de privilèges minimaux dans un environnement isolé. Ce conseil dépasse ce paquet précis. Un agent local capable d’appeler un analyseur, un compilateur, un gestionnaire de paquets ou un assistant de déploiement constitue un système d’automatisation local. Une erreur de traitement des arguments peut transformer une limite d’espace de travail soigneusement décrite en simple hypothèse que le système d’exploitation n’impose pas.\n\n Kiro IDE illustre une autre version du même problème. Le bulletin AWS consacré à CVE-2026-95985 indique que les versions de Kiro antérieures à 1.0.242 pouvaient permettre à un acteur distant non authentifié d’exécuter des commandes arbitraires et d’injecter des instructions forgées dans le contexte de l’agent lorsqu’un utilisateur lançait celui-ci dans un dépôt forgé comme espace de travail non fiable. AWS précise qu’il suffisait à l’utilisateur d’envoyer un message pour que des modifications de l’agent soient automatiquement apportées à des chemins de configuration globale chargés au démarrage.\n\n La version corrigée de Kiro est 1.0.242. AWS indique qu’il n’existe aucun contournement et demande aux utilisateurs ayant exécuté l’agent dans un espace de travail non fiable avec une version antérieure d’examiner le répertoire de configuration globale de Kiro à la recherche d’entrées qu’ils n’ont pas créées. Les chemins indiqués sont `~/.kiro` sur macOS et Linux et `%USERPROFILE%\\.kiro` sur Windows. Le détail opérationnel important est qu’un dépôt peut être non fiable même lorsque la personne qui l’ouvre est digne de confiance. La décision de confiance dépend du contenu analysé par l’agent et des outils qu’il peut appeler, pas seulement de l’identité du développeur devant son clavier.\n\n ## Le point commun n’est pas que « l’IA serait non sécurisée »\n\n Il serait facile de réduire ces avis à une mise en garde contre les logiciels d’IA. Ce serait trop général pour orienter une réponse. Le point commun utile est la concentration de privilèges. Chaque produit associe des composants logiciels ordinaires à une capacité susceptible de franchir une limite : écriture dans des fichiers locaux, connecteur MCP ou A2A, client OAuth2, rôle d’exécution temporaire, script de démarrage ou contexte d’agent qui influence les actions suivantes.\n\n Ces frontières sont familières aux équipes de sécurité. Ce qui change avec les outils agentiques, c’est le nombre d’étapes qui peuvent suivre l’entrée initiale. Un dépôt peut influencer le contexte d’un agent. L’agent peut appeler un outil. L’outil peut atteindre un point de terminaison interne ou lancer une commande. La commande peut lire ou modifier des fichiers. Un service cloud peut ensuite utiliser des identifiants temporaires pour effectuer des appels d’API. Cette séquence ne constitue pas nécessairement une chaîne d’exploitation dans chaque déploiement, mais l’architecture permet à une petite erreur de parsing ou d’autorisation d’avoir des conséquences en dehors de l’application d’origine.\n\n L’unité d’analyse pertinente n’est donc pas seulement le paquet ou l’IDE. C’est le paquet avec son identité d’exécution, son périmètre de système de fichiers local, ses sorties réseau, ses outils connectés et ses permissions cloud. Une équipe qui met Kiro à niveau mais laisse chaque agent de développement disposer d’identifiants d’administrateur réduit un défaut connu tout en conservant un rayon d’action incontrôlé. Une équipe qui corrige Loom sans renouveler les jetons après une éventuelle divulgation ferme le chemin logiciel sans clore l’incident.\n\n Les recommandations IAM d’AWS préconisent des identifiants temporaires pour les charges de travail, des permissions minimales, un examen régulier des permissions inutilisées, des conditions qui restreignent les politiques et des garde-fous de permissions entre les comptes. AWS recommande également d’utiliser l’activité CloudTrail et IAM Access Analyzer pour affiner les politiques. Ces contrôles sont généraux, mais les bulletins montrent où les appliquer : aux identités et aux intégrations utilisées par les outils agentiques, pas uniquement aux services de production.\n\n ## Qui doit agir en premier\n\n Le premier groupe est constitué des équipes ayant déployé Loom for AWS au-delà d’une machine de développement accessible seulement sur l’interface locale, en particulier si aucun fournisseur d’identité n’était configuré avant que l’application soit accessible sur un réseau. Viennent ensuite les équipes ayant accordé à Loom des portées d’intégration administratives comme `mcp:write` ou `a2a:write` à davantage de personnes qu’un petit groupe d’administrateurs. Enfin, les équipes utilisant Loom avec des intégrations OAuth2, des agents distants ou des serveurs d’outils détenant des identifiants doivent vérifier leur exposition.\n\n Le groupe suivant rassemble les équipes de données et d’IA qui utilisent les Spaces de SageMaker Unified Studio avec Trusted Identity Propagation. Le risque dépend de la configuration du projet et de la branche de distribution, mais la correction est concrète : identifier les Spaces qui exécutent des versions concernées, les redémarrer après la disponibilité des images corrigées et vérifier que les anciennes branches mineures non prises en charge ne sont plus en service. Un redémarrage doit être suivi comme une modification, avec un responsable et une preuve, et non considéré comme acquis parce que la plateforme est gérée.\n\n Les équipes chargées de la plateforme de développement et de la sécurité applicative doivent rechercher `security-agent-mcp-server` dans les manifestes d’outils locaux, les intégrations d’éditeurs, les images d’assistants CI et les conteneurs de développement partagés. Le paquet peut être installé sous un nom qui n’apparaît pas dans un inventaire des services AWS. Il faut examiner les dépôts sources et la configuration d’amorçage des postes qui déclarent des serveurs MCP, puis associer chaque installation à une version et à un compte d’exécution.\n\n Enfin, les équipes de gestion des postes doivent vérifier les versions de Kiro sur les stations de travail des développeurs et les bureaux virtuels administrés. C’est particulièrement important lorsque les développeurs ouvrent régulièrement des dépôts externes, des tickets ou du code généré. Si une version concernée a été utilisée avec un espace de travail non fiable, l’examen doit inclure le répertoire de configuration globale de Kiro. L’objectif n’est pas d’inspecter chaque fichier sans contexte, mais de comparer l’historique de configuration avec des références connues comme sûres et d’enquêter sur les entrées apparues pendant la période concernée.\n\n ## Une séquence de réponse pratique\n\n ### 1. Dresser l’inventaire des capacités\n\n Commencez par les capacités, pas par les noms des fournisseurs. Énumérez tous les outils de développement ou de données capables d’effectuer au moins l’une des opérations suivantes : écrire en dehors du répertoire du projet, exécuter des commandes locales, appeler des serveurs MCP ou A2A, accéder à des identifiants cloud, résoudre des adresses réseau, créer ou modifier des rôles IAM, ou lire des secrets d’intégration. Incluez les extensions d’IDE, les démons locaux, les conteneurs partagés, les exécuteurs CI, les images de notebooks et les wrappers internes autour de projets open source.\n\n Pour chaque élément, notez la version installée, la source d’installation, le propriétaire, l’hôte ou le conteneur, l’identité utilisée pour accéder aux ressources cloud, les réseaux joignables et les dépôts ou projets susceptibles de fournir des entrées. L’inventaire n’a pas besoin de devenir une base d’actifs parfaite dès le premier jour. Il doit permettre de répondre à deux questions : un avis AWS donné s’applique-t-il à une installation réelle, et quels autres systèmes étaient accessibles depuis celle-ci ?\n\n ### 2. Corriger selon la véritable frontière du produit\n\n Pour Loom, passez à la version 1.7.0 et examinez les forks ou le code dérivé. AWS précise que les dérivés doivent intégrer les correctifs ; un dépôt ayant copié le code en amont n’est donc pas couvert simplement parce que la version amont est à jour. Pour le serveur MCP, passez à la version 0.2.0 et vérifiez que les images partagées et les scripts d’amorçage des postes n’installent plus une ancienne plage de versions. Pour Kiro, passez à la version 1.0.242 ou ultérieure et examinez la configuration globale lorsqu’une version concernée a été utilisée avec un espace de travail non fiable.\n\n Pour SageMaker Unified Studio, identifiez la branche mineure de distribution et redémarrez les Spaces concernés afin d’appliquer le correctif déployé mondialement. La liste de versions d’AWS est importante parce que certaines branches anciennes ne sont pas corrigées : elles ne sont plus prises en charge. Un service géré peut réduire la charge de déploiement des correctifs, mais il ne supprime pas la nécessité de confirmer le runtime réellement utilisé ni de vérifier qu’un Space a redémarré.\n\n ### 3. Rétablir la maîtrise des identifiants lorsque l’exposition est plausible\n\n N’attendez pas la preuve qu’un jeton a été utilisé. L’avis AWS sur Loom recommande de renouveler les secrets des clients OAuth2 et de révoquer puis réémettre les jetons d’accès actifs lorsque la période concernée peut les inclure. Si un identifiant de rôle de conteneur a pu être consulté, renouvelez les identifiants de session et examinez CloudTrail pour repérer une utilisation inattendue. La séquence précise doit suivre le processus de gestion des incidents de l’organisation et les capacités du fournisseur d’identité.\n\n Le principe consiste à séparer la correction du code de la correction des identifiants. Un binaire corrigé empêche une répétition du chemin connu. Il n’invalide pas un secret qui a peut-être déjà été copié. La même distinction s’applique aux fichiers de configuration, aux jetons de développeurs, aux identifiants CI et aux sessions temporaires de rôles.\n\n ### 4. Examiner l’activité cloud autour de la fenêtre d’exposition\n\n CloudTrail enregistre les appels d’API AWS avec des informations telles que l’identité appelante, l’heure, l’adresse IP source, les paramètres de requête et les éléments de réponse. Utilisez ces données pour déterminer si le rôle ou l’intégration concerné a effectué des actions inhabituelles pendant la période où le composant vulnérable était exposé. Portez une attention particulière aux prises de rôle, aux changements de politiques IAM, à la création de nouvelles clés d’accès, aux modifications des politiques de confiance, à l’accès aux secrets, aux lectures de données inattendues et à l’activité provenant de réseaux inconnus.\n\n Il ne s’agit pas de rechercher un nom d’événement magique. Construisez une chronologie à partir du composant vulnérable, de son identité et de ses services connectés. Une divulgation de jeton peut apparaître comme un accès depuis une adresse inattendue. Une réécriture de politique de rôle peut se manifester par une modification IAM suivie d’un accès depuis un nouveau principal. Un Space de développement de données compromis peut produire une activité sous un rôle temporaire légitime ; c’est pourquoi l’heure, la source et l’activité attendue du projet doivent être considérées ensemble.\n\n ### 5. Réduire les permissions avant le retour à la normale\n\n Les fenêtres de correctifs sont un bon moment pour supprimer les permissions accordées à titre expérimental et jamais réduites ensuite. Commencez par séparer la découverte en lecture seule, l’analyse de code, le déploiement, l’accès aux secrets et l’administration IAM dans des rôles distincts. Utilisez des identifiants temporaires et des sessions courtes lorsque cela est possible. Placez les actions puissantes derrière une approbation ou dans un rôle d’opérateur séparé, au lieu de les rendre accessibles à toutes les identités connectées à des agents.\n\n AWS recommande le principe du moindre privilège et les garde-fous de permissions. Concrètement, un agent ne doit disposer que des actions d’API nécessaires à sa tâche et uniquement sur les ressources nécessaires à cette tâche. Un analyseur de code n’a pas automatiquement besoin de modifier des politiques IAM. Un serveur d’outils qui lit du code source n’a pas automatiquement besoin d’accéder aux secrets de production. Un contributeur de notebook ne devrait pas hériter de l’identité d’un autre membre du projet simplement parce qu’une fonction de propagation d’identité de confiance est activée.\n\n Les contrôles réseau comptent également. Limitez les sorties des conteneurs d’agents et des services de développement aux destinations nécessaires. Bloquez l’accès aux points de terminaison qui distribuent des identifiants, sauf par le mécanisme pris en charge. Gardez les outils locaux dans des environnements isolés lorsqu’ils traitent des dépôts non fiables. L’isolation réseau ne remplace pas les correctifs, mais elle peut empêcher qu’un parseur, un connecteur ou un wrapper de commande transforme une erreur locale en accès à un environnement plus vaste.\n\n ## Ce qu’il ne faut pas conclure des bulletins\n\n Ces divulgations ne prouvent pas que chaque IDE agentique ou serveur MCP est compromis. Elles montrent que l’examen de sécurité doit inclure les défauts logiciels ordinaires dans le plan de contrôle qui entoure l’agent. Le risque ne dépend pas du fait qu’un produit se présente comme une solution d’IA. Un plugin sans IA disposant de l’exécution de commandes et d’identifiants cloud peut être tout aussi sensible. À l’inverse, un agent sans identifiants, sans accès réseau et limité à un espace de travail en lecture seule présente un profil d’impact différent de celui d’un agent capable de modifier des rôles de déploiement.\n\n Ces avis ne justifient pas non plus l’interdiction des outils agentiques open source en tant que catégorie. Les avis AWS concernant Loom et `security-agent-mcp-server` montrent pourquoi les équipes doivent suivre les forks, les versions figées et les wrappers locaux. L’open source peut rendre les correctifs visibles et auditables, mais un dépôt copié, un correctif interne ou une image de conteneur peuvent continuer à contenir une vulnérabilité après la publication d’un correctif amont. Le contrôle pertinent est la discipline de version et de provenance, pas une étiquette simpliste.\n\n Enfin, un score de vulnérabilité ne suffit pas à déterminer l’urgence. Un contournement d’authentification dans un plan de contrôle accessible depuis Internet, une injection d’arguments sur le poste d’un développeur et une exécution de code dans un environnement de données multi-utilisateur peuvent avoir des probabilités et des conséquences très différentes. La priorité doit refléter l’exposition, les identifiants, la portée réseau, les données concernées et les éléments présents dans les journaux.\n\n ## La leçon durable pour les équipes plateforme\n\n Le développement agentique devient un ensemble de petits plans de contrôle : l’IDE, le serveur d’outils local, la couche d’orchestration, le dépôt, l’espace de travail cloud et le fournisseur d’identité. Pris séparément, chaque composant peut ressembler à une fonction de productivité. Ensemble, ils forment un chemin entre une entrée non fiable et une action privilégiée. La responsabilité de sécurité ne peut pas s’arrêter à l’équipe applicative qui a installé l’outil.\n\n Les avis AWS fournissent un test utile de la maturité organisationnelle. L’équipe sait-elle quels développeurs utilisent Kiro, quels dépôts contiennent le serveur MCP, quels déploiements Loom sont accessibles, quels Spaces SageMaker exécutent les distributions concernées et quels rôles ces systèmes peuvent endosser ? Peut-elle renouveler un secret d’intégration sans reconstruire toute une plateforme ? Peut-elle distinguer un appel normal effectué avec un rôle temporaire d’un appel suspect ? Si la réponse est non, le contrôle manquant n’est pas un énième document de politique sur l’IA. C’est un processus d’inventaire, d’identité et d’audit pour l’automatisation du développement.\n\n Pour l’instant, la séquence raisonnable reste courte : identifier l’exposition, appliquer les correctifs du fournisseur, redémarrer les Spaces gérés lorsque c’est requis, renouveler les éléments potentiellement exposés, examiner CloudTrail et réduire les permissions avant de réactiver un accès large. Les bulletins AWS portent sur des produits et des versions précis, mais leur message opérationnel va plus loin. Lorsqu’un logiciel peut interpréter un dépôt, appeler un outil et agir sous une identité cloud, son correctif de sécurité doit entrer dans la file de réponse aux incidents aussi bien que dans celle des mises à niveau destinées aux développeurs.\n\n ### Sources et périmètre\n\n Cet article se concentre sur les bulletins de sécurité AWS publiés entre le 24 septembre et le 2 octobre 2026, en mettant l’accent sur les actions opérationnelles indiquées par AWS. Il ne prétend pas qu’une exploitation a eu lieu dans l’un des déploiements concernés. Les étapes techniques d’exploitation sont volontairement omises ; les équipes doivent utiliser les avis des fournisseurs et leurs propres procédures de gestion des incidents pour mener leurs investigations.\n\n Les divulgations principales sont [le bulletin AWS 2026-125 concernant CVE-2026-104019 dans SageMaker Distribution](https://aws.amazon.com/security/security-bulletins/2026-125-aws/), [le bulletin AWS 2026-124 concernant les trois CVE de Loom for AWS](https://aws.amazon.com/security/security-bulletins/2026-124-aws/), [le bulletin AWS 2026-121 concernant CVE-2026-97662 dans security-agent-mcp-server](https://aws.amazon.com/security/security-bulletins/2026-121-aws/) et [le bulletin AWS 2026-117 concernant CVE-2026-95985 dans Kiro IDE](https://aws.amazon.com/security/security-bulletins/2026-117-aws/). Les recommandations relatives aux permissions et à l’audit s’appuient sur les [bonnes pratiques de sécurité IAM d’AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html), les [recommandations sur le moindre privilège](https://docs.aws.amazon.com/wellarchitected/2024-06-27/framework/sec_permissions_least_privileges.html) et la [documentation de l’API CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/).","available_translations":[{"language":"ar","title":"نشرات AWS الأمنية لشهر أكتوبر تجعل أدوات التطوير الوكيلة جزءاً من الاستجابة للحوادث","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=ar","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=ar","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=ar"},{"language":"de","title":"AWS-Sicherheitsbulletins im Oktober machen agentische Entwicklungstools zur Sache der Incident Response","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=de","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=de","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=de"},{"language":"en","title":"AWS’s October security bulletins turn agentic development tools into an incident-response issue","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=en","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=en","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=en"},{"language":"es","title":"Los boletines de seguridad de AWS de octubre convierten las herramientas de desarrollo agéntico en un asunto de respuesta a incidentes","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=es","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=es","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=es"},{"language":"fr","title":"Les bulletins de sécurité AWS d’octobre font du développement agentique un sujet de réponse aux incidents","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=fr","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=fr","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=fr"},{"language":"pl","title":"Październikowe biuletyny bezpieczeństwa AWS zmieniają narzędzia do agentycznego programowania w problem reagowania na incydenty","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=pl","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=pl","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=pl"},{"language":"ru","title":"Октябрьские бюллетени AWS превращают безопасность агентных инструментов разработки в задачу реагирования на инциденты","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=ru","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=ru","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=ru"},{"language":"zh","title":"AWS 十月安全公告：代理式开发工具已成为事件响应问题","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=zh","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=zh","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=zh"}],"_links":{"self":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=fr","api":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=fr","html":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=fr","canonical":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=fr","markdown":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=fr","json":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=fr","channel":"https://publicasta.com/api/public/v1/channels/it_today_news","channel_articles":"https://publicasta.com/api/public/v1/channels/it_today_news/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}