IA agentique : comment AWS sécurise vos données pour des agents autonomes ?

UN AGENT CLIENT PEUT TOUT FAIRE. MAIS PAS N'IMPORTE COMMENT

Imaginez un agent du service client qui répond seul à une demande : « Où est ma commande n°12345, et puis-je encore retourner les écouteurs achetés la semaine dernière ? ». Pour répondre, il doit consulter l'historique des commandes, vérifier la politique de retour des écouteurs, et synthétiser une réponse. Mais comment s'assurer qu'il n'accède qu'aux données de ce client précis, sans voir celles des autres ?

Les applications d'IA agentique (où l'IA agit de manière autonome) posent un problème de gouvernance bien plus complexe que les simples systèmes de Recherche augmentée (RAG). Dans un RAG, l'IA récupère des extraits de texte filtrés par métadonnées. Mais un agent autonome doit :

• Découvrir quelles tables existent dans les bases de données
• Comprendre leur structure (schémas)
• Construire des requêtes SQL
• Récupérer des données dans des vecteurs sémantiques
• Synthétiser les résultats

Chaque étape nécessite un contrôle d'accès spécifique. Un seul point de contrôle (comme dans le RAG) ne suffit plus. Une faille à un seul endroit pourrait exposer des données sensibles.

LE PROBLÈME : LES CONTRÔLES DE GOUVERNANCE CLASSIQUES NE SUFFISENT PLUS

Dans un système RAG, le contrôle se fait au moment de la récupération des données : on filtre les résultats par métadonnées comme le domaine métier ou la classification de sécurité. Par exemple, si un agent cherche des politiques de retour, il ne récupère que celles de la catégorie « électronique ».

Mais avec un agent autonome, les choses se compliquent. Les permissions ne peuvent pas se résumer à des paires clé-valeur sur des chunks de texte. Il faut gérer :

