Comment Tamnoon a construit une remédiation de sécurité cloud propulsée par l'IA avec Amazon Bedrock

Les expositions cloud critiques s'accumulent plus vite que ce que les équipes de sécurité peuvent corriger. Les plateformes de protection des applications cloud natives (CNAPP), les fournisseurs de cloud et les scanners de posture génèrent plus de résultats qu'aucune équipe ne peut traiter, et le risque s'accumule dans l'écart entre la détection et la correction. La plupart des résultats restent intouchés, non pas parce qu'ils sont difficiles à corriger. Quelqu'un doit enquêter sur le contexte, identifier le propriétaire, confirmer que la correction ne cassera pas la production, puis le faire à un volume qui dépasse les effectifs.

Dans cet article, nous partageons comment Tamnoon a construit Tami, un orchestrateur agentique de remédiation cloud sur Amazon Bedrock, pour combler cet écart. Tami enquête de manière autonome sur les résultats ingérés depuis les CNAPP et les sources cloud natives et évalue si la remédiation est sûre. Il génère et orchestre ensuite la correction avec des garde-fous et une gouvernance chaque fois qu'un changement touche le cloud d'un client. Cette approche a permis une réduction de plus de 90 pour cent de l'exposition cloud critique en 90 jours, sans aucun incident de production.

À propos de Tamnoon

Tamnoon est une plateforme de remédiation de sécurité cloud propulsée par l'IA qui fonctionne aux côtés des CNAPP. Son assistant IA, Tami, aide les experts humains en sécurité cloud à enquêter, prioriser et remédier en toute sécurité aux configurations erronées et aux problèmes dans les environnements clients sur AWS, Azure, Google Cloud et d'autres fournisseurs de cloud.

Tamnoon s'intègre aux CNAPP et aux outils cloud natifs que les équipes utilisent déjà et transforme leurs résultats en corrections validées et sûres pour la production. La majeure partie du travail, y compris l'investigation, la priorisation et la planification de la remédiation, se déroule avant que quoi que ce soit ne touche un environnement de production, ce qui rend la remédiation automatisée digne de confiance à grande échelle.

Défis de la remédiation de sécurité cloud

Un ingénieur en sécurité peut passer des heures à enquêter sur un seul résultat. Souvent, celui-ci remonte à la même cause racine que des dizaines d'autres alertes.

• Le volume d'alertes dépasse les effectifs : les CNAPP et les scanners génèrent des milliers de résultats. Les équipes ne peuvent pas tous les trier, si bien que les expositions critiques restent non résolues pendant que le risque s'accumule pendant des mois.
• L'investigation est manuelle et répétitive : chaque résultat nécessite la collecte de contexte sur qui possède la ressource, ce qui en dépend, si la correction est sûre. Cela consomme des heures de temps d'ingénieurs seniors, répétées pour chaque élément du backlog.
• La crainte d'un impact sur la production bloque l'automatisation : les équipes hésitent à automatiser la remédiation parce qu'elles ne peuvent pas risquer de faire tomber la production. Sans confiance dans le fait qu'une correction est sûre, rien n'avance.
• Une priorisation réactive : sans moyen de regrouper les résultats liés ou d'évaluer la confiance dans la remédiation, les équipes traitent les alertes de manière linéaire plutôt que de s'attaquer aux causes racines qui résolvent plusieurs problèmes à la fois.

La solution de Tamnoon traite l'ensemble du pipeline, de l'ingestion des résultats à la correction validée. La plateforme considère ces défis comme des problèmes interconnectés plutôt qu'isolés.

Présentation de la solution

Tamnoon vous mène du résultat initial à l'exécution de la correction. La plateforme ingère les résultats des fournisseurs de CNAPP, de Cloud Security Posture Management (CSPM) et d'autres outils de sécurité, et les normalise dans un schéma unifié. Elle les enrichit ensuite avec le contexte des actifs et des expositions et les priorise. Ensuite, la couche agentique prend le relais à l'aide d'un ensemble d'agents IA spécialisés, chacun s'exécutant dans une architecture serverless pilotée par les événements sur AWS, de sorte que chaque étape évolue indépendamment et échoue en toute sécurité.

Architecture agentique sur Amazon Bedrock

La plateforme délègue le travail à quatre agents spécialisés, chacun responsable d'une phase distincte du pipeline de remédiation :

