ReadingResearchRadarInvestment frameworkAI Company Primary Sources
Sign in / Sign up
← Back to reading
NewsMaterial4 min readDisconfirmAI Editorial

EDB Postgres AI Embeds Semantic Governance into the Database: One COMMENT Changes Agent Answers, One GRANT Changes Agent Permissions

An Amazon Web Services Machine Learning blog demonstrates an architecture that places the AI agent semantic layer directly inside an operational Postgres database using the AIDB extension. The COMMENT ON statement defines business meaning, foreign keys provide join paths, and GRANT statements along with row-level security control access. The demonstration shows that with the same model, prompt, and tool catalog, a single column comment can correct an agent's calculation error, while a single column-level GRANT can prevent the agent from accessing sensitive data.

2026-11-04 00:41 GMT+8

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.

Sign in / Sign up
ReadingResearchRadarInvestment frameworkAI Company Primary Sources

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.

The applicability boundaries of this pattern are worth noting. It relies on the AIDB extension for EDB Postgres AI, requiring data to reside in Postgres. For analytical workloads exceeding the operational database, the blog mentions that Postgres Analytics Accelerator (PGAA) can read Apache Iceberg, Delta Lake, and Parquet tables, and Postgres foreign data wrappers can federate external relational sources—in both cases, the semantic layer definition remains unchanged because business meaning, column comments, and semantic aliases live in Postgres. However, this pattern does not directly apply to non-Postgres environments or scenarios requiring a unified semantic layer across multiple database types.

The blog also recommends combining Postgres GRANT (which controls what the agent can execute) with Amazon Bedrock Guardrails (which controls what the agent can generate). The former prevents SSNs from being read at the data layer, while the latter filters PII patterns at the model output layer. These two layers complement each other, and neither alone is sufficient.

For teams building agent analytics systems, the transferable insight from this blog is: if your data is already in Postgres, semantic governance does not require a standalone system. A single COMMENT ON determines whether the agent calculates correctly, and a single GRANT determines whether the agent can see the data. Correctness and security become deterministic behaviors at the database primitive level, rather than probabilistic behaviors at the prompt engineering level.

Sources

  • aws.amazon.comAmazon Web Services↗
Continue researching →