• Des hiérarchies de rôles (un manager peut voir plus de données qu'un employé)
• Des permissions basées sur des attributs (ex : accès uniquement aux données du service client)
• Des filtres au niveau des lignes (un agent ne voit que les commandes de son client)
• Des limites de coûts (un agent ne doit pas scanner des téraoctets de données)

De plus, les bases de données vectorielles synchronisent les permissions périodiquement. Si un accès est révoqué, l'agent pourrait encore l'utiliser pendant des heures. C'est inacceptable quand l'IA agit seule.

LA SOLUTION : UN DATA MESH GOUVERNÉ SUR AWS

Pour résoudre ces problèmes, AWS propose une architecture de data mesh gouverné en quatre couches, chacune avec ses propres contrôles d'accès. Voici comment ça fonctionne :

COUCHE 1 : LES DONNÉES STRUCTURÉES (ORDRES, CLIENTS) AVEC AMAZON S3 TABLES ET LAKE FORMATION

Les équipes métier (comme celle du service client) publient leurs données dans leur propre compte AWS. Elles utilisent Amazon S3 Tables, un service qui stocke les données dans des fichiers S3 tout en offrant les fonctionnalités d'une base de données transactionnelle (comme Apache Iceberg). Résultat : jusqu'à 10 fois plus de transactions par seconde qu'avec des tables Iceberg classiques sur S3 standard.

S3 Tables gère automatiquement la compaction, la gestion des snapshots et la suppression des fichiers inutilisés. Il s'intègre avec Amazon SageMaker Lakehouse, qui alimente le catalogue de données AWS Glue et fédère l'accès via Lake Formation.

Les trois produits de données publiés sont :

• customer_orders : les commandes des clients
• customer_profiles : les profils clients
• interaction_history : l'historique des interactions

Ces données sont interrogeables via Amazon Athena, avec des permissions gérées par Lake Formation. Par exemple, un filtre au niveau des lignes limite l'accès à un seul client :

Chaque requête injecte l'identité du client authentifié comme paramètre de session avant d'être envoyée à Athena. Lake Formation peut aussi masquer des colonnes sensibles comme le mode de paiement ou l'adresse de facturation.

COUCHE 2 : LES DONNÉES NON STRUCTURÉES (POLITIQUES, FAQ) AVEC AMAZON S3 VECTORS

Les clients ont aussi besoin d'accéder à des documents non structurés : manuels produits, politiques de retour, FAQ, guides de dépannage. Pour cela, AWS propose Amazon S3 Vectors, un service entièrement serverless qui stocke et interroge des vecteurs (représentations numériques de texte).

S3 Vectors supporte jusqu'à 2 milliards de vecteurs par index et offre une forte cohérence en écriture : les nouveaux vecteurs sont immédiatement interrogeables. Pour les clients d'Amazon Bedrock, S3 Vectors peut réduire les coûts de 90 % par rapport à des solutions spécialisées de bases de données vectorielles, dans des scénarios de fréquence de requêtes modérée.

Pour les charges de travail à très haute fréquence (millisecondes de latence), Amazon OpenSearch Serverless reste plus adapté. AWS permet d'exporter facilement les données de S3 Vectors vers OpenSearch Serverless quand les performances deviennent un goulot d'étranglement.

S3 Vectors permet de filtrer les résultats par métadonnées. Par exemple, pour trouver uniquement les politiques de retour des produits électroniques :

Les métadonnées peuvent être de type chaîne, nombre, booléen ou liste, avec des opérateurs comme $eq (égal), $ne (différent), $gt (supérieur à), $in (dans une liste), etc.

COUCHE 3 : LE GATEWAY AGENTCORE POUR EXPOSER LES DONNÉES À L'IA

Une fois les données gouvernées, il faut les exposer à l'agent IA de manière sécurisée et standardisée. C'est le rôle d'AgentCore Gateway, une couche centrale qui gère la connexion entre l'agent et les outils (fonctions Lambda, APIs, serveurs MCP).

Le Gateway agit comme un point d'entrée unique pour :

• L'authentification (via OAuth)
• La supervision (observabilité)
• L'application des politiques

Les agents se connectent via un transport HTTP streamable avec un token Bearer OAuth. Quatre outils MCP (basés sur Lambda) fournissent un accès gouverné aux données :

• getusertables : liste les tables autorisées dans le catalogue de données
• get_schema : récupère la structure (colonnes, types) d'une table
• run_query : exécute une requête SQL en lecture seule avec limites de coûts
• kb_search : effectue une recherche sémantique dans les bases de connaissances

Voici un exemple de schéma pour l'outil run_query :

{
  "name": "run_query",
  "description": "Exécute une requête SQL en lecture seule sur des tables Iceberg gouvernées via Amazon Athena avec des limites de scan d'octets et une sécurité au niveau des lignes de Lake Formation.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql": {"type": "string", "description": "Une requête SQL SELECT en lecture seule."},
      "database": {"type": "string", "description": "Le nom de la base de données dans le catalogue AWS Glue."}
    },
    "required": ["sql", "database"]
  }
}

Pour déployer ces outils, il faut créer des fonctions Lambda avec des rôles IAM spécifiques. Par exemple :

aws lambda create-function --function-name getusertables \
    --runtime python3.12 --handler lambdafunction.lambdahandler \
    --role arn:aws:iam::ACCOUNT_ID:role/mcp-tool-role \
    --zip-file fileb://function.zip

COUCHE 4 : LES INTERCEPTEURS POUR CONTRÔLER LES REQUÊTES ET RÉPONSES

Les interceptors sont des fonctions Lambda personnalisées qui agissent comme des middleware : elles inspectent, transforment ou bloquent les requêtes et réponses qui passent par le Gateway. Il en existe deux types :

• Request interceptor : s'exécute avant que le Gateway n'appelle l'outil cible
• Response interceptor : s'exécute après la réponse de l'outil, mais avant que les résultats n'atteignent l'appelant

Un exemple de fonction de filtrage des outils :

