Designing a Shared Data Layer for Human and Agent Consumers

Most AI agents never make it to production, and the reason has little to do with how good the underlying model is. Agents fail because they cannot securely reach live business data, cannot reliably figure out what a column or a table actually means across different schemas, and cannot act without a human checking every step along the way. The common response, when a team hits this wall, is to swap in a newer model or throw more compute at the problem. Neither one helps, because the agent still doesn't know which data source holds the answer, what a given field is supposed to represent, or which numbers it's even allowed to touch. A human analyst facing the same confusion can walk over and ask a colleague what a field means, or wait a day for someone to pull an export. An autonomous agent has none of that. It starts cold on every single query unless the surrounding infrastructure hands it structured business context up front. Skipping that step leaves the organization with forked truth: analysts looking at one number, agents reporting a different one, and nobody left who can say with confidence which number is right.

What MCP changes about how agents reach data

The Model Context Protocol is turning into the standard way AI agents connect to data platforms, and that's a real shift in how agentic systems get wired up. But MCP moves data from one place to another. It doesn't make that data correct, current, or trustworthy once it arrives. Whether an MCP implementation actually enforces governance depends entirely on how a given team builds it, not on anything the protocol itself guarantees. The specification published on July 28, 2026, pushed MCP toward a stateless request and response core, meaning MCP servers can now run on ordinary HTTP load balancers without sticky routing or session stores. Operationally, that puts an MCP server on the same footing as any other web service, which is a large part of why adoption is moving so fast. The trouble is that the easier MCP becomes to deploy, the more it matters what sits behind it. An agent wired up to ungoverned tables through a perfectly functioning MCP server will still return confident, wrong answers, because the protocol is the pipe and never the contract. The mistake teams keep making in 2026 is treating MCP as a replacement for clean data or a semantic layer. MCP exposes whatever is sitting behind it, governed or not, and it makes no judgment either way.

Why humans and agents need the same semantic layer

A semantic layer takes messy, inconsistent data structures and turns them into consistent, governed definitions: revenue means one thing, churn means one thing, lifetime value means one thing, and every dashboard, every SQL query, and every AI agent pulls from that same definition no matter who or what is asking. In an architecture built around a shared data layer, MCP handles transport and the semantic layer is the contract underneath it. The same metric definitions serve both a human-facing dashboard and a conversational agent, with agent-specific metadata, synonyms, guardrails, and the like, attached as added context rather than built out as some separate parallel system. Databricks made this idea concrete when Unity Catalog Business Semantics reached general availability: define a metric, a dimension, or a rule once at the data layer, and every dashboard, every SQL query, every notebook, and every AI agent downstream works from that same trusted definition. The Genie AI analyst agent shows what that looks like in practice. Because its Metric Views get compiled into logical queries at runtime, users get the same correct result every time, with Genie resolving metrics from one governed source. That matters for agents specifically, because an agent that runs into ambiguity won't stop and ask for clarification. It will pick a table, run with it, and act, with no flag raised about the uncertainty baked into that choice. A semantic layer resolves the ambiguity before the agent ever starts reasoning, which stops small errors in meaning from turning into wrong answers delivered with total confidence. Left unaddressed, this is how organizations end up with semantic drift: one team defines a metric, a second team copies it, a third team tweaks it slightly, and before long the company is spending its energy managing drift instead of managing meaning. A single governed definition shuts that argument down before it starts. It also solves a harder problem for agents: without business context built into governance, an agent can't tell data it was meant to use from data it merely has the technical permission to reach. Left to its own devices, it will write queries against datasets it should never touch.

Why Supabase teams face this problem faster than they expect

Supabase teams start with a database built for transactional writes, and the moment analytics or agents enter the picture, that same database becomes the wrong tool for the new job. A typical early setup runs Supabase Postgres as the system of record, Supabase Auth for identity, Storage for user files, and Edge Functions for trusted server-side logic, and that's the foundation most teams end up bolting agents onto without rethinking it. Analytical queries behave very differently from transactional ones: they scan and aggregate across huge numbers of rows, while the primary database instance is row-oriented and tuned for fast lookups, inserts, and updates. Running both workloads on the same machine makes them fight each other for the same CPU and memory. Supabase's own recommendation for this situation is a read replica, or Supabase Pipelines for teams that need a purpose-built analytical destination. A replica sounds like the fix, but it runs at the same compute size as the primary, bills separately with plan compute credits not applying to it, and adds disk space at a multiple of what the primary uses. In practice, it roughly doubles the database bill without fixing the governance problem that caused it. Then there's PostgREST, which auto-generates a REST API straight from the Postgres schema and is a big part of why Supabase has become the default backend for AI-assisted apps. The same mechanism that makes that convenient also exposes an entire table the instant it's created, unless Row Level Security and an explicit policy get attached to it first. That risk gets sharper once AI agents start running the KPI queries themselves, because an agent with a direct line into production can read, or even write if permissions are set up wrong, tables it has no legitimate reason to touch at all.

What pre-calculated, governed datasets change about both human and agent access

Pre-calculating metrics into governed datasets, instead of running fresh queries every time someone or something asks a question, is the decision that lets humans and agents work from the same numbers without either one touching production directly. In an agent-first world, the right unit of analytics is a modeled, pre-calculated dataset that both humans and agents can safely consume, because a query can return almost anything depending on how it's written, while a pre-modeled metric returns one governed answer every time. For a human operator, this translates into something concrete: a founder should be able to type "What was net new MRR last week from paid social?" in plain English and get back a chart that matches the number the board already agreed on, without touching a spreadsheet or triggering an argument about whose numbers are right. For an agent, pre-calculated datasets resolve ambiguity before the agent ever starts reasoning. It is reading a governed value that already has one definition attached to it, not picking a table and guessing. Data lineage and version control make this auditable, letting teams trace a wrong answer back to stale or incomplete inputs after the fact. Serving these datasets in a format that lightweight engines can query directly, Parquet files through DuckDB, for instance, means agents get fast, cheap access to real context without ever touching the operational database. Metrics work best when they're calculated ahead of time and pushed out to wherever people actually work, an inbox, a Slack channel, whatever tool the team already lives in, rather than sitting around waiting for someone to remember to check them. A metric pushed to where people work gets acted on; one left sitting archived somewhere does not. A single MCP server exposing these pre-modeled datasets gives every downstream consumer, whether that's a dashboard, an agent, a report, or an API caller, the same interface and the same governed values. The type of consumer asking the question never changes the answer it gets back.

How to enforce governance at the data layer rather than at the application layer

Access controls built for human login sessions were never designed with agents in mind, and applying them to agents doesn't hold up. Every action an agent attempts needs to be checked against policy before it runs, taking into account the content of the request, what the agent has already done earlier in the session, and the current business context, rather than just confirming the agent is holding a valid credential. Security has to apply everywhere the data actually lives, not only inside the AI application itself, so that permissions, masking rules, and regulatory requirements get enforced consistently across databases, warehouses, object storage, and SaaS systems alike. Attribute-based access control stretches governance well past static roles: row-level security makes sure an agent only ever sees the records it's authorized to see, and column-level masking redacts sensitive fields even in queries the agent is otherwise permitted to run. A fraud detection agent, for example, can see transaction amounts and timestamps without ever seeing a payment card number or a customer's name, because governance filters what comes back at the moment the query runs even though the agent has database access. Agents also need to be treated as their own distinct principals, each with unique credentials and access scoped tightly to the task at hand. A support agent and a financial reporting agent should never share an API key or a database credential, even inside the same company. Because agents accumulate access rights over time in ways no organization would tolerate from a human employee, offboarding an agent needs to follow the same discipline as offboarding a person: permissions explicitly revoked, credentials destroyed, and the agent registry updated to reflect it. The safe-access pattern that holds all of this together has four pieces. Agent queries get routed through a gateway, with no direct credentials handed out. Send analytical queries to a read layer that's kept separate from production writes. Use service accounts scoped to the narrowest privilege the task requires. And enforce controls at the level of each individual query, not just once at session login. A deterministic pre-action check underlies all four: the agent's intended action gets evaluated before it executes, not audited afterward, so a misconfiguration gets caught before it can spread rather than discovered once the damage is already done.

Why the Five Eyes and NSA warnings are an infrastructure design signal, not a compliance checkbox

The joint Five Eyes guidance and the NSA's warnings about agentic AI read like engineering critiques, because that's what they are. They describe, almost point for point, the failure mode a governed shared data layer is built to prevent. In May 2026, the Five Eyes alliance published guidance warning that autonomous AI systems are being deployed with excessive privileges, and that the governance mechanisms built for human actors simply don't translate to autonomous agents operating at machine speed. The guidance names Zero Trust architecture, defense-in-depth, and least-privilege access as the required engineering response, and a well-built shared layer architecture embeds these by design. This represents a real shift from the 2023 guidance issued by CISA, the NSA, and the NCSC, which focused on adversarial machine learning risks like training data poisoning and prompt injection. Models in 2026 aren't just answering questions anymore, so the guidance is concerned with operational execution and systemic resilience instead. OWASP's Excessive Agency category names the specific failure at play here: excessive functionality, excessive permissions, or excessive autonomy, an agent acting without human approval on a high-impact action, can produce damaging results across confidentiality, integrity, and availability in whatever systems that agent can reach. The Confused Deputy pattern describes one version of this directly: a trusted agent gets manipulated into carrying out unauthorized actions while still operating under its own legitimate identity, so the system has no obvious signal that anything has gone wrong. The NSA's own report stated that MCP's rapid proliferation has outpaced the development of its security model, which puts the weight of the problem squarely on whatever governance layer sits behind the MCP interface, since that's the point where security either gets enforced or quietly gets skipped. Multi-agent systems make this worse rather than better: when agents call other agents and orchestrate workflows against each other in real time, data can end up processed and combined in ways that violate compliance requirements even when every individual agent stayed within the bounds of its own stated permissions.

What a working shared data layer looks like end to end for a Supabase team without a data team

None of this requires a dedicated data engineering function to build. A founder or a small team can run a governed shared data layer, pre-modeled metrics, separated read workloads, a single MCP interface, without hiring anyone for it, provided the infrastructure is designed around pre-calculating data rather than querying it fresh every time. That architecture rests on three separation points. Production writes stay on the Supabase Postgres primary, untouched by anything analytical. Analytical reads go to a governed read layer, pre-calculated Parquet datasets queried through DuckDB. And agents only ever reach that governed layer through a single MCP server, never the production database itself. Every metric gets exactly one definition, MRR, churn, net revenue retention, calculated once, versioned, and served identically to every consumer: the founder's dashboard, the board export, and the AI agent generating the weekly summary all draw from the same number, regardless of who or what asked for it. An agentic data sandbox, isolating compute, network access, and data state, gives a team a safe surface to test new agent workloads against production-scale data before anything goes live for real. Read-only agent access is the lowest-risk way to start, and it's where most agentic AI adoption actually begins in practice. A team that starts there, with pre-modeled metrics exposed read-only through MCP, already has a governed foundation to build more capable agents on top of later. For a team with no data team at all, the real prescription is to build the governed layer directly into the infrastructure from day one, so that the dashboards and the agents are always answering from the same source, and the metrics can speak for themselves.