EDB Semantic Layer Puts Agent Access Rules Inside Postgres

AWS published an EDB semantic layer walkthrough that puts database permissions, rather than prompt instructions, in charge of what an agent can read. Published November 3, the example connects EDB Postgres AI to Amazon Bedrock AgentCore, AWS services for hosting and connecting software agents. Its central proposition is concrete: keep business definitions near operational data, and enforce access where queries execute.

A semantic layer connects business language with database structures and calculations. Here, an agent uses Strands Agents, a framework for building agents that call tools, to answer questions about customer activity. The tension is between flexible query generation and dependable control. An assistant needs enough freedom to interpret questions, while database owners need predictable limits on its access.

The comparison with Denodo, a data virtualization platform that queries distributed sources, helps locate EDB’s approach. Both give agents business context, but they organize that context around different data architectures. For developers and enterprise buyers, the immediate question is where definitions and permissions should live, and who must maintain them.

The EDB semantic layer makes database meaning discoverable

The change is an integration pattern that makes existing database definitions usable by an external agent.

The agentic semantic layer walkthrough combines EDB’s AIDB database extension with an agent running on AWS. Its customer example uses four tables and a derived view, a saved query presented as a database object. Business descriptions come from database comments, while foreign keys, constraints connecting related records, supply join relationships.

According to AWS, the example holds the prompt and agent code constant while changing the database credential. The restricted role cannot retrieve a protected Social Security number column. That is a useful distinction: the database rejects the attempted access before the assistant composes its answer.

This remains a vendor-authored reference example. It establishes a proposed implementation and reports sample behavior, rather than supplying independent evidence of enterprise-wide reliability. Readers should separate those claims before drawing conclusions about deployment readiness.

EDB’s documentation explains the underlying semantic knowledge base, a searchable index of database structure and descriptions. It indexes tables, views, columns, and comments instead of embedding customer records. Embeddings, numerical representations used for similarity matching, help agents locate relevant database objects through natural-language questions.

That distinction matters for evaluation. Finding the correct structure does not establish that a generated calculation is correct. It gives the model better material for constructing a query. Teams still need to compare answers against accepted business results.

For anyone seeking the EDB semantic layer explained, the useful starting point is this separation between discovery and enforcement. Descriptions help an agent decide what data means. Permissions determine whether its proposed query can access that data.

The placement also changes ownership. A database comment becomes part of the agent’s working context, rather than documentation that only developers occasionally consult. An inaccurate description deserves the same attention as a misleading application interface.

Consider a hypothetical purchase field whose name does not reveal whether it contains a unit amount or an order total. Both interpretations support valid arithmetic. Only one matches the business definition, so successful execution alone cannot identify the mistake.

That makes this architecture relevant beyond its sample dataset. Its value depends on whether teams can turn ambiguous database conventions into maintained, discoverable definitions. The agent connection exposes that work as a prerequisite, rather than making it disappear.

Database owners inherit part of the agent workload

Moving meaning into Postgres gives database teams a direct role in answer quality.

The immediate pressure falls on the people who own schemas, reporting definitions, and access policies. An application team can improve an assistant’s instructions, but it cannot resolve an unsettled business definition through phrasing alone.

Suppose sales and finance use different definitions of an active customer. One counts recent purchases; the other requires an account in good standing. An agent that chooses either interpretation without qualification produces an answer that looks more settled than the underlying organization.

Keeping a definition near the data creates a place to resolve that disagreement. It does not decide which department is right. Someone still needs authority to approve the definition, explain its scope, and manage changes.

This is why the operational burden deserves attention alongside the architecture. A team adopting the pattern should expect ongoing editorial work on database meaning. Reviewing descriptions becomes part of maintaining an interface that software agents consume.

The same applies to relationships between tables. A technically valid connection does not automatically express the business relationship a question requires. Buyers should ask whether their existing database structure reflects reporting needs or merely supports application transactions.

That difference becomes visible when a customer has multiple addresses, account owners, or historical classifications. A question about current territory needs a different interpretation from a question about territory when an order occurred. Neither answer should depend on an undocumented assumption.

These are evaluation scenarios, not reported failures of EDB’s implementation. They show where stronger schema discovery still needs business judgment. A useful pilot should deliberately include questions whose answers change when those assumptions change.

The staffing implication is direct. Agent teams need access to the people who already resolve reporting disputes. Otherwise, application developers risk becoming unofficial owners of metrics they lack authority to define.

Enterprise buyers should therefore assess the maintenance process alongside the agent demonstration. Who approves a changed definition? Which applications depend on it? How does the organization discover that an assistant is using an outdated interpretation?

For engineering teams, a searchable knowledge base can preserve the reasoning behind those decisions. Database definitions and supporting documentation serve related purposes, even when they live in different systems.

The short-term pressure is to prepare a trustworthy pilot. The longer-term pressure is organizational: keep business definitions consistent as applications, reporting requirements, and staff change. The architecture makes that responsibility more visible, which is useful only if someone accepts it.

Reviewed queries give flexible agents a stable reference

Recurring business questions deserve reusable query logic, even when users ask them in different words.

EDB documents semantic aliases, named queries paired with searchable natural-language descriptions and defined parameters. An alias must contain a single read-only SELECT, a query that retrieves results. EDB says it validates that restriction when the alias is created and executed.

The architectural implication is a middle path between fixed reporting interfaces and unrestricted query generation. Users can express a familiar request conversationally, while the system has an existing query available as a reference.

For a hypothetical regional sales report, the reviewed logic might already specify the reporting period, customer classification, and treatment of canceled orders. Those decisions should survive changes in how a user phrases the request.

That is different from asking the model to reconstruct every decision each time. Reconstructing familiar logic introduces another opportunity for variation. Reuse gives reviewers a smaller, more concrete object to inspect.

However, a saved query does not solve interpretation by itself. The agent must still identify the appropriate query and supply suitable parameters. A request for quarterly activity should not silently become a request for the latest calendar quarter.

This creates distinct evaluation questions. Did the system recognize the intended business question? Did it select the right period and scope? Did the returned explanation accurately describe what the query measured?

A favorable database result addresses only part of that chain. An assistant can retrieve the right records and summarize them incorrectly. Conversely, a fluent explanation can conceal a query that answered a neighboring question.

The practical response is to keep reference answers for recurring requests. Teams can compare generated answers with those references while varying wording, dates, and user permissions. That tests behavior users will actually encounter.

Reviewed logic also creates a clearer change process. If the business changes its definition, maintainers can identify the relevant query and evaluate affected outputs. Without a shared reference, equivalent definitions can drift across agent applications.

There is a boundary to this benefit. Highly exploratory questions will still demand interpretation beyond an existing catalog of queries. Buyers should assess how the system behaves when no close match exists, including whether it asks for clarification.

The important product behavior is honest uncertainty. A tool that identifies an ambiguous request gives users a chance to correct its direction. A tool that confidently selects an unsuitable definition hides the decision.

The EDB approach is therefore best assessed as a way to organize reusable meaning and query logic. Its usefulness depends on retrieval quality, parameter handling, and review practices working together. None should be inferred from a successful demonstration of another.

Denodo highlights the boundary of database-local meaning

The EDB vs Denodo comparison turns on data placement and operating responsibility.

AWS’s earlier data virtualization architecture uses Denodo to connect customer information across Amazon Aurora, Amazon Redshift, and an on-premises PostgreSQL database. Data virtualization presents distributed sources through a shared query layer. That walkthrough places business views and access policies in Denodo.

The EDB example instead centers meaning inside its operational Postgres database. This comparison does not establish a performance winner. It shows different starting conditions for deciding where a business definition belongs.

For a team whose relevant data already resides together, database-local definitions deserve consideration. The organizational attraction is straightforward: existing database maintainers have a familiar place to inspect the objects that shape answers.

For a team whose customer information spans independent systems, the central problem is broader. It must reconcile identifiers, meanings, and permissions across those systems. Adding an agent interface does not remove those integration decisions.

The useful EDB vs Denodo question is therefore about the boundary of the business question. Can the organization answer it from the governed database it already operates? Or does the answer require coordination across several sources?

Consider a hypothetical account manager asking which customers need renewal attention. Purchase history alone might be insufficient. Contract status, unresolved support cases, and account ownership could each affect the answer.

If those records live elsewhere, a database-centered pilot should make that limitation visible. Otherwise, a successful answer over available records can be mistaken for a complete account assessment. The missing source becomes a business risk disguised as technical success.

A distributed approach faces its own evaluation burden. Connecting sources does not automatically establish that their definitions agree. Buyers still need to inspect how the system reconciles conflicting identifiers and reporting periods.

The central tension remains the same across both approaches: flexible agents need maintained meaning and enforceable access. The architectural choice determines where those responsibilities collect, rather than eliminating them.

This is also why connector counts are an incomplete buying criterion. A connector establishes a route to information. It does not establish that a particular question has an agreed meaning across every connected source.

Teams should compare architectures using a representative business request and its full dependencies. Include the source owners, approved calculation, access restrictions, and expected explanation. That reveals more than a general discussion of agent capabilities.

For EDB, the opportunity is to make existing database structure a dependable foundation for agents. The boundary is equally clear: an organization must establish how far that foundation covers the questions its users actually ask.

Permissions still depend on the identity reaching Postgres

A database access rule protects the intended user only when the query executes under an appropriate role.

EDB’s MCP server uses the Model Context Protocol, a standard interface through which agents call external tools. Its documentation states that tool calls execute as the authenticated Postgres role. Database privileges then determine what that role can run.

This creates a concrete review point for production teams. Authenticating a person at an application boundary and selecting a downstream database identity are separate responsibilities. Reviewers should trace both before accepting a claim about user-specific access.

A hypothetical shared reporting account illustrates the issue. If every request reaches the database under that account, database rules evaluate that account’s permissions. A personalized application interface does not itself establish personalized database enforcement.

That does not make shared accounts universally inappropriate. It means their authority must match the intended service boundary. A narrowly scoped reporting assistant has different requirements from an assistant serving users with distinct access rights.

PostgreSQL’s row security policies restrict which records a role can access. When enabled without an applicable policy, row security defaults to denial. However, superusers and roles with BYPASSRLS bypass those restrictions, while table owners normally bypass them unless forced to comply.

Those documented exceptions matter when testing an agent connection. A demonstration using an administrative account cannot establish ordinary-user isolation. Evaluators need to verify the effective role and its privileges for the actual request path.

Column restrictions and row restrictions also answer different questions. Hiding a sensitive field does not establish that another customer’s record is inaccessible. A convincing evaluation should test the dimensions of access that the application promises.

That evaluation should include attempted access through alternative questions. Asking for a sensitive field directly is useful, but business requests can combine permitted attributes in unexpected ways. Reviewers should inspect what the application returns and how it explains restrictions.

Permission enforcement also does not establish answer correctness. A role can be authorized to read records that the agent combines incorrectly. Security evaluation and analytical evaluation should remain distinct, with evidence for each.

Read-only access deserves similar precision. Preventing writes limits what an agent can change through that route. It does not determine whether an authorized result contains information the application should display in a particular context.

These qualifications define the scope of the claim rather than dismissing it. Database enforcement gives reviewers something concrete to inspect. They can examine roles, privileges, policies, and executed queries instead of relying solely on the assistant’s stated intentions.

The remaining work is to verify that the application consistently reaches that enforcement point under the intended identity. That is a deployment responsibility, and it should be visible in the acceptance evidence.

Watch identity isolation, definition changes, and repeatable answers

The next useful evidence will show whether governance survives changes in users, definitions, and request volume.

Over the coming months, buyers should watch for evaluations that connect those dimensions. Additional demonstrations of familiar questions provide less information than tests designed around the architecture’s boundaries.

The first signal is identity isolation across the deployed request path. Look for evidence that users with different permissions receive appropriately different results. The evidence should identify the effective database role, rather than merely showing different names in an interface.

An isolation test should include an attempted action outside the user’s authority and the resulting database behavior. Consistent enforcement would strengthen the case for the architecture. Unexplained credential sharing would weaken claims about user-specific governance.

The second signal is how definition changes affect answers. A business metric rarely remains untouched throughout an application’s life. Teams should look for demonstrations that update a definition and then verify the assistant’s subsequent interpretation.

The meaningful evidence includes the transition itself. Does the assistant use the revised meaning? Can reviewers identify which definition supported an earlier answer? Are affected reference answers updated through an explicit process?

Successful change handling would strengthen the argument for keeping meaning near maintained database objects. Unclear ownership or stale interpretations would show that co-location alone does not deliver consistency.

The third signal is repeatable correctness under representative usage. Evaluations should vary question wording, user authority, and the amount of simultaneous activity. Buyers need to see whether the system remains useful when conditions differ from the original demonstration.

That does not require treating every business question as a benchmark competition. It requires a declared set of expected behaviors. Correct calculations, appropriate refusals, understandable limitations, and acceptable response times should each have evidence.

For teams seeking the EDB semantic layer explained in operational terms, those signals provide a practical decision framework. They turn an architectural proposition into questions that a pilot can answer.

They also avoid an unsupported forecast about which platform wins. The strongest implementation will depend on data placement, identity requirements, and the organization’s ability to maintain definitions. A database-centered approach should be judged against those conditions.

Start with a business question your team already answers reliably, then document its definition, expected result, and access boundaries. Give reviewers enough information to reproduce the result without trusting the assistant’s explanation. Run the same request through appropriately restricted identities, and inspect the database behavior alongside the response. Next, change a relevant definition and verify that the answer follows the approved change. Use the EDB semantic layer to test a specific operating proposition: your organization can maintain shared meaning while enforcing access at query time. Before expanding the pilot, ask whether you can explain every important answer and every important denial.