When building enterprise-grade AI agent analytics, a recurring problem is that agents can write SQL but do not know the business meaning behind column names or what they are authorized to read. Common solutions involve deploying a separate semantic layer—such as a knowledge graph, data virtualization platform, or dimensional model—and having the agent query that layer. On November 3, 2026, the Amazon Web Services Machine Learning blog presented a different approach: placing the semantic layer directly inside the operational Postgres database itself, using native database COMMENT, GRANT, and row-level security features to define meaning and control access, eliminating the need for a second system.
The specific mechanism operates in three layers. The first layer is meaning: the AIDB extension’s Semantic Knowledge Base (SemKB) embeds the definition of every table, view, and column, along with COMMENT ON text, into a vector index, allowing agents to find the correct tables and columns via natural language search. The second layer is relationships: Postgres foreign keys are automatically crawled by SemKB into join paths, so agents do not need to guess associations based on column names. The third layer is governance: the AIDB Model Context Protocol (MCP) endpoint has no permission system of its own; it passes the Postgres username and password for each request as HTTP Basic authentication, and the database’s GRANT and Row-Level Security (RLS) policies determine what that connection can see.
The blog illustrates the role of the meaning layer with a concrete example. In the C360 dataset, the purchases.price column records the order total, not the unit price. Without a COMMENT ON statement clarifying this, the agent treats it as a unit price multiplied by quantity, calculating approximately $502,529 for the top customer, Carolyn Inworth—a wrong figure. Adding a comment stating 'Total amount the customer paid for the entire order, in US dollars. Not the unit price.' changes the answer to $27,991.66. The model did not change, the prompt was not altered, and the tools remained the same; only the indexed comment within SemKB changed.
Governance verification is more direct. The blog defines two Postgres login roles: mcp_agent_full can see all columns, while mcp_agent_restricted cannot see customers.ssn. Running the exact same prompt to list five customers' Social Security Numbers yields different results. The full role returns the SSN values for all five customers; the restricted role’s tool call is denied at the Postgres layer, returning 'permission denied for column ssn,' after which the agent informs the user that SSNs cannot be read. The prompt, tool catalog, SemKB, and agent code are identical; the only difference is the Basic authentication credentials injected by AgentCore Identity.
Architecturally, the agent runs on the Amazon Bedrock AgentCore runtime, using Claude for planning and calling MCP tools through the AgentCore Gateway. The Gateway forwards requests to an Application Load Balancer within the EDB Postgres AI Virtual Private Cloud (VPC), reaching the AIDB edb-endpoints MCP server. No Lambda functions or translation layers are required—AIDB natively speaks the streamable HTTP MCP protocol. Auditing also remains within the same database: AIDB writes OpenTelemetry traces for every SQL execution into the aidb_otel schema, which can be queried using standard SQL.