For the past two years, most organizations have treated generative AI as a conversational interface. The value proposition was simple: ask a question in natural language, get an answer. However, as businesses begin to deploy agentic AI<\/strong>\u2014systems that don\u2019t just answer questions but take actions like querying databases, updating records, or triggering workflows\u2014the risks of this approach become apparent.<\/p>\n When an LLM writes a SQL query directly from a prompt, it is guessing at the structure of your data. It does not inherently know which columns are sensitive, how revenue should be calculated, or whether the user has permission to see specific customer records. This creates a governance gap. If you rely on the prompt to define these rules, you are asking a probabilistic model to perform deterministic security checks. It cannot.<\/p>\n A new architectural pattern emerging on Amazon Web Services (AWS) addresses this by decoupling the agent\u2019s intent from the data\u2019s reality. By placing a semantic layer<\/strong> between the AI agent and the underlying database, enterprises can enforce consistent definitions, row-level security, and audit trails without modifying the agent\u2019s core logic. This post examines a recent implementation using AtScale and Amazon Bedrock AgentCore, illustrating why this separation is critical for enterprise-grade AI.<\/p>\n In a typical direct-access setup, an AI agent connects to a data warehouse (such as Amazon Redshift) and generates SQL queries on the fly. While flexible, this approach suffers from three major flaws:<\/p>\n The solution is to treat data access as a service, not a raw connection. A semantic layer acts as a unified interface that translates natural language requests into precise, governed SQL queries. It ensures that every query, whether generated by a human analyst or an AI agent, uses the same business logic and security policies.<\/p>\n A recent technical walkthrough published by AWS Machine Learning details a “Customer 360” pattern that integrates AtScale (a semantic modeling platform) with Amazon Bedrock AgentCore. This architecture demonstrates how to build a governed environment for agentic AI. The key innovation is the use of the Model Context Protocol (MCP)<\/strong> to connect the agent to the semantic layer.<\/p>\n The process begins when a client sends a request to the Strands agent hosted on Amazon Bedrock AgentCore. Crucially, the system validates the user\u2019s identity via a JSON Web Token (JWT) against the enterprise identity provider before the agent even sees the question. This ensures that the agent knows who is asking, which is essential for downstream security enforcement.<\/p>\n The agent then uses a foundation model (such as Anthropic Claude Sonnet 4.6) to interpret the user\u2019s intent and plan the necessary data retrieval. Instead of writing SQL directly, the agent decides to invoke a tool call to the AtScale MCP server.<\/p>\n This is where the semantic layer adds value. The AtScale MCP server acts as a proxy registered on AgentCore Gateway. When the agent sends its tool call, the gateway injects the user\u2019s credentials. AtScale then resolves these credentials to a specific role, applying row and column filters automatically.<\/p>\n AtScale plans the query against a dimensional model defined in its Semantic Modeling Language (SML). This model is version-controlled in Git and exposed over multiple protocols, including SQL and XML for Analysis (XMLA). The resulting SQL is pushed down to Amazon Redshift Serverless for execution. Because the joins, metric definitions, and security filters live inside the semantic layer\u2014not the prompt\u2014the agent receives a consistent, secure, and auditable result.<\/p>\n The example uses a retail “Customer 360” scenario involving customer profiles, orders, products, and rewards enrollments. The semantic model maps these entities into a star schema:<\/p>\n By defining these elements in YAML files within Git, data engineers can review changes via pull requests. This brings software development best practices to data modeling, ensuring that any change to a metric definition is tracked and approved before it affects AI agents or BI tools.<\/p>\n The adoption of semantic layers for agentic AI is not just a technical preference; it is a strategic necessity for scaling AI safely. Here is what this shift means for organizations:<\/p>\n Because the semantic layer exposes the same model over SQL, XMLA, and MCP, both human analysts using traditional BI tools and AI agents get the same computed answers. This eliminates the “single source of truth” problem where different departments report conflicting numbers because they use different calculation methods.<\/p>\n Data engineers no longer need to write custom connectors for every new AI application. By standardizing on a semantic layer, they can onboard new agents quickly. The agent simply needs to know how to talk to the MCP server, not how to navigate the underlying database schema.<\/p>\n Security is enforced at the point of query planning, not at the point of data storage. This means that even if an agent is compromised or prompts are manipulated, the semantic layer\u2019s row-level security prevents unauthorized data access. The agent never sees the raw data; it only sees the results filtered by the user\u2019s role.<\/p>\n If your organization is moving toward agentic AI, consider these steps:<\/p>\n The era of AI as a mere chatbot is ending. As agents gain the ability to act on data, the integrity of that data becomes the primary constraint on AI\u2019s utility. By building a robust semantic layer, you ensure that your AI agents are not just smart, but also safe, consistent, and trustworthy.<\/p>\nThe Problem with Direct Database Access<\/h2>\n
\n
How the New AWS Architecture Works<\/h2>\n
1. The Inbound Path: Identity and Intent<\/h3>\n
2. The Outbound Path: Governance and Execution<\/h3>\n
3. The Data Model: Dimensions and Measures<\/h3>\n
\n
What This Means for Business Leaders<\/h2>\n
Consistency Across Tools<\/h3>\n
Reduced Development Friction<\/h3>\n
Enhanced Security Posture<\/h3>\n
Next Steps for Implementation<\/h2>\n
\n
Sources<\/h3>\n