def checktoolauthorization(scopes, tool, target):
    if target in scopes:
        return True
    return f"{target}:{tool}" in scopes

Et une fonction de réponse qui filtre les outils autorisés :

def lambda_handler(event, context):
    gateway_response = event['mcp']['gatewayResponse']
    authheader = gatewayresponse['headers'].get('Authorization', '')
    token = auth_header.replace('Bearer ', '')
    claims = decodejwtpayload(token)
    scopes = claims.get('scope', '').split()
    tools = gateway_response['body']['result'].get('tools', [])
    filteredtools = [t for t in tools if checktool_authorization(
        scopes, t['name'].split('___')[1], t['name'].split('___')[0])]
    return {
        "interceptorOutputVersion": "1.0",
        "mcp": {
            "transformedGatewayResponse": {
                "statusCode": 200,
                "headers": {"Authorization": auth_header},
                "body": {"result": {"tools": filtered_tools}}
            }
        }
    }

Chaque token inclut un champ Act: Agent pour établir une chaîne de responsabilité claire. Un outil en aval non autorisé ne peut pas réutiliser un token trop privilégié pour accéder à d'autres outils.

LES CINQ COUCHES DE PROTECTION POUR LES AGENTS AUTONOMES

Pour un agent qui construit seul des requêtes SQL, cinq couches de protection se superposent pour limiter ce qu'il peut interroger, combien de données il peut scanner, et quelles informations atteignent le modèle :

1. Contrôles de coûts dans Athena

Chaque requête s'exécute dans un workgroup Athena dédié, configuré avec une limite BytesScannedCutoffPerQuery. Si une requête dépasse ce seuil, Athena l'annule automatiquement. Le paramètre EnforceWorkGroupConfiguration empêche l'agent de contourner ces limites. Des alertes via Amazon SNS sont déclenchées si le volume de données scannées dépasse un seuil.

2. Prévention des modifications de schéma (DDL)

Le rôle IAM de l'exécution Lambda a une interdiction explicite pour les actions de mutation du catalogue de données (création, suppression ou modification de tables ou partitions). Lake Formation ajoute une couche supplémentaire : un utilisateur ne peut pas créer de bases de données ou tables sans y être explicitement autorisé.

3. Sécurité fine avec Lake Formation

Lake Formation applique des politiques de sécurité à cinq niveaux de granularité : base de données, table, colonne, ligne et cellule. Ces contrôles s'appliquent nativement à Athena, Redshift Spectrum, Glue ETL et EMR, sans coût supplémentaire. Par exemple, un filtre au niveau des lignes limite l'accès à un seul client :

4. Intercepteurs du Gateway

Les request interceptors appliquent l'autorisation basée sur les scopes JWT avant l'exécution de l'outil. Les response interceptors filtrent les listes d'outils et masquent les données sensibles dans les résultats des requêtes.

5. Gardes-fous Amazon Bedrock intégrés au Gateway

Au lieu d'appliquer les contrôles de sécurité uniquement au moment de l'inférence du modèle, Amazon Bedrock Guardrails est maintenant intégré directement dans le moteur de politiques d'AgentCore. Il évalue en temps réel les entrées et sorties de chaque action autorisée de l'agent, y compris les appels aux outils et aux modèles. Cela permet de bloquer les attaques par injection de prompts, les contenus nuisibles ou les fuites de données sensibles avant qu'ils n'atteignent les systèmes en aval. Pour les charges de travail nécessitant des contrôles supplémentaires au niveau du modèle, les Guardrails de Bedrock peuvent toujours être appliqués en complément à la frontière d'inférence.

L'approche alternative (contrôles uniquement au niveau de l'inférence) est plus simple à mettre en œuvre, mais elle présente trois lacunes majeures pour les agents autonomes :

• Un angle mort temporel : un contenu nuisible peut se propager via des appels d'outils intermédiaires avant d'atteindre la frontière de sortie du modèle
• Impossibilité d'appliquer des politiques spécifiques aux outils (ex : bloquer certaines requêtes pour run_query tout en les autorisant pour kb_search)
• Dépendance totale au comportement du modèle pour exposer les sorties des outils à l'évaluation, ce qui n'est pas garanti dans des chaînes de raisonnement multi-étapes