• Un agent d'investigation s'appuie sur un entraînement à partir de millions d'environnements cloud clients réels pour déterminer le contexte, puis filtre ce contexte à travers une couche de validation de type LLM-as-a-judge (grand modèle de langage en tant que juge). Il raisonne sur l'objectif de remédiation, la portée opérationnelle et la vérification spécifique au fournisseur de cloud, produisant des étapes d'investigation en lecture seule et un plan d'investigation complet.
• Un agent de notation de sécurité construit une chaîne de preuves par actif, combinant les résultats de vérification automatisés avec les conclusions des analystes. Il classe la remédiation de chaque résultat comme SAFE, RISKY ou AWAITING DATA avec un biais délibérément conservateur. En cas de doute, il rétrograde.
• Un agent de remédiation ne s'active que pour les résultats jugés sûrs par l'agent de sécurité. Il raisonne sur l'ordre, les dépendances et les conditions, puis produit un plan de remédiation dans lequel chaque étape suit une structure de sauvegarde, remédiation et vérification, et inclut des instructions de restauration.
• Un agent de génération de code transforme les étapes du plan en remédiation exécutable, mais uniquement après qu'un garde-fou d'entrée a filtré la pertinence et l'injection de prompts. Chaque artefact passe par une boucle automatisée de génération et de révision dans laquelle un agent réviseur distinct doit approuver le résultat.

Pourquoi Amazon Bedrock

Lorsque l'équipe de Tamnoon s'est lancée dans la construction de Tami, le choix de la plateforme de modèle de fondation (FM) allait façonner tout ce qui suivrait. Les agents de remédiation de Tamnoon ne font pas tous le même type de travail. Certains effectuent un raisonnement d'investigation approfondi pour comprendre la cause racine d'une découverte de sécurité. D'autres gèrent la validation à haut volume, vérifiant rapidement et à moindre coût les correctifs proposés. D'autres encore examinent le code généré, en équilibrant qualité et coût à chaque tâche. Associer chacun de ces travaux au bon modèle, sans assembler une intégration différente pour chacun, était une exigence fondamentale.

Cette exigence a fait d'Amazon Bedrock le choix naturel. Via une API unique, chaque agent peut appeler le modèle de fondation le mieux adapté à sa tâche. Les modèles les plus performants traitent les raisonnements les plus complexes. Les modèles plus efficaces prennent en charge le travail répétitif à haut débit. Les modèles axés sur la révision optimisent le compromis entre qualité du résultat et coût. Comme il s'agit d'une intégration unique plutôt que de plusieurs, les modèles peuvent être remplacés ou mis à niveau à mesure que le paysage évolue, sans devoir retravailler l'architecture à chaque fois.

La charge opérationnelle à grande échelle était un autre facteur de la décision. À mesure que le volume de requêtes augmentait, Tamnoon voulait éviter de construire et de maintenir sa propre logique pour répartir le trafic entre les capacités régionales. L'inférence multi-régions d'Amazon Bedrock gère cela automatiquement. Elle achemine automatiquement les requêtes d'inférence vers la Région AWS optimale dans une limite géographique définie, en maintenant le débit sans nécessiter de code de routage personnalisé.

La sécurité était la dernière considération, et pour une entreprise de sécurité cloud, elle était non négociable. Avec Bedrock, l'inférence s'exécute dans l'environnement AWS propre de Tamnoon, sous des permissions délimitées par AWS Identity and Access Management (IAM). Les données sensibles des clients ne quittent jamais la frontière de confiance. Cela a donné à l'équipe la confiance que la plateforme sous-tendant Tami respectait le même standard que celui auquel Tamnoon soumet son propre service.

Comment Tamnoon s'intègre aux CNAPP et aux outils de sécurité cloud

Tamnoon se situe en aval des outils de détection que les équipes de sécurité utilisent déjà. Les CNAPP comme Wiz, CrowdStrike, Palo Alto Cortex, Upwind, SentinelOne, Orca et Cyera, ainsi que les services natifs du cloud comme AWS Security Hub et Amazon GuardDuty, sont la source de vérité sur ce qui ne va pas dans l'environnement. Tamnoon se connecte via des intégrations basées sur des API et normalise les découvertes dans un format commun, de sorte qu'une mauvaise configuration se présente de la même manière, qu'elle provienne de Wiz ou de GuardDuty. Les outils de détection restent le socle. Tamnoon fournit la remédiation de bout en bout qui s'ensuit.

