Per collegare un agente ad Amazon Bedrock AgentCore ai dati PostgreSQL, l’esempio di AWS inserisce la knowledge base semantica di AIDB in EDB Postgres AI e fa passare le richieste attraverso un endpoint MCP. La base indicizza metadati dello schema, non le righe dei dati; PostgreSQL applica i permessi del ruolo che esegue la query. La guida è utile ad amministratori di database e data engineer che valutano questa architettura.

Prima di iniziare

Per riprodurre l’esempio servono un database operativo EDB Postgres AI con AIDB, un agente e i componenti AWS della connessione, fra cui Amazon Bedrock AgentCore, Amazon Cognito e un Application Load Balancer (ALB). AWS usa Strands Agents in un esempio Python e Claude su Amazon Bedrock; la disponibilità del modello dipende dalla Regione AWS.

Il dataset dimostrativo è il Customer 360 (C360) Knowledge Kit di Stardog: quattro file CSV, quattro tabelle nello schema c360 e una vista derivata. È un modello campione, non una configurazione già dimostrata su schemi di qualsiasi dimensione.

Procedura di configurazione

  1. Carica i dati C360 nello schema c360. L’esempio organizza le tabelle customers, locations, products e purchases e definisce le chiavi esterne che collegano i dati. Queste relazioni forniscono all’agente percorsi di join ricavabili dallo schema.
  2. Descrivi il significato dello schema. Usa commenti PostgreSQL, per esempio con COMMENT ON, per chiarire che cosa rappresentano tabelle e colonne e quali campi sono sensibili. AIDB Semantic Knowledge Base (SemKB) indicizza nomi e descrizioni dello schema, delle viste e delle colonne, oltre alle relazioni tra chiavi esterne; non indicizza le righe sottostanti.
  3. Rendi esplicite le definizioni aziendali riutilizzabili. Nel C360, la vista big_spender definisce un cliente “grande spenditore” come chi ha almeno un ordine superiore a 250 dollari. Un alias semantico può dare un nome e una descrizione in linguaggio naturale a una query SELECT parametrizzata e di sola lettura, poi esporla all’agente come strumento.La definizione dei campi conta quanto i nomi. In C360, purchases.price indica il totale dell’ordine, non il prezzo di una singola unità. Nel calcolo riportato da AWS, l’interpretazione sbagliata ha prodotto una spesa di circa 502.529 dollari per il cliente principale; il risultato mostrato dopo aver chiarito il significato del campo è 27.991,66 dollari. Sono risultati del dataset dimostrativo.
  4. Configura la knowledge base semantica. L’esempio crea c360_kb sullo schema c360, usa il modello bge-small-en-v1.5-f16 e imposta auto_processing su Live. AWS descrive anche le modalità Background e Disabled. Se sono presenti più SemKB, le ricerche devono specificare kb_name per indicare quale usare.
  5. Abilita l’endpoint MCP di AIDB. L’esempio attiva edb.endpoints_mcp_enabled, aggiunge aidb a shared_preload_libraries e riavvia PostgreSQL. La porta predefinita indicata è 8765; per un binding diverso da loopback servono le impostazioni del certificato TLS e della chiave.
  6. Collega l’endpoint al Gateway. La configurazione descritta mette un ALB HTTPS davanti al server edb-endpoints su un’istanza EC2 e registra l’ALB come destinazione MCP di AgentCore Gateway. Il percorso usa HTTP MCP in modalità streamable, quindi l’esempio non richiede AWS Lambda per tradurre le chiamate. Nel setup descritto, il target group dell’ALB usa HTTPS sulla porta 8765 e non verifica la catena del certificato del backend; AWS raccomanda la connettività privata nella VPC per gli ambienti di produzione.
  7. Configura identità e credenziali del database. Amazon Cognito emette il JWT dell’utente; AgentCore Gateway lo verifica e valuta la policy Cedar che regola l’accesso agli strumenti. Per la connessione in uscita, AgentCore Identity fornisce al target MCP nome utente e password della role PostgreSQL con autenticazione HTTP Basic. Il codice dell’agente non riceve la credenziale del database.

Come AgentCore porta la richiesta fino a PostgreSQL

Diagramma di flusso dalla richiesta dell’utente attraverso Cognito, AgentCore e l’endpoint MCP fino ai controlli PostgreSQL, con un ramo separato per le tracce SQL.

Il controllo dell’accesso agli strumenti e quello sui dati avvengono in punti diversi: Gateway autorizza la richiesta e PostgreSQL applica i permessi della role. Perciò la credenziale Postgres selezionata determina quali dati la query può leggere, mentre la policy del Gateway regola quali strumenti l’agente può invocare.

La dimostrazione AWS confronta una role completa e una role limitata con gli stessi prompt e strumenti. La role limitata riceve un errore di permesso quando prova a leggere customers.ssn; le policy di sicurezza a livello di riga possono invece filtrare le righe restituite. È PostgreSQL a imporre questi vincoli.

Verifica query, definizioni e aggiornamenti

  1. Prova i ruoli e controlla le tracce. Ripeti una domanda campione con le credenziali di ciascuna role e verifica che PostgreSQL restituisca o neghi i dati secondo i permessi assegnati. Per osservare l’esecuzione, AgentCore invia a CloudWatch Transaction Search tracce delle chiamate agli strumenti e ai modelli, oltre all’uso dei token. AIDB può registrare le tracce di esecuzione SQL nello schema aidb_otel quando la telemetria è configurata.

Un’esecuzione SQL riuscita non basta a stabilire che una risposta applichi la definizione aziendale voluta. In una dimostrazione separata su Snowflake, l’utente Data-Queen-Mayra ha descritto tre conteggi plausibili di “fornitori attivi” su 34 record: 25 usando acquisti o fatture negli ultimi 12 mesi, 24 considerando gli ultimi 90 giorni e 21 basandosi sullo stato ERP. La semantica può codificare una definizione scelta; la decisione su quale definizione approvare spetta all’organizzazione.

Anche gli aggiornamenti richiedono verifiche distinte. In una discussione tra professionisti su agenti per database con circa 700 tabelle, u/MemStrata ha avvertito che una query può essere eseguita senza errori e dare comunque un risultato sbagliato, suggerendo di controllare il piano della query e registrare la definizione aziendale usata. u/bshivarthy ha raccontato che il proprio team confronta istantanee dello schema e segnala le definizioni che dipendono da tabelle modificate; ha anche descritto un saldo fuorviante causato da una replica non aggiornata. Sono esperienze di altri sistemi, non caratteristiche dell’integrazione EDB.

Per valutare le risposte, affianca quindi ai test dei permessi domande con risultati attesi e definizioni approvate, poi ricontrolla le query quando cambia lo schema e verifica la freschezza dei dati usati. La demo C360 di AWS comprende quattro tabelle e una vista.