L'approche basée sur le Gateway élimine ces lacunes en évaluant chaque requête et réponse à la frontière d'invocation de l'outil. Elle permet une personnalisation des politiques par outil, un blocage en temps réel des injections de prompts dans les entrées des outils, et une application déterministe indépendante du comportement du modèle.

UN EXEMPLE CONCRET : LA DEMANDE DU CLIENT

Prenons le scénario où un client contacte le service après-vente : « Où est ma commande n°12345, et puis-je encore retourner les écouteurs achetés la semaine dernière ? ». Voici comment l'agent autonome traite cette demande en respectant toutes les couches de gouvernance :

1. Authentification : L'agent reçoit un token OAuth valide avec des scopes limités au service client.
2. Filtrage des outils : Le Gateway intercepte la requête et ne fournit que les outils autorisés (getusertables, run_query, kb_search).
3. Requête des tables utilisateur : L'agent découvre les tables disponibles via getusertables.
4. Requête des données : L'agent construit une requête SQL pour récupérer l'état de la commande n°12345. Le rôle IAM limite la requête à la lecture seule, et Lake Formation applique un filtre au niveau des lignes pour ne retourner que les données du client authentifié.
5. Limite de coûts : Si la requête dépasse la limite de scan d'octets, Athena l'annule automatiquement.
6. Recherche sémantique : L'agent interroge la base de connaissances pour trouver la politique de retour des écouteurs, filtrée par catégorie de produit et type de document.
7. Synthèse de la réponse : L'agent combine les résultats et génère une réponse finale, tout en respectant les gardes-fous de contenu d'Amazon Bedrock.

À chaque étape, un contrôle différent est appliqué :

• Étapes 1-2 : Intercepteurs du Gateway
• Étapes 3-4 : Lake Formation
• Étape 4 : Limites du workgroup Athena
• Étape 6 : Filtrage des métadonnées de S3 Vectors

Cette approche en profondeur réduit le risque qu'une faille dans un seul contrôle expose des données non autorisées.

VALIDER ET DÉPLOYER L'ARCHITECTURE

Après le déploiement, il faut valider chaque couche de gouvernance :

• Vérifier les logs CloudWatch pour les fonctions Lambda
• S'assurer que les rôles IAM ont les bonnes permissions
• Tester les requêtes avec des limites de coûts strictes
• Vérifier que les filtres au niveau des lignes fonctionnent correctement

Pour éviter des frais après les tests, il est recommandé de supprimer les ressources suivantes :

• Fonctions Lambda
• Workgroups Athena
• Index S3 Vectors
• Politiques Lake Formation

POURQUOI CELA CHANGE TOUT POUR L'IA AGENTIQUE

Le passage du RAG à l'IA agentique étend considérablement la surface de gouvernance. Le RAG nécessitait un seul point de contrôle au moment de la récupération des données. L'IA agentique introduit :

• La découverte autonome des schémas
• La construction de requêtes SQL
• La synthèse multi-sources
• L'invocation d'outils

Chaque étape nécessite son propre contrôle d'accès. Cet article montre comment répondre à cette surface élargie avec un data mesh gouverné sur AWS qui combine :

• Amazon S3 Tables pour le stockage transactionnel avec sécurité Lake Formation
• Amazon S3 Vectors pour une recherche sémantique optimisée en coût
• AgentCore Gateway avec ses interceptors pour une autorisation déterministe au niveau des outils
• Contrôles des workgroups Athena pour la gouvernance des coûts des requêtes
• Amazon Bedrock Guardrails pour la sécurité du contenu au niveau du modèle

Ensemble, ces couches permettent un déploiement en production pour des industries fortement régulées, où la conformité exige une défense en profondeur à chaque étape de l'accès aux données.