.jpg)
TL;DR
- A semantic layer for human BI users is designed for consistency and reuse; one serving AI agents in a multi-tenant product must also stand between an autonomous system and customer data.
- Row-level security enforced only at the application layer is not sufficient when an agent generates or executes queries independently.
- Without canonical metric definitions, two agents can return two different answers to the same customer question.
- Model Context Protocol and LLM function-calling expose your semantic layer directly to agents, making governed definitions a security boundary.
- Production-grade agentic analytics combines a code-defined semantic layer with an embedded framework that enforces tenant isolation and auditability.
What a Semantic Layer Actually Does — And Why That Changes When the Consumer Is an Agent
AI can scaffold a dashboard in minutes. The production risk underneath doesn't shrink at all — and nowhere is that clearer than at the data access layer.
A semantic layer for AI agents is a governed data access layer that exposes canonical metric definitions, enforces row-level security per tenant, and produces an auditable record of what was returned to whom — designed for machine consumption rather than human analysts. Human-facing BI has tolerance for review, interpretation, and correction. Agent-facing analytics has less tolerance because the answer may be generated and delivered directly to a customer. That shift in consumer type makes governance mandatory, not advisory.
In the modern data stack, a semantic layer sits between raw data and the tools that consume it, translating physical tables into business meaning: metrics, dimensions, business rules, and the relationships between them. Cube and the dbt Semantic Layer (powered by MetricFlow) both do this well for BI tools and human analysts, where a slightly wrong answer gets caught in a dashboard review. When AI systems replace the human in that loop, the semantic model becomes the last line of defence. Business logic encoded incorrectly, or semantic layer definitions that silently vary between tenants, produces answers that go straight to customers with no review step.
We've seen this gap widen as teams move from internal analytics to customer-facing products. A semantic layer designed primarily around analyst productivity doesn't automatically carry the identity propagation, tenant isolation, or audit trails that a multi-tenant AI agent deployment requires. That difference is architectural, not cosmetic.
The Cross-Tenant Data Leak: A Failure Scenario That Makes Governance Concrete
A customer opens your product and asks the AI agent: "Why did our active users spike last Tuesday?" The agent calls your semantic layer via an MCP function, generates SQL against your events model, and returns a confident answer. The numbers are wrong. They belong to a different tenant.
The failure mode is not hard to imagine. If the agent can call the semantic or data layer outside the same request path that normally applies tenant context, application-layer row-level security is no longer enough. When an agent calls a semantic layer through function-calling or Model Context Protocol, it generates SQL at runtime, and if row-level security isn't enforced at the model layer, the generated query has no predicate scoping it to the requesting tenant. The agent doesn't know. The customer doesn't know. The answer just looks right.
A common architectural failure mode is assuming the application layer handles tenant isolation, without accounting for the fact that an agent can call the data layer directly, bypassing that path entirely.
A broken chart is a support ticket. A cross-tenant data leak is a breach. The difference is why governance can't be an afterthought bolted on after the agent works.
Internal BI vs Customer-Facing Agentic Analytics: What the Semantic Layer Must Do Differently
Most semantic layer tooling was designed with a single primary consumer type in mind: a human analyst inside one organisation. A semantic layer for BI users is often designed around consistency, reuse, and analyst productivity. A semantic layer for AI agents still needs those things, but the failure mode changes: the layer may now be the thing standing between an autonomous system and customer data.
| Dimension | Internal BI | Customer-facing agentic analytics |
|---|---|---|
| Consumer type | Human analyst | AI agent (machine) |
| Tenancy model | Single-tenant | Multi-tenant |
| Failure mode | Wrong answer | Wrong tenant's data |
| Governance surface | Advisory (catch mistakes) | Load-bearing (prevent breaches) |
The shift from advisory to load-bearing is the one that bites. In internal BI, governance is a quality rail. In a customer-facing product, it's a security boundary.
MCP and Function-Calling: How Agents Actually Reach Your Semantic Layer
Two patterns dominate how LLMs reach structured data today: function-calling (where the model selects a named tool from a schema and passes typed arguments) and Model Context Protocol (MCP), Anthropic's open standard for connecting assistants to systems where data lives, in a portable, host-agnostic way. Both patterns share the same load-bearing assumption: the agent calls a named capability, not a query it constructs itself. That named capability is where your semantic layer either earns its place or fails.
MCP can expose semantic-layer capabilities as tools or resources that an agent can discover and invoke. Depending on the implementation, those tools may resolve canonical metrics, generate SQL, execute queries, or return governed results. When a tool definition reads get_metric(name: "monthly_revenue", tenant_id: "acme-corp"), the agent isn't writing SQL. It's invoking a canonical definition. The semantic layer is what sits behind that definition and resolves it consistently.
The critical point is that MCP standardises access; it does not automatically enforce the governance rules behind that access. Protocol access is not governance. If agents can call tools, the tools themselves need to enforce identity, scope, and auditability. This is why metric naming is not a cosmetic decision. If revenue is defined in three places — one dbt model, one Cube measure, one ad-hoc view a data engineer built last quarter — two agent runs can resolve the same question through different definitions and return conflicting numbers. The fix isn't better prompting; it's a single, authoritative metric definition the agent resolves against every time. Embeddable anchors that in metrics and models defined in code, so whatever agent calls the endpoint gets the same canonical answer.
Five Things Your Semantic Layer Must Do Before You Let an Agent Answer Customer Questions
Before you route a customer question through an AI agent, the semantic layer underneath it needs to clear a higher bar than it ever did for a human analyst. Here's what we check before we'd call it production-ready.
Row-level security enforced at the model layer, per tenant. Not in the application, not in a middleware wrapper — at the data model itself. If row-level security is applied anywhere else, a misconfigured agent call can bypass it entirely.
Canonical metric definitions no agent can misinterpret. Revenue, churn, active users: every metric needs a single, authoritative definition written in code. dbt does this well for internal analytics; the requirement doesn't change when the consumer is an agent rather than an analyst.
Tenant context bound server-side by the runtime. Each customer's context — their org ID, their data scope — must be bound server-side by the runtime, not supplied as a free-form argument the agent can invent or override.
Access policies that scope what a given role can query. Access policies determine which models and measures a specific role can reach. Without them, an agent operating on behalf of a read-only user can still call admin-level aggregations.
An auditable trail of what was returned, and to whom. When something goes wrong, and it will, you need a record. Not just query logs, but a trace linking each agent response to the tenant, role, and metric definition that produced it.
The risk looks like this: a team skips item three, and doesn't notice until a customer flags that their "usage" numbers look suspiciously high. They were seeing another tenant's rows.
What the Production-Grade Version Actually Looks Like
The governed stack isn't one thing. It's a semantic layer with metrics and models defined in code, sitting underneath an embedded analytics framework that enforces row-level security, tenant isolation, and access policies outside the generated queries. The semantic layer answers "what does this metric mean." The framework answers "who is allowed to see it, and can we prove what we returned."
Cube, dbt, and similar tools can be part of the answer — especially for canonical metric definitions, reusable modeling, and lineage. The question is whether the full runtime around the agent also handles tenant context, permissions, environments, and auditability.
Embeddable's model is code-defined data models and metrics, enforced row-level security and access policies, environment-aware deployment, and auditability across embedded analytics experiences. That means agents can generate or call analytics experiences without becoming the place where tenant isolation or metric truth is defined.
Frequently Asked Questions
What Is a Semantic Layer for AI Agents and How Does It Differ from a BI Semantic Layer?
A semantic layer for AI agents is a governed data access layer that enforces row-level security per tenant, exposes canonical metric definitions, and produces an auditable record of what was returned to whom. A semantic layer for BI users is often designed around consistency, reuse, and analyst productivity. A semantic layer for AI agents still needs those things, but the failure mode changes: the layer may now be the thing standing between an autonomous system and customer data. When an agent is the consumer, there is no human in the loop to catch errors, so governance stops being advisory and becomes load-bearing infrastructure.
Why Does Row-Level Security Need to Be Enforced at the Semantic Layer Rather Than in the Application?
If the agent can call the semantic or data layer outside the same request path that normally applies tenant context, application-layer row-level security is no longer enough. If row-level security only lives in the application, the agent's generated SQL has no tenant predicate and can return another tenant's data without either the agent or the customer knowing.
How Does Model Context Protocol (MCP) Connect an AI Agent to a Semantic Layer?
MCP can expose semantic-layer capabilities as tools or resources an agent can discover and invoke. For example, an MCP server might expose a get_metric tool that accepts a metric name, time range, and tenant-scoped context, then resolves that request through the governed semantic layer. The important point is that MCP standardises access; it does not automatically enforce the governance rules behind that access. Whatever governance the semantic layer enforces (or fails to enforce) is inherited directly by the agent's output.
What Are Canonical Metrics and Why Do AI Agents Need Them to Return Consistent Answers?
Canonical metrics are single, authoritative definitions of measures like revenue, churn, or active users, defined once in the semantic layer and used everywhere. Without them, two agent runs can resolve the same question through different definitions and return conflicting numbers, with no way to determine which is correct.
Can Existing Semantic Layer Tools Like Dbt or Cube Handle Multi-Tenant, Customer-Facing Agentic Analytics?
Existing semantic-layer tools can solve important parts of this problem, especially metric consistency and reusable modeling. Some also provide access-control primitives. But customer-facing agentic analytics adds runtime requirements that are easy to underestimate: tenant identity propagation, enforced per-tenant scope, role-aware access policies, environment promotion, and auditability for each agent response. In practice, teams need either a semantic layer designed for that runtime or an embedded analytics framework around it.