Pour chaque découverte qu'il traite, Tami attribue un indicateur de confiance de remédiation (RCI) : SAFE, RISKY ou AWAITING DATA. Cette évaluation indique aux équipes ce qui peut être automatisé et ce qui nécessite d'abord une revue humaine.

Figure 1 : Tamnoon en action

Architecture AWS de Tamnoon

Tamnoon s'exécute entièrement dans ses propres comptes AWS, isolés par environnement. Les utilisateurs accèdent à la plateforme via un point d'entrée sécurisé unique construit sur Amazon API Gateway, avec le chiffrement géré par AWS Certificate Manager et la connexion assurée par Amazon Cognito. Tout ce qui se trouve derrière ce point d'entrée s'exécute dans des réseaux privés répartis sur plusieurs zones de disponibilité, de sorte que la plateforme centrale n'est jamais directement exposée à Internet.

Dans cet environnement, Tamnoon combine deux types de calcul. Amazon Elastic Kubernetes Service (Amazon EKS) exécute les services toujours actifs derrière le tableau de bord, tandis qu'AWS Lambda alimente le travail piloté par événements consistant à collecter les découvertes, les analyser et exécuter les remédiations. Un ensemble de services de messagerie et de workflow AWS, notamment Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS) et AWS Step Functions, coordonne ces étapes afin que de grands volumes de découvertes soient traités de manière fiable et en parallèle, sans qu'un seul enregistrement défectueux ne bloque le reste.

La couche IA fonctionne sur Amazon Bedrock. Amazon Bedrock AgentCore, une plateforme pour construire, connecter et optimiser des agents à grande échelle avec n'importe quel framework ou modèle, offre aux agents de Tamnoon un moyen gouverné d'agir au lieu d'un accès sans limites. Amazon Bedrock Guardrails examine ensuite à la fois la requête et le code généré avant que quoi que ce soit ne progresse. Des services de support gèrent le reste de la plateforme : bases de données et cache gérés pour l'état, Amazon Simple Storage Service (Amazon S3) pour les playbooks et artefacts, et AWS Secrets Manager pour les identifiants, de sorte que les clés sensibles ne résident jamais dans le code applicatif.

Côté client, tout ce qui se trouve à gauche de la frontière de l'AWS Cloud est ce que les clients connectent à Tamnoon. Ils peuvent lier leurs propres comptes AWS, Azure et Google Cloud, brancher les outils de sécurité d'où proviennent leurs découvertes, et connecter les destinations où ils souhaitent voir livrés les résultats, telles que Slack, Jira, ServiceNow et GitHub.

Figure 2 : Architecture AWS de Tamnoon

Comment Tamnoon maintient zéro incident en production

Zéro incident en production est une réalité pour les clients de Tamnoon, et ce n'est pas un hasard. L'autonomie chez Tamnoon s'inscrit dans une architecture de sécurité en profondeur, où chaque couche suppose que la précédente pourrait laisser passer quelque chose.

Tout commence avant même la rédaction d'un correctif. Aucune remédiation n'est écrite tant qu'une évaluation de sécurité indépendante, axée sur le périmètre et délibérément orientée vers la prudence, n'a pas conclu que la modification peut être faite en toute sécurité. À partir de là, la plateforme trace une ligne stricte entre lecture et écriture. Les étapes d'investigation sont validées comme strictement en lecture seule, de sorte que le travail de compréhension d'un problème ne peut jamais le modifier. Seul le chemin de remédiation est autorisé à changer quoi que ce soit, et chaque modification effectuée comporte ses propres étapes de sauvegarde, de vérification et de restauration.

Cette discipline est renforcée par une auto-critique constante. Chaque étape de génération est associée à une étape de réflexion qui vérifie le résultat et réinjecte sa critique dans la régénération, de sorte que le système examine toujours son propre travail au lieu de s’y fier aveuglément. Ces recommandations restent également ancrées dans la réalité. Les résultats de l’agent sont validés par rapport aux résultats d’automatisation, aux retours des utilisateurs et aux données d’entraînement issues d’alertes réellement corrigées, et lorsque le modèle ne peut pas parvenir à un résultat exact par lui-même, un humain est intégré au processus.

