Tutorial: a semantic layer for AI agents in EDB Postgres AI with the Amazon Bedrock AgentCore runtime
AWS and EDB have described how to build a semantic layer for AI agents directly inside Postgres (the AIDB extension) and connect it via Amazon Bedrock AgentCore to the Claude model. Data access is handled by Postgres GRANT and row-level security, not prompt editing.
AWS and EDB have published a tutorial describing how to build a semantic layer for agentic AI using the EDB Postgres AI extension (AIDB) combined with the Amazon Bedrock AgentCore runtime. It is another installment in a series showing the same "customer 360" scenario previously addressed using a knowledge graph from Stardog, a data virtualization platform from Denodo, a dimensional model from AtScale, and linked models from Strategy Mosaic.
Business metadata (e.g., the definition of the term "large customer" or an explanation that the price field in the orders table is the total amount, not the unit price) is stored directly in standard Postgres COMMENT statements. Foreign keys between tables serve as a map for joining data (join paths) that the agent uses when querying. Data access control is handled by Postgres GRANT and row-level security enforced via the AIDB extension's MCP endpoint — according to the authors, the same prompt and the same tool catalog thus return different results depending on the role of the requester.
The model planning and formulating queries is Claude on the Amazon Bedrock platform, with the runtime provided by Amazon Bedrock AgentCore. Authentication is handled by Amazon Cognito and the AgentCore Gateway with Cedar policies, while AgentCore Identity holds the output credentials for the Postgres database, so the agent's code never encounters the database password. Traffic monitoring combines CloudWatch on the AgentCore side and OpenTelemetry traces stored as rows in the aidb_otel schema inside Postgres, queryable with standard SQL.
The source article is only partially available; further technical details (e.g., a complete comparison of results for different roles) can be found in the source text itself.
Why it matters
It shows a concrete architecture in which business rules and data access rights for AI agents are not enforced through prompt instructions but directly at the database level (GRANT, row-level security). This reduces the risk of the agent bypassing restrictions due to a poorly formulated or modified prompt, and ensures that definitions such as "order total price" or "large customer" remain consistent across all agents and tools accessing the data.
Two audiences, two different impacts
What this means
For individuals
For developers designing AI agents with database access, the tutorial offers a concrete pattern for separating the business meaning of data (the semantic layer) from access control, instead of relying on instructions in the prompt.
For a business
For companies building internal AI agents on sensitive data, it shows a pattern for enforcing different access rights by user role at the database level rather than in the prompt, which reduces the risk of data leaking between roles when using the same agent code.
DevelopmentCheck the original
Event sources
only one source so far · 1 publisher, 0 independent. We count feeds from the same owner only once.