Two legs, opposite needs.
Mainstream AI clients — Claude, ChatGPT, Copilot — connect to an MCP server from the vendor's cloud, not from a user's laptop. That single fact splits the design in two: a public, authenticated front door and a private, in-tenant back end — with identity in the middle of every call.
One gateway between any client and your data.
Each leg gets exactly the security its exposure demands.
Client → Gateway · public
HTTPS on 443, Streamable HTTP /mcp. OAuth 2.1 via Entra ID authenticates the user, with strict audience/issuer validation, short-lived tokens, a pre-registered OAuth client and an explicit tool allow-list — no generic "run SQL". WAF / vendor-IP allow-listing in front; a vendor secure tunnel is the escape hatch if no public endpoint is permitted.
Gateway → data · private
Never public. An encrypted tunnel in the pilot; site-to-site VPN / ExpressRoute with a Private Endpoint in production. The Gateway always reads through the governed view layer with a read-only login — the database itself is never exposed.
Gateway → documents
SharePoint / Microsoft 365 via the Graph API with app permissions — or the simplest path, a locally-synced folder that inherits the signed-in account's access. Content: contracts, invoices, metric and source definitions.
Thin views give data. The semantic layer gives meaning.
One unified model is read through thin, governed views — they deliver rows, not meaning. The Gateway therefore carries its own semantic layer, where every metric is re-expressed once, version-controlled, and served identically to every model and surface.
The honest part
Re-expressing business logic that today lives inside dashboard measures is the hardest, most valuable step of the whole build. We say that up front — it's where the real work is.
Verified, not assumed
Correctness is proven against a golden set of questions with independently computed answers, reconciled continuously — and every answer carries source citations.
Defined once
No drift between the AI's number and the report's number: both read the same definition from the same layer.
The Gateway is the enforcement point.
Identity on every call
The Gateway validates the Entra token, resolves the real user, and keys everything downstream — query filters, tool access, audit — to that identity.
Row-level filtering in the views
Server-applied, identity-driven filtering injected in the view query — per business unit, per object, public-vs-confidential flags.
Audited per user
Who asked what, when, and the exact query that ran — append-only, reviewable, yours.
The resolved position, stated plainly: the middle tier over governed views is the primary enforcement point. We do not impersonate users into the database (no on-behalf-of); the database sees a read-only service account while the Gateway enforces identity. Dashboard-level RLS (e.g. Power BI) remains in place for its own reports — it is secondary, not the AI's security model.
Boring, proven building blocks — on purpose.
What a pilot includes
The full two-leg architecture, OAuth identity logged on every call, read-only governed views, audit, golden-set verification — with row-level security deferred and a small full-access user group.
What production adds
Per-user identity propagation with full row-level security and an authorization matrix, SSO rollout, production networking (VPN/ExpressRoute + Private Endpoint, APIM), and a penetration test before go-live.
Want the full picture?
The architecture brief covers network topology, identity flows and the security model in depth — or walk through it live with the people who built it.
Ask your business data anything. Get an answer in seconds.
Start with a discovery call — we'll scope a low-risk pre-study and show you what's answerable on your data.
What to expect: a 30-minute call · we map your data sources · a live answer on your data — no pressure.