Capa sémantique EDB Postgres: relier un agent à AgentCore

Pour relier un agent à des données PostgreSQL avec la couche sémantique EDB Postgres AI et Amazon Bedrock AgentCore, il faut décrire le sens du schéma dans AIDB, connecter son endpoint MCP à AgentCore, puis laisser PostgreSQL appliquer les droits du rôle utilisé. Voici comment suivre les étapes de l’exemple C360 présenté par AWS dans un tutoriel publié le 3 novembre 2026, à destination des administrateurs de bases de données et des ingénieurs data.

Préparer la base C360

L’exemple part du kit Customer 360 de Stardog : quatre fichiers CSV chargés dans le schéma c360, quatre tables (customers, locations, products et purchases) et une vue dérivée. Il faut aussi que l’extension AIDB soit installée et activée dans l’instance EDB Postgres AI. Le parcours fait ensuite intervenir une base sémantique AIDB, un endpoint MCP et des rôles PostgreSQL.

Décrire le sens des données et créer la base sémantique

1. Chargez les tables et leurs relations dans c360. Les clés étrangères donnent à AIDB des chemins de jointure que l’agent peut retrouver à partir du sens des colonnes.
2. Ajoutez les définitions métier avec COMMENT ON et des vues. Décrivez les tables, les colonnes et les champs sensibles dans le vocabulaire de l’entreprise. Dans l’exemple, purchases.price désigne le montant total d’une commande, pas le prix d’un article. La vue big_spender définit, pour ce jeu de données, un client comme « gros acheteur » lorsqu’il a passé au moins une commande de plus de 250 $.
3. Créez une SemKB pour le schéma. L’exemple nomme la base c360_kb, utilise le modèle local bge-small-en-v1.5-f16 et choisit le mode Live. La SemKB indexe les métadonnées du schéma, les tables, les vues, les colonnes, leurs commentaires et les relations entre clés étrangères. Elle n’indexe pas les lignes de données.

AWS illustre l’enjeu d’une définition métier précise avec le champ purchases.price : pris à tort pour un prix unitaire, il produit dans l’exemple un résultat d’environ 502 529 $, alors que le montant total présenté pour le client en tête est de 27 991,66 $. Ce sont des résultats du jeu C360, pas des mesures de performance du produit.

La SemKB de l’exemple accepte trois modes de traitement. Le choix détermine comment elle suit les changements du schéma :

Quand plusieurs SemKB sont présentes, chaque appel à aidb.semantic_kb_search doit préciser kb_name. Le modèle, le schéma et le mode de traitement font partie de la configuration de la base sémantique, et non de réglages généraux valables pour toutes les installations.

Relier AgentCore à l’endpoint MCP d’AIDB

1. Activez l’endpoint MCP d’AIDB. Le tutoriel configure edb.endpoints_mcp_enabled, ajoute aidb à shared_preload_libraries, puis redémarre PostgreSQL. L’exemple utilise le port 8765. Pour une écoute hors boucle locale, il prévoit un certificat TLS et une clé.
2. Placez l’endpoint derrière un ALB HTTPS. L’Application Load Balancer expose le serveur MCP d’AIDB à l’extérieur de l’instance. AgentCore Gateway enregistre la cible MCP et transmet les requêtes à l’endpoint par l’ALB. Dans cette architecture, le serveur parle déjà le protocole MCP en HTTP diffusé en continu : le chemin décrit n’utilise pas AWS Lambda.

Suivre l’identité jusqu’aux droits PostgreSQL

L’authentification de l’utilisateur et les droits sur les données passent par des contrôles distincts. Amazon Cognito émet le JWT de l’utilisateur. AgentCore Gateway le valide et évalue la politique d’accès aux outils. Au moment de l’appel à la base, AgentCore Identity fournit au point de terminaison MCP l’identifiant et le mot de passe du rôle PostgreSQL ; le code de l’agent ne reçoit pas ces identifiants. PostgreSQL applique ensuite les autorisations du rôle et, le cas échéant, la sécurité au niveau des lignes.

Vérifier les droits, les requêtes et la fraîcheur des données

1. Testez l’accès avec les rôles prévus. Dans la démonstration, un rôle restreint reçoit une erreur de permission lorsqu’il tente de lire la colonne customers.ssn. Les rôles peuvent donc produire des résultats différents avec les mêmes outils et la même demande. La sécurité au niveau des lignes peut aussi filtrer les enregistrements accessibles.
2. Comparez les réponses à des questions dont le résultat est connu. Une définition dans la SemKB rend une interprétation réutilisable ; elle ne décide pas qui, dans l’entreprise, est habilité à l’approuver. Dans une démonstration distincte sur Snowflake, un praticien a obtenu trois décomptes de « fournisseurs actifs » sur un échantillon de 34 : 25 avec une définition fondée sur les achats ou factures des douze derniers mois, 24 sur les 90 derniers jours et 21 à partir du statut dans l’ERP. Le terme doit donc être défini par son responsable métier, ou précisé lorsque la question admet plusieurs interprétations.
3. Suivez séparément les changements de schéma et la fraîcheur des données. Des praticiens discutant d’agents pour de grandes bases ont recommandé de tester des questions réelles, de vérifier les plans de requête et de consigner la définition métier associée à chaque requête. L’un d’eux a décrit une méthode qui compare des empreintes de schéma pour repérer les changements touchant les tables référencées ; il a aussi rapporté qu’un réplica en retard avait fourni un solde obsolète. Ces pratiques sont des retours d’expérience, pas des fonctionnalités propres à EDB.

AIDB peut enregistrer les traces d’exécution SQL dans le schéma aidb_otel lorsque la télémétrie est configurée. AgentCore produit séparément des traces d’appels aux outils et au modèle, ainsi que des données d’utilisation de jetons, dans CloudWatch Transaction Search.