Le dernier garde-fou se situe au moment de l’exécution. L’IA ne détient jamais d’identifiants cloud. Au lieu de cela, l’exécution est assurée par des identifiants à durée de vie courte et limités au tenant, sous une confiance contrôlée par le client, dans un environnement isolé maintenu séparé des agents qui planifient le travail. Tout cela est enveloppé par une gouvernance humaine : les remédiations passent par un flux d’approbation avec une piste d’audit complète, et chaque capacité d’IA est prouvée en interne avant d’atteindre un client.

Sécurité des données et conformité

Tami raisonne sur des données clients sensibles : charges utiles d’alertes, identifiants de ressources, mauvaises configurations et contexte de remédiation. Ces données doivent rester à l’intérieur de la frontière de confiance AWS, s’exécuter avec le moindre privilège et rester auditables. La standardisation sur Amazon Bedrock rend cela possible.

Le contenu sensible reste à l’intérieur d’AWS

Chaque charge de travail de Tami invoque Anthropic Claude sur Amazon Bedrock via l’interface ChatBedrockConverse , plutôt que d’appeler un point de terminaison LLM tiers. Ce choix unique place l’ensemble de la chaîne d’approvisionnement en IA sous un seul service natif AWS, ce qui a de réelles conséquences sur la manière dont les données clients sont traitées. L’inférence s’exécute entièrement dans le compte AWS propre de Tamnoon dans des Régions commerciales américaines, de sorte que les données ne quittent jamais AWS. Pour plus d’informations sur la disponibilité des modèles par Région, consultez Modèles pris en charge par Région AWS dans Amazon Bedrock. Comme Bedrock ne conserve ni ne s’entraîne sur les invites ou les complétions, les données clients n’atteignent jamais un fournisseur externe en premier lieu.

Cette frontière tient même lorsque les charges de travail augmentent. L’inférence multi-Région de Bedrock achemine automatiquement les requêtes vers des Régions situées dans la limite géographique américaine, augmentant le débit disponible pour l’application. Le calcul sous-jacent reste également privé. Chaque service s’exécute sous forme de fonction AWS Lambda attachée à un cloud privé virtuel (VPC), dans des sous-réseaux privés avec un groupe de sécurité explicite, sans ingress public et avec un egress strictement contrôlé.

Protéger ce qui atteint le modèle

Les charges utiles peuvent contenir des détails sensibles, donc Tami applique Amazon Bedrock Guardrails à chaque requête et réponse. La stratégie est appliquée au niveau de la couche Bedrock, ce qui signifie qu’elle couvre uniformément les trois services et qu’aucune logique d’invite d’une fonction individuelle ne peut la contourner. Ce point d’application unique fait plusieurs choses à la fois.

D’abord, il protège les données sensibles. Les PII et le contenu de type secret sont masqués avant d’être persistés ou exposés, de sorte que rien de sensible ne subsiste là où il n’a pas sa place. Il protège également contre l’injection d’invites, ce qui compte parce que Tami raisonne sur des résultats non fiables qu’un utilisateur non autorisé pourrait influencer. Le filtrage au niveau de la couche de garde-fous empêche une charge utile forgée de détourner le modèle ou d’exfiltrer le contexte. Enfin, les sujets refusés et les filtres de contenu maintiennent la sortie du modèle limitée à la remédiation de sécurité et à rien d’autre. Chaque intervention est consignée aux côtés d’AWS CloudTrail, offrant aux clients d’entreprise une trace claire de preuves de gouvernance.

Accès au moindre privilège

L’accès à travers la plateforme passe par un rôle d’exécution IAM dédié par service, de sorte que chaque fonction ne peut atteindre que ce dont elle a besoin et rien de plus. Ce principe est plus facile à voir dans la manière dont Tami accède à Amazon Bedrock. Sa seule autorisation Bedrock est bedrock:InvokeModel, délimitée à des ARN spécifiques de profils d’inférence et de modèles de fondation. Elle n’a aucune capacité à gérer, entraîner ou exporter des modèles.

La même discipline s’étend à toutes les autres dépendances. L’accès à AWS Secrets Manager est limité aux deux secrets qu’une fonction utilise réellement, l’accès à SQS est confiné à sa propre file d’entrée, et les écritures dans Amazon CloudWatch sont restreintes par espace de noms. Il n’existe aucun rôle général fourre-tout dans la conception. Les fonctions s’attachent uniquement aux politiques gérées AWSLambdaBasicExecutionRole et AWSLambdaVPCAccessExecutionRole , et à rien de plus large.

