Protéger les agents IA d'Amazon Bedrock : deux modèles avec AWS WAF

AWS a publié un guide présentant deux modèles d'architecture pour protéger Amazon Bedrock AgentCore Runtime avec AWS WAF. Le premier ajoute un proxy Lambda entre l'équilibreur de charge et le VPC Endpoint, ce qui permet de transformer les requêtes avec souplesse. Le second appelle directement les adresses IP de l'ENI, supprimant un saut intermédiaire. Une politique de ressources avec la condition `aws:SourceVpce` ferme l'accès direct qui contournerait WAF. Les deux modèles ont été testés avec l'authentification SigV4 et OAuth via Amazon Cognito JWT.

Traité par IA depuis AWS Machine Learning Blog ; édité par Hamidun News
Protéger les agents IA d'Amazon Bedrock : deux modèles avec AWS WAF
Source : AWS Machine Learning Blog. Collage: Hamidun News.
Écouter l'article
Fiche synthèse et chiffres clés
ParamètreDonnées
Source primaireAWS Machine Learning Blog ↗
Rédacteur en chef
Chiffre clé #1L'ALB est ouvert à Internet et AWS WAF inspecte chaque requête entrante
Chiffre clé #2Le trafic passe par un VPC Interface Endpoint jusqu'à AgentCore Runtime
Chiffre clé #3Une politique de ressources interdit le contournement direct de WAF

AWS a publié deux modèles d'architecture pour protéger les agents IA d'Amazon Bedrock avec AWS WAF, testés avec l'authentification SigV4 et OAuth via Amazon Cognito JWT.

Pourquoi AgentCore Runtime a besoin de la protection WAF

AgentCore Runtime, le composant d'Amazon Bedrock qui sert à exécuter des agents IA en production, n'offre par défaut aucun filtrage au niveau de l'application web. Sans architecture supplémentaire, un attaquant peut viser l'agent par des injections, du DDoS ou de la falsification de requêtes en accédant directement au service.

AWS WAF (Web Application Firewall) permet de bloquer les vecteurs d'attaque connus, de limiter le débit des requêtes et d'appliquer des groupes de règles gérées avant que la requête n'atteigne l'agent. Les deux modèles utilisent un Application Load Balancer (ALB) exposé à Internet auquel AWS WAF est associé, et acheminent le trafic vers AgentCore Runtime via un VPC Interface Endpoint.

Paramètres clés des deux solutions :

  • L'ALB est ouvert à Internet et AWS WAF inspecte chaque requête entrante
  • Le trafic passe par un VPC Interface Endpoint jusqu'à AgentCore Runtime
  • Une politique de ressources interdit le contournement direct de WAF
  • L'authentification SigV4 et OAuth (Amazon Cognito JWT) est prise en charge
  • Les deux modèles ont été testés dans des scénarios de bout en bout

Modèle 1 contre Modèle 2 : quelle différence

Le modèle 1 ajoute une fonction AWS Lambda faisant office de proxy entre l'ALB et le VPC Endpoint. La fonction reçoit la requête après filtrage par WAF, peut la transformer (ajouter des en-têtes, normaliser les chemins, modifier le corps) puis la transmet à AgentCore via le VPC Endpoint. Cela offre un contrôle maximal sur le trafic, particulièrement utile en cas de logique de transformation ou de validation supplémentaire avant l'agent. Contrepartie : une latence accrue et le coût des appels Lambda.

Le modèle 2 supprime entièrement le saut par Lambda : l'ALB appelle directement les adresses IP de l'ENI (Elastic Network Interface) du VPC Interface Endpoint. Le schéma est plus direct, avec une latence plus faible et sans surcoût Lambda. Il convient lorsque la transformation des requêtes n'est pas nécessaire et que la priorité est la latence minimale, tout en conservant la protection de WAF.

«

Les deux modèles ont été testés de bout en bout avec l'authentification SigV4 et OAuth (Amazon Cognito JWT) », note AWS sur son blog Machine Learning.

Comment fermer la porte dérobée avec la politique de ressources

La partie la plus critique des deux modèles est la configuration correcte de la politique de ressources d'AgentCore Runtime. Sans elle, la protection WAF perd tout son sens : un attaquant peut découvrir le point de terminaison public d'AgentCore et l'appeler directement, contournant complètement l'ALB et WAF.

La solution est la condition `aws:SourceVpce` dans la politique de ressources. Elle n'autorise les appels vers AgentCore que via un VPC Interface Endpoint précis, ce qui garantit que tout le trafic traverse l'ALB et AWS WAF. La porte dérobée directe est fermée au niveau de la politique IAM.

Cette approche applique le principe de Defence in Depth : WAF est la première ligne de filtrage, la politique de ressources la seconde, qui empêche de contourner la première.

Ce que cela signifie

Le guide d'AWS offre aux développeurs d'agents IA sur Bedrock des modèles prêts à l'emploi et testés, plutôt que de les laisser inventer leurs propres schémas de protection. Le choix est simple : si la transformation des requêtes est nécessaire, modèle 1 avec Lambda ; si la rapidité et la simplicité priment, modèle 2 avec route directe vers l'ENI.

Questions fréquentes

Quelles méthodes d'authentification les deux modèles prennent-ils en charge ?

Les deux modèles ont été testés avec AWS SigV4 (signature des requêtes avec les clés d'accès AWS) et OAuth avec des jetons Amazon Cognito JWT. Le choix dépend de l'architecture de l'application.

Pourquoi activer WAF sans politique de ressources ne suffit-il pas ?

AWS WAF ne protège que le trafic qui passe par l'ALB. Si l'accès direct au point de terminaison d'AgentCore n'est pas fermé par une politique de ressources avec la condition `aws:SourceVpce`, un attaquant peut contourner WAF en appelant AgentCore directement à son adresse publique.

Pourquoi

Amazon Bedrock AgentCore Runtime est-il vulnérable sans WAF ?

AgentCore Runtime n'offre par défaut aucun filtrage au niveau de l'application web. Sans architecture supplémentaire, un attaquant peut s'en prendre à l'agent par des injections, du DDoS ou de la falsification de requêtes.

Dossier

Questions clés sur cet article

Quelles méthodes d'authentification les deux modèles prennent-ils en charge ?

Les deux modèles ont été testés avec AWS SigV4 (signature des requêtes avec les clés d'accès AWS) et OAuth avec des jetons Amazon Cognito JWT. Le choix dépend de l'architecture de l'application.

Pourquoi activer WAF sans politique de ressources ne suffit-il pas ?

AWS WAF ne protège que le trafic qui passe par l'ALB. Si l'accès direct au point de terminaison d'AgentCore n'est pas fermé par une politique de ressources avec la condition `aws:SourceVpce`, un attaquant peut contourner WAF en appelant AgentCore directement à son adresse publique.

Pourquoi Amazon Bedrock AgentCore Runtime est-il vulnérable sans WAF ?

AgentCore Runtime n'offre par défaut aucun filtrage au niveau de l'application web. Sans architecture supplémentaire, un attaquant peut s'en prendre à l'agent par des injections, du DDoS ou de la falsification de requêtes.

ZK
Zhemal Khamidun — CPO d'Alpina Digital, product manager d'AlpinaGPT. Conçoit des produits IA depuis 2019. Hamidun News est un projet personnel devenu un agrégateur en production avec plus de 6 000 lecteurs.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
Qu'en pensez-vous ?
Chargement des commentaires…