The governed data layer for AI agents
Give AI agents certified answers, not warehouse access.
Sembric sits between the warehouse you already run and the agents your teams are building. Your people classify fields and certify the exact aggregates and views agents may use. Agents query only those certified surfaces through MCP or a typed API, with no SQL, no copied data and an audit record for every call.
Works with BigQuery, Snowflake, Trino, Databricks, PostgreSQL and MySQL.
Your warehouse
Tables stay where they are
- orders
- region
- net_amount
- ordered_at
- customers
- email (sensitive)
- full_name (sensitive)
- segment
- support_cases
- notes (sensitive)
- status
- opened_at
Sembric
Only certified surfaces pass
- Fields classified, 3 sensitive withheld
- Steward review approved
- Independent certification, 4 of 4 checks
- Enforced on every call
Your agents
MCP and typed API
sembric_query_productregion, ordered_at:quarter → 4 rowsanswered · auditedcustomers.emailnot a declared field refused · auditedSELECT * FROM customersno route accepts SQL refused
The problem
Every company wants agents on its data. Today’s shortcuts put the data at risk.
Teams are under pressure to connect AI agents to business data. The fastest paths hand an agent far more than the answer it needs, and leave nobody accountable for what it says.
Credentials and raw SQL
The quickest integration hands an agent a service account and lets the model write queries. That account can read every table it can see, and nobody reviewed the query it just ran.
Copies that drift
Exporting tables into a new store for agents creates one more copy to secure. Warehouse policies do not follow the data, and the numbers start to disagree with the source.
Answers nobody vouches for
A model that writes its own joins can return a confident, wrong figure. There is no business definition, owner or check behind it, and no way to tell a good answer from a lucky one.
No record and no limits
When an answer is questioned, teams cannot say which agent asked what, under which identity, or what it was refused. Nothing bounds how much an agent can ask the warehouse for.
How Sembric works
A governed path from table to agent, in four steps
Sembric does not add another copy of your data. It adds review, certification and enforcement between the data you already govern and the agents that need answers.
01 · Discover
Connect what you already run
An owner connects a warehouse with a read-only customer identity per Sembric role. Sembric reads the catalog of existing tables and views. It never ingests, copies or transforms rows.
02 · Classify
Review every field
Columns that look personal start sensitive. The asset’s data steward reviews its classification before anything is published, and sensitive fields can never become measures, dimensions or view columns.
03 · Certify
Prove the answer first
Define an aggregate data product or a governed view with business context. A reviewer who is neither its owner nor its last editor runs expected-answer checks under every granted role, then certifies it for 30 days.
04 · Serve
Agents query only that
Agents discover and query certified surfaces through MCP or the typed API: declared fields, typed filters and bounded limits. Every call is audited, answered or refused.
What an agent sees
Answers when it’s certified. Refusals when it isn’t.
Agents get typed tools, business definitions and caveats, never a connection string. Anything outside a certified surface is refused before a source query runs, and recorded.
→ tools/call sembric_query_product
{
"productId": "net-revenue-by-region",
"dimensions": ["region", "ordered_at:quarter"],
"filters": { "ordered_at": { "gte": "2026-01-01", "lt": "2026-07-01" } },
"limit": 20
}
← 4 rows · certified · expires in 23 days
region ordered_at net_revenue
North 2026-01-01 412880.00
North 2026-04-01 436120.00
South 2026-01-01 298410.00
South 2026-04-01 305990.00
audit answered · caller mcp · key 3f9c…a1→ tools/call sembric_query_product
{
"productId": "net-revenue-by-region",
"dimensions": ["customer_email"],
"limit": 20
}
← refused before any source query
customer_email is not a declared dimension
of this product.
audit refused · undeclared field · caller mcp · key 3f9c…a1steward customers.segment marked sensitive
→ classification changed
sembric certificate withdrawn · product returned to draft
→ agent visibility removed in the same transaction
→ tools/call sembric_list_products
← net-revenue-by-segment is no longer listed
audit certificate withdrawn · notification sentIllustrative synthetic data. Tool names match Sembric’s MCP server.
Agents can
- List the certified products and views granted to their role
- Group by up to three declared dimensions, including day to year time grains
- Filter with typed equality, value lists of up to 50, and ranges on numeric, date and time fields
- Read definitions, caveats and the concepts a surface grounds
Agents cannot
- Send SQL or reach source credentials
- See undeclared, sensitive or nested fields
- Query drafts, expired or withdrawn surfaces
- Release groups smaller than a product’s reviewed minimum
Shortcut vs. Sembric
The difference between access and a governed answer
| Concern | Direct agent access | Through Sembric |
|---|---|---|
| Access | A shared service account that can read whatever it can see | Certified surfaces granted to the caller’s current role |
| Interface | Free-form SQL written by the model | Typed tools over declared fields, filters and limits |
| Data movement | Exports and copies into new stores | Data stays in your warehouse or lakehouse |
| Correctness | Model-written joins with no review | Business definitions with independent expected-answer checks |
| Change | Schema and policy changes go unnoticed | Drift or reclassification withdraws access automatically |
| Accountability | Little or no record of agent activity | Every agent query audited, answered or refused |
| Load | Nothing bounds what an agent asks for | Persistent workspace read budgets before every statement |
Certification
At least two people stand behind every certified answer
The person who defines a surface can’t certify it. An independent reviewer runs distinct expected-answer checks under each granted role’s own source identity, so row policies that change answers per role are caught during review.
Data product
Net revenue by region
| Check under role | Expected | Result |
|---|---|---|
| Analyst · Q1 total | 711,290.00 | pass |
| Analyst · North only | 849,000.00 | pass |
| Viewer · Q1 total | 412,880.00 | pass |
| Viewer · North only | 849,000.00 | pass |
Reviewer is neither the owner nor the last editor · fingerprint unchanged through the final check
- Classification review by the asset’s assigned data steward comes first
- The reviewer must differ from both the current owner and the last definition editor
- Each granted role needs distinct checks; a check can override its expected answer per role
- Governed views also prove every granted identity can read the approved projection
- The reviewed asset fingerprint must stay unchanged through the final check
Safe by default
When something changes, access stops
Governance that only holds on the day of review isn’t governance. Sembric withdraws access as soon as the facts behind a certificate change.
Schema drift stops queries
Before each query Sembric compares the live schema with the certified fingerprint. A mismatch stops the query until the source is rediscovered, reviewed and recertified.
Reclassification withdraws
Mark a column sensitive and every product or view that uses it returns to draft. Re-reviewing cannot quietly recertify an unchanged draft.
Revocation is immediate
Membership, role, the calling key and the certificate are rechecked after every source query, so a revocation mid-query withholds the rows.
Certificates expire
Certificates last 30 days by default. Renewal in the final week re-runs every check; an expired surface returns to draft with an audit record.
Source edits reset trust
Editing or pausing a source withdraws dependent reviews and certificates in one transaction. Resuming requires rediscovery and recertification.
Budgets before contact
Every statement reserves workspace minute and day read budgets before reaching the source, and BigQuery jobs reserve a daily billed-byte allowance.
Your warehouse stays in charge
Built on the engines and policies you already trust
Sembric queries with the customer identity mapped to each Sembric role, so the source engine’s own row and column policies keep applying. Only owners connect sources or change those mappings.
Google Cloud data warehouse
BigQuery
Discover a BigQuery dataset and serve certified aggregates and governed views to agents, with each Sembric role impersonating its own customer service account.
Cloud data platform
Snowflake
Connect a Snowflake schema over the SQL API with one key-pair user and role per Sembric role, and let agents query only certified surfaces.
Federated SQL engine and lakehouse catalogs
Trino
Discover one Trino catalog and schema, including a lakehouse catalog you operate, and serve certified surfaces through role-specific read-only users.
Databricks SQL warehouse with Unity Catalog
Databricks
Connect a Databricks SQL warehouse and one Unity Catalog schema with a separate OAuth service principal per Sembric role.
Native PostgreSQL
PostgreSQL
Connect an existing PostgreSQL schema over verified TLS with a restricted login per Sembric role, keeping row-level security in force.
MySQL 8.0 and 8.4
MySQL
Connect a MySQL 8.0 or 8.4 database over mandatory verified TLS with direct read-only grants per Sembric role.
Built for agents
One MCP endpoint. Eight read-only tools.
Connect Claude Code or any HTTP MCP client with a short-lived, revocable Sembric key, or with user-linked tokens from your identity provider. Applications that don’t speak MCP use the typed REST API, described by an OpenAPI document.
FAQ
Frequently asked questions
Does Sembric copy or move our data?
No. Customer data stays in its source. Sembric stores metadata, definitions, classifications, checks, certificate state and audit records, and runs bounded, parameterized reads in your engine when a certified surface is queried.
Can an agent run its own SQL through Sembric?
No. No agent route accepts SQL. Agents choose from declared dimensions, typed filters and a bounded limit on surfaces certified for their role, and Sembric builds the source query.
How is this different from giving an agent a read-only service account?
A read-only account can still read every table it can see and lets the model write any query. Sembric narrows that to reviewed fields and certified definitions, checks the answers before release, rechecks access after every source query, and audits each call — answered or refused.
Which agents can use Sembric?
Any client that speaks the Model Context Protocol over HTTP, such as Claude Code, plus applications that call the typed REST API. Agents authenticate with a short-lived, revocable Sembric key or a user-linked token from your identity provider.
What happens when a table’s schema changes?
Before every query Sembric compares the live schema with the certified fingerprint. A mismatch stops the query until the source is rediscovered, reviewed and recertified.
Is Sembric generally available?
Sembric is available for pilots. Its commercial release depends on acceptance gates that are still open, and we share the current evidence with pilot customers.
Put your first certified data product in front of an agent.
Tell us which warehouse you run and what your agents need to answer. We will help you connect a source, certify a first surface and query it over MCP.