Isolation multi-tenant et gouvernance

Maintenir les tenants séparés est une exigence fondamentale, appliquée dès le tout premier appel. Les appels de service à service utilisent OAuth2 client credentials via Cognito, délimités par application, et le travail est traité un message SQS à la fois avec son contexte de tenant attaché. Ainsi, une seule invocation ne touche jamais que les données d’un seul tenant.

Une grande partie de cette assurance vient du traitement de l’ensemble de la plateforme comme du code. Les politiques IAM, le placement réseau, les ID de modèles et les alarmes vivent tous dans des modèles AWS CloudFormation et SAM versionnés, de sorte que chaque autorisation et version de modèle est révisable dans le contrôle de source, sans modifications manuelles dans la console pouvant créer une dérive. Les versions de modèles en particulier sont épinglées à des identifiants datés, par exemple claude-sonnet-4-5-20250929, ce qui signifie qu’un changement de modèle est toujours une modification de code explicite et révisée plutôt qu’une mise à niveau silencieuse.

Cette transparence se poursuit à l’exécution. Chaque appel d’inférence atterrit dans AWS CloudTrail, attribuable au rôle invoquant, et le décodage déterministe avec la température réglée sur zéro maintient la notation et la planification cohérentes d’une exécution à l’autre. La gestion des échecs est gouvernée avec la même rigueur. Chaque service dispose d’une file d’entrée avec redrive, d’une fonction de gestion d’erreurs, d’une file d’attente de messages morts (DLQ) et d’alarmes CloudWatch sur les dépassements de délai et la profondeur de la DLQ reliées à l’astreinte. Les échecs sont contenus et observables, et jamais ignorés silencieusement.

Résultats et impact

Tami a analysé plus de 14 millions d'alertes cloud dans la base de clients de Tamnoon, un chiffre suivi dans le rapport 2026 State of Cloud Remediationde Tamnoon. Les décisions que Tami prend reflètent les modèles appris à partir de ces environnements réels.

Pour un client typique, les résultats apparaissent rapidement, généralement en 90 jours.

Les chiffres de compression et de zéro problème proviennent des recherches de Tamnoon. Le schéma est cohérent, montrant moins d'expositions ouvertes, beaucoup moins de travail manuel et aucun temps d'arrêt dû aux correctifs eux-mêmes.

Conclusion

Construire un agent capable de raisonner sur un constat cloud est la partie simple. Construire un agent auquel on peut confier des actions en production est la partie difficile. Amazon Bedrock est un service entièrement géré qui donne accès à des modèles de fond performants ainsi qu'aux outils nécessaires pour créer des applications agentiques : orchestration, utilisation d'outils et garde-fous, via une API unique. Cette combinaison compte ici pour une raison précise : agir sur une infrastructure cloud de production exige à la fois un raisonnement solide et des limites de sécurité strictes.

Quatre éléments rendent cela possible :

• Vos expositions sont réellement closes : Tamnoon opère sur une infrastructure cloud en direct, pas sur des tickets ou de l'automatisation de flux de travail. Le backlog diminue au lieu de s'étaler.
• L'autonomie évolue sans risque de production : chaque action proposée comporte un indice de confiance. Les actions SAFE peuvent s'exécuter automatiquement tandis que les actions AWAITING DATA ou RISKY font appel aux ingénieurs cloud intégrés de Tamnoon.
• Fonctionne sur la pile que vous avez déjà achetée : Tamnoon fonctionne par-dessus les CNAPP populaires et les outils de sécurité cloud. Chaque outil de détection que vous payez déjà commence à porter ses fruits car ses constats sont enfin clôturés.
• La capacité de l'équipe évolue sans recrutement : une adoption rapide et sûre de l'IA de pointe signifie plus d'expositions closes par analyste, sans effectifs supplémentaires.

Prochaines étapes

Pour démarrer avec une architecture similaire, considérez ce qui suit :

• Explorez Amazon Bedrock et les modèles disponibles via ce service.
• Consultez la documentation Amazon Bedrock pour planifier votre architecture.
• Réservez une démo avec Tamnoon pour découvrir quelle part de votre exposition critique au cloud vous pouvez réduire au cours des 90 prochains jours.

À propos des auteurs