Denodo and AWS Define the Trust Boundary for Agentic Data

AI 요약

• What happened: Denodo announced new integrations with Amazon Bedrock AgentCore, Amazon SageMaker Catalog, and Amazon Quick.
  • The May 18, 2026 announcement frames live data access, a semantic layer, MCP support, and AWS agent controls as one foundation for enterprise agents.
• Why it matters: The agent infrastructure bottleneck is moving from MCP server connectivity to data meaning, permissions, freshness, and lineage.
• Builder impact: Enterprise AI teams need to verify not only what an agent can see, but whether that data is interpreted inside current business rules and user permissions.
• Watch: This is still product integration news. The real test is MCP configuration, catalog quality, access policy design, and audit logging in production.

On May 18, 2026, Denodo announced new AWS integrations. The short version is that Denodo wants AI agents to access enterprise data more safely. But that sentence hides the more important shift. The announcement is not mainly about adding another connector count to a vendor slide. It is about the conditions an agent needs before it can read business systems and act on them: which data is trusted, which user can access it in which context, what the data means in business language, and whether the organization can later prove what the agent used as evidence.

Denodo is approaching that problem from its home territory: logical data management and semantic layers. On the AWS side, the announcement brings in Amazon Bedrock AgentCore, Amazon SageMaker Catalog, and Amazon Quick. AgentCore is the control plane around agent identity, routing, access, and runtime boundaries. SageMaker Catalog focuses on discovery, metadata, lineage, and governance for data and AI assets. Amazon Quick is the generative BI and agentic workflow surface where users meet the system. Denodo is positioning its platform between those layers, offering live, zero-copy, governed access to hybrid and multi-cloud data.

The interesting part is how closely this maps to the agent market's current refrain. Nearly every vendor now talks about MCP. "Expose our tool as an MCP server." "Let agents call internal systems." "Connect Slack, GitHub, Salesforce, and databases." Those are useful moves. Standardized connectivity lowers integration cost. But the more systems an agent can reach, the sharper the next questions become. Is the data the agent just queried current? Do finance and sales use the same metric name differently? When user A can see a column and user B cannot, where is that enforced? If the agent reaches a bad conclusion, can the team trace which source data and policies led to the action?

Denodo's announcement lands exactly there. The company argues that AI agents are hard to trust when they lack real-time awareness, operate on incomplete data, or move outside governance boundaries. The useful framing is that this is not only a model problem. It is a data problem. Swapping in a stronger frontier model does not fix ambiguous metrics, stale operational state, or a permission model that gets bypassed through a tool server. A larger model can write more convincing prose over bad inputs, but it does not make those inputs governed.

What Denodo Is Attaching to AWS

The first axis is Amazon Bedrock AgentCore. AWS describes AgentCore as a platform for building, deploying, and operating effective agents securely at scale. The recurring concepts in its FAQ and documentation are identity, gateway, scoped access, secure permissions delegation, and observability. In Denodo's announcement, authentication, request routing, and access control matter most. The picture is that Denodo supplies data meaning and allowed usage, while AgentCore manages which identity and policy context is used to process the request.

The second axis is Amazon SageMaker Catalog. AWS's SageMaker Catalog page describes a place to discover and govern data, AI models, BI dashboards, and applications. It also highlights generative AI-created metadata, a business glossary, fine-grained access controls, data classification, and data and ML lineage. Denodo says it will connect SageMaker Catalog business metadata and context to Denodo-powered data access, so agents can interpret data as business concepts rather than raw column names.

The third axis is Amazon Quick. The Amazon Quick MCP server documentation describes MCP as the standard for attaching custom tools and integrations to Quick. Users can connect MCP servers so conversations and scheduled agents can use external systems such as databases, internal APIs, and developer tools. From Denodo's perspective, Quick becomes the user and agent surface, Denodo MCP becomes the data access tool, and the AWS plus Denodo policy layers coordinate access below it.

The table matters because each product is not trying to be the same kind of "agent platform." AgentCore is closer to runtime and control. SageMaker Catalog is closer to data governance and asset discovery. Quick is closer to the analysis and automation surface for business users. Denodo ties them together as a data meaning layer. In the agent era, that division of labor matters. MCP is the grammar of tool calls. Trust comes from the catalog, semantic model, identity, masking, lineage, and runtime policy moving together.

The Next Problem After MCP Connectivity

MCP is quickly becoming a default language for AI agent ecosystems. If databases, internal APIs, and SaaS products can expose capabilities through a common protocol, developers do not need to build bespoke plugins for every tool. That is a real improvement. But a standard call format does not automatically govern the meaning and permissions of the thing being called.

Take a sales database with a column called revenue. One team may use it for booked revenue. Another may use it only for recognized revenue. One region may include tax, while another excludes it. Executives may be allowed to see all customers, while account owners can only see their own accounts. Customer names may be visible while contract terms must be masked. When a user asks an agent to "find risky customers this quarter and draft an action plan," simple SQL generation is not enough to handle those differences.

Denodo's semantic layer and governance pitch targets that gap. The company says it provides more than 200 native connections, including enterprise systems such as SAP, Oracle, and Salesforce, along with controls such as attribute-based access controls, dynamic data masking, and end-to-end lineage capture. Those features were already relevant in traditional BI and data virtualization. Agents change the stakes. When a human reads a dashboard, there is still room for interpretation and skepticism. When an agent uses the same data to call another system or advance a workflow, a weak data foundation can become an automated operational error.

RAG Indexes Are Not the Same as Live Data

For much of the last two years, the default enterprise AI answer was RAG. Put documents and data into a vector index, retrieve the nearby chunks for a user question, and pass those chunks to a model. That pattern remains useful. But it has limits for agents that operate against current business state. Inventory, transactions, contract status, customer segments, security permissions, and approval stages all change. A document indexed yesterday does not guarantee today's operational truth.

Denodo's emphasis on live, zero-copy access matters in that context. Instead of copying everything into an AI-specific store, the design keeps source systems and policies in place and reaches them when needed. That does not mean live access is always easier or faster. Live queries face latency, source system load, cache policy, and failure propagation. But for regulated organizations, or companies with data spread across multiple clouds and on-premises systems, copying can create its own risk. Teams must track where data was copied, whether masking policies apply to the copy, and whether deletion or retention rules propagate to every derived index.

Agents make the problem harder. When a user writes a direct query, the scope is relatively explicit. An agent receives a goal, queries data several times, forms intermediate conclusions, and then calls other tools. Freshness and authorization cannot be applied only to one API call. The system has to know which user the agent is acting for across the session, which policies and budgets apply, and which data led to which result. That is why the combination of a runtime control layer such as AgentCore and a data meaning layer such as Denodo reads as more than partner language.

Builders Should Test More Than Connection Success

For engineering and platform teams, this announcement changes the checklist. Older demos often centered on whether an MCP server connects, whether a natural-language question turns into SQL, and whether a dashboard answer appears. Those are baseline checks. The more important checks come next.

First, does user identity propagate end to end? A demo is easier if every agent query runs through one service account. Real organizations need different access policies based on role, department, region, and data use purpose. If AgentCore Identity or IAM, Denodo access controls, and source-system permissions disagree, the agent may see too much data or fail to see what it legitimately needs.

Second, is the semantic layer actually maintained? "Add business context" sounds tidy in a press release. In practice it requires ownership, glossary management, certification, lineage, deprecation, and metric definition work. To build a trustworthy data layer for agents, data teams and business teams have to agree on terms, then ensure the model and catalog follow that agreement. A good MCP server does not replace this work. It exposes semantic debt faster because more users can reach more data with less friction.

Third, can the team trace failures? When an agent reaches the wrong conclusion, saying "the model hallucinated" is not enough to repair the system. Teams need to see which datasets were queried, which rows and columns were masked, which business metadata was referenced, which policy decisions were made, and how an intermediate answer led to the next action. Denodo lineage, AgentCore observability, and SageMaker Catalog asset tracking only become valuable if that debugging path connects in practice.

Competition Is Moving Down the Data Stack

This announcement is not only a Denodo story. Databricks is using Unity Catalog to define governance boundaries for data and AI. Snowflake is pairing Cortex with its data cloud to keep AI applications close to governed data. Microsoft Fabric, Google Dataplex, Collibra, Alation, Informatica, and Atlan are all reinterpreting catalog and governance products in agent-era language. The difference is where each vendor starts. Model companies start from agent APIs and tool calling. Cloud providers start from runtime and identity. Data platforms start from catalog, lineage, and semantic layers. Business SaaS vendors start from real workflows and permission models.

Denodo's position is specific. It is not a frontier model company, and it does not control the full cloud runtime the way AWS does. It starts from the older, less glamorous data integration problem: logically combining many sources, reaching them without copying everything, and maintaining a semantic layer. Whether that becomes a major market differentiator is still open. But the problem itself is clear. The more agents take on real work, the more important it becomes to ask whether the world they read is organized.

Community reaction appears more focused on that problem than on this specific announcement. I did not find a major Hacker News or GeekNews discussion around the Denodo release itself. Reddit discussions around AWS and MCP are closer to practical questions about using AgentCore in production, managing MCP registries and runtime state, and understanding where AWS-specific constraints differ from other platforms. BI and data engineering discussions remain skeptical of claims that AI can simply replace SQL or catalogs. The more durable theme is that AI agents need reliable metadata and semantic layers before they can support stable decisions. Denodo's announcement fits that broader current.

What Still Needs Proof

It would be too much to say that a Denodo and AWS integration solves the agent data problem. The announcement describes direction and feature scope, while deployment details will determine the outcome. Teams still need to inspect which permission model the MCP server uses, how Quick scheduled agents preserve user-specific policy, what happens when AgentCore Gateway policy and Denodo policy conflict, and how automatically SageMaker Catalog metadata synchronizes with Denodo's semantic model. For organizations spread across countries and regulatory zones, "no data movement" is not the whole answer. Query execution location, log storage, caching, and audit retention matter too.

There is also an operating-cost question. Live, governed, semantic access requires more organizational agreement than a simple vector index. Someone has to assign data owners, maintain a business glossary, test masking rules, validate lineage, and observe agent tool calls. That is heavy for a short-term demo. But once agents execute real business tasks, the cost is difficult to avoid. Adding the trust layer later can mean revisiting MCP servers, agent prompts, copied datasets, and permission exceptions that were already built.

So this news should not be read only as an inflated partner announcement or as a finished solution. The better reading is that it points to where the next bottleneck in agent infrastructure is moving. In 2024 and 2025, the center of gravity was model calls, RAG, tool calling, and MCP connectivity. In 2026, that connectivity is meeting enterprise data and business permissions. The needed layer is not a longer plugin list. It is a way to bring data meaning and access policy into the agent execution path.

Denodo and AWS make that direction visible. For an agent to be useful inside an enterprise, it has to read the world. But the enterprise world is not a few files and APIs. It is old ERP systems, new SaaS tools, data warehouses, departmental definitions, regional regulations, user-level permissions, and audit logs layered on top of one another. If that structure remains unmanaged, handing action to agents can produce faster confusion before it produces faster automation.

The practical message is simple: do not stop at connecting MCP servers. Ask what the agent's data means, where it came from, how fresh it is, who is allowed to see it, and how its lineage is preserved. Then check whether those answers carry through runtime policy and user experience. That trust boundary is the place Denodo is trying to occupy with AWS. While model competition continues in public, control over the data floor beneath agents is quietly becoming one of the more important battlefields.