MCP + Greenplum in Banking: how to give LLM access to DWH without breaking Data Governance
We are replacing a 14-year-old Oracle DWH with an MPP platform on Greenplum / Arenadata DB under full Data Governance. Model Context Protocol turns LLM access to the warehouse from an ungoverned shortcut into a contract-based API surface.
We are currently in the middle of a project many will recognize from the first paragraph.
There is a banking warehouse built on Oracle Database — about 14 years old. Inside: fragmented business logic, T+2 closing, manual reconciliation between business units, and a permanent “human cache” sitting in Excel.
We are replacing it with an MPP platform based on Greenplum Database / Arenadata DB, with full Data Governance: lineage, business glossary, access control, and a near-real-time ingestion layer (target 0.5–1 hour latency).
That is when AI enters the picture.
And the question is not about SQL.
Not “can Claude write SQL,” but “can we give it access to the DWH without turning it into an ungoverned shortcut.”
The answer is Model Context Protocol (MCP).
Why MCP and not direct database access
Because direct access breaks Data Governance.
An unrestricted LLM:
- ignores the glossary
- breaks lineage
- can bypass security policies
- creates a shadow BI system
For a bank this is unacceptable.
So MCP is not an integration — it is a contract-based access surface.
1. Identity: no service accounts
MCP does not hold privileged credentials.
Instead:
- the user authenticates through the IdP
- MCP receives a short-lived token
- the session runs on behalf of that user
Result:
- all policies (RLS/CLS) are enforced
- AI cannot bypass them
- behaviour matches the regular BI tool
If the analyst cannot see the data in their dashboard, they cannot see it through the LLM either.
2. MCP does not expose SQL — it exposes business operations
The anti-pattern:
run_sql(query)
We ruled it out.
Instead we expose:
regulatory_form_700()liquidity_ratio_snapshot()reconciliation_diff(...)
Each tool is:
- linked to the glossary
- owned by the data team
- kept in version control
- bound by a strict contract
The LLM does not write SQL — it orchestrates business operations.
3. Mapping: glossary → query
The key layer is trivial to state:
Business Term → Trusted Query
The LLM does not invent metrics — it uses approved ones.
4. Observability
Every MCP call is logged:
- user
- tool
- latency
- outcome
These events flow into the same monitoring stack the rest of the bank already uses. AI is not a separate system — it is just another service.
5. Architecture
User → LLM → MCP → Governance → DWH
MCP does not bypass governance — it reinforces it.
Takeaway
MCP is not LLM access to data.
It is a governed API surface on top of the DWH.