The MCP Trust Problem: Why Model Context Protocol Needs a Governed Data Layer Behind It

The MCP Trust Problem: Why Model Context Protocol Needs a Governed Data Layer Behind It

MCP standardizes how agents reach enterprise data and leaves identity, policy, cost, and audit to you. The architecture that closes that gap is a governed query layer between the MCP server and the store.

By

Billy Allocca

Table of Contents

The MCP Trust Problem: Why Model Context Protocol Needs a Governed Data Layer Behind It

MCP (Model Context Protocol) standardizes how agents call tools and read data. It does not decide who an agent acts for, what it may see, what it may spend, or what gets logged. Safe MCP places a governed query layer between server and data store, so agent requests meet the same identity, policy, budget, and audit controls as human queries.

Anthropic published MCP on November 25, 2024 [1]. OpenAI added remote MCP servers to its Responses API and joined the steering committee on May 21, 2025 [2], and on December 9, 2025 the protocol moved under the Linux Foundation's Agentic AI Foundation, reporting more than 97 million monthly SDK downloads and roughly 10,000 active servers [3]. The incidents followed the adoption curve. On May 26, 2025, Invariant Labs showed that a malicious issue in a public GitHub repository could steer an agent on the official GitHub MCP server into publishing private repository contents [4]. In July 2025, General Analysis showed an agent using the Supabase MCP server under a service_role key, which bypasses row-level security, read an integration_tokens table and pasted it into a support ticket because a customer had typed instructions into that ticket [5]. In both cases the protocol worked as designed; everything it leaves to the implementer failed.

The post on why one control plane is the only scalable answer for enterprise AI governance covers the organizational side of this argument. This guide covers the architecture.

What Does MCP Do and What Does It Deliberately Leave Out?

MCP is a JSON-RPC 2.0 protocol with three server primitives (tools, resources, prompts) and an optional OAuth 2.1 layer; it names security obligations and defines none of the mechanisms. The specification says so directly: "MCP itself cannot enforce these security principles at the protocol level," followed by a SHOULD-level recommendation that implementors build their own consent flows and access controls [6]. The tools section requires servers to "implement proper access controls" and "rate limit tool invocations," and asks clients to "log tool usage for audit purposes," without defining what a policy or a log record looks like [7]. The authorization specification forbids passing the client's token upstream: a server calling another API "MUST NOT pass through the token it received from the MCP client" [8], which protects the upstream system and also means the end user's identity stops at the MCP server unless you build a path for it.

Capability

MCP defines it

Left to the implementer

Tool discovery and invocation

Yes, tools/list and tools/call with JSON Schema [7]

Which principal may call which tool

Client-to-server authentication

Yes, OAuth 2.1 for HTTP transports [8]

Authorization server, scope design, consent storage

Identity propagation to the data store

No; token passthrough is forbidden [8]

Mapping the delegated user to a database role, row filter, or column mask

Authorization policy (RBAC, ABAC)

No; "implement proper access controls" is the full text [7]

Policy engine, policy language, enforcement point

Audit logging

No; clients "SHOULD log tool usage" [7]

Record schema, retention, correlation with the human user

Rate limiting and cost control

No; servers "MUST rate limit" [7]

Limits per principal and per token budget

Untrusted tool results

No; annotations are "untrusted unless they come from trusted servers" [7]

Detecting injected instructions in returned data

Role-based access control (RBAC) grants permissions to named roles, and attribute-based access control (ABAC) evaluates attributes of the principal, the resource, and the request at decision time; MCP carries neither, only a bearer token and a JSON payload.

What Are the Security Risks of Connecting MCP Directly to Enterprise Data?

An MCP server that proxies straight to a production store hands every connected agent the server's credential, and three attack surfaces open at once. Simon Willison named the underlying condition the "lethal trifecta" on June 16, 2025: an agent with access to private data, exposure to untrusted content, and a way to communicate externally can be made to leak the data, and MCP "encourages users to mix and match tools from different sources" so the conditions co-occur by default [9]. OWASP catalogs the mechanisms as LLM01:2025 Prompt Injection, including indirect injection through "external sources (websites, files)" [10], and LLM06:2025 Excessive Agency [11]. Prompt injection is content, in a user message or in data the model reads, that changes model behavior in ways the operator did not intend; tool poisoning is the variant carried in a tool's own description, which Invariant Labs demonstrated on April 1, 2025 with a tool that claimed to add two numbers and read SSH keys instead [12].

Attack surface

With MCP direct to store

Disclosed example

Mitigation at the governed layer

Prompt injection through data responses

A row, ticket, or issue contains instructions; the model reads it as a tool result and runs the next query for the attacker

Supabase MCP, July 2025: injected ticket text produced two SQL queries that read and republished integration_tokens [5]

The delegated user's row filters and column masks apply regardless of what the model asks, so the injected query returns only what the user could already see; PII in the request or response is redacted or blocked, with the reason logged

Lateral movement across tools

One poisoned result redirects the agent to a second tool or dataset connected for another purpose

GitHub MCP, May 2025: a public issue steered the agent into private repositories on the same token [4]; tool "shadowing" rerouted email through a second server [12]

Every call is authorized against the same identity and policy as a human query, so the second hop fails at the policy decision point instead of succeeding on a shared credential

Unbounded query cost

Agents loop, retry, and fan out; a SELECT * over a wide table becomes millions of context tokens or thousands of warehouse credits with no owner

The tools spec requires rate limiting and defines no budget model [7]

Per-role token budgets and per-request spend ceilings stop the loop; row and byte caps bound the result; deterministic queries route to the engine with zero model tokens

The cost surface produces an invoice instead of a breach notice, which is why it gets the least attention; the post on AI token spend governance covers the budget model. Supply chain belongs in the threat model too: CVE-2025-6514, disclosed by JFrog on July 9, 2025 with a CVSS score of 9.6, let a malicious MCP server run operating system commands on the client through a crafted OAuth authorization_endpoint URL in mcp-remote 0.0.5 through 0.1.15 [13].

How Does a Governed Query Layer Make MCP Safe for Enterprise Data?

The safe architecture interposes a governed query layer between the MCP surface and the store, so the MCP server holds no data credential at all. A governed query layer is a federated query engine paired with a policy engine and an audit sink, where every query carries the identity of the human the agent acts for and is rewritten at planning time to include that identity's row filters and column masks. The MCP server becomes a thin adapter that translates tools/call into a query against that layer.

This is the enforcement point human analysts already pass through, which is why it works. Apache Ranger supports row-level filtering and column masking as policy types [14], so a customer_pii tag produces one policy that applies whether the query arrives from a notebook or an agent, and Keycloak brokers identity from LDAP, Active Directory, SAML, and OpenID Connect providers into one token [15], so the delegated user in an agent request is a principal the warehouse already knows. The guides on what multi-agent systems need from your data layer and on column-level security when agents query your data go deeper on each half.

Property

MCP direct to store

MCP through governed query layer

Credential held by the MCP server

Service account or service_role key shared by every agent [5]

None for data; the server presents the delegated user's identity

Principal the database sees

The MCP server

The human user plus the agent as a second principal

Row and column policy

Whatever the service account can see

Ranger row filters and column masks per user, rewritten into the plan [14]

Response to injected instructions

Executes them if the credential allows

Bounded to the user's own entitlements; PII redacted or request blocked, reason recorded

Cost ceiling

None unless each tool author adds one

Per-role token budget, per-request spend ceiling, row and byte caps

Audit record

Server logs showing the service account, if any

One event per request naming agent, user, tool, decision, rows, tokens, reason

Adding a data source or agent framework

New server, new credential, new policy silo

Register the source or point the framework at the same endpoint; governance is inherited

Putting policy in each MCP server makes every server author a security engineer and every new server an audit target. Putting it in the query layer means a single policy and a single log, with MCP servers reduced to thin adapters.

What Should a Governance Event Log for MCP Queries Contain?

An MCP audit record is useful only if it binds the agent, the human it acted for, the policy decision, and the resource consumed into one row. The Supabase incident produced two syntactically correct queries under a valid credential, so a database log alone showed normal traffic [5]; the governed layer also sees the tool name, the delegated user, the policy that fired, and the token count.

Field

Allowed request

Blocked request

Timestamp

2026-09-10T14:22:07Z

2026-09-10T14:22:41Z

Agent principal

svc-agent-support-triage@tenant-eu

svc-agent-support-triage@tenant-eu

Delegated user

m.okafor@example.com (role: support_analyst)

m.okafor@example.com (role: support_analyst)

Tool

query_tickets

query_table

Policy decision

ALLOW; column mask on tickets.customer_email; row filter region = 'EU'

DENY

Rows returned

42

0

Tokens

0 model tokens (deterministic route to Trino); 1,180 context tokens

0

Reason

Ranger policy pol-2291 matched role support_analyst on tag customer_pii

Table integration_tokens carries tag secrets; no policy grants role support_analyst; request text matched injection pattern

Because agent principal and delegated user are separate fields, a reviewer can answer "what did this agent do across all users" and "what was done on behalf of this person" from one table, and because the reason is policy-engine text, the log explains itself six months later.

Why Not Just Put OAuth Scopes and Read-Only Mode on the MCP Server?

Scopes and read-only mode reduce blast radius and should be used, and they leave the trust problem open because they operate on the wrong principal. An OAuth scope describes what the client application may ask the server to do; it says nothing about which rows the human behind the request may see, and the authorization spec stops the token at the server boundary [8]. General Analysis recommended read-only mode after the Supabase disclosure, and the attack they demonstrated was a read [5]. Read-only mode would have stopped the write-back into the ticket, and the model would still have loaded every integration token into its context, where the next tool call could carry it anywhere.

The MCP security best practices document names the failure mode: "Treating claimed scopes in token as sufficient without server-side authorization logic" [16]. Noma Security reached the same conclusion about GitHub Agentic Workflows on July 7, 2026, after bypassing GitHub's injection filter with minor rewording: "a filter is a backstop, not a boundary" [17]. The policy engine that touches the data is the boundary.

NexusOne Governs MCP Requests With the Same Identity and Policy as Human Queries

NexusOne carries MCP and tool calling on its AI & Data Control Plane router, so an agent's tools/call hits the same boundary as a human query. Identity from Active Directory, Okta, LDAP, or SAML is federated into one Keycloak layer [15], and each request carries the agent principal and the delegated user. A policy defined once in Apache Ranger is enforced across Trino, Apache Spark, Apache Kyuubi, and S3 object storage per object, so the row filter and column mask that bind the human bind the agent acting for them [14]; tagging a dataset in DataHub and mapping a role to the tag generates the policies.

The semantic router then classifies the request. Deterministic questions route to the federated query engine with zero model tokens; requests carrying jailbreak or PII patterns are blocked before any model sees them, reason logged; per-role token budgets cap cost; PII is redacted before anything reaches a frontier model; every request is logged. The layer runs identically on-prem, cloud, hybrid, or air-gapped on open formats such as Apache Iceberg, and is currently the data and AI layer for a Top 3 US bank. To trace an agent request through your estate, book an expert consultation.

Key Takeaways

  • MCP defines connectivity and client authentication, states that it "cannot enforce" security principles at the protocol level, and leaves policy, identity propagation, audit, and rate limiting to the implementer.

  • An MCP server that holds a data credential gives every connected agent that credential, which was the precondition for the GitHub (May 2025) and Supabase (July 2025) disclosures.

  • Prompt injection through data responses, lateral movement across tools, and unbounded query cost are all bounded by per-user policy and per-role budgets enforced at the query layer.

  • A governed query layer holds the only data credential, rewrites each query with the delegated user's row filters and column masks, and emits one audit event per request naming agent and user separately.

  • OAuth scopes and read-only mode remain backstops; the boundary is the policy engine that touches the data.

FAQ

What Is MCP (Model Context Protocol) and How Does It Handle Enterprise Data?

MCP is an open protocol, published by Anthropic in November 2024 and now governed by the Linux Foundation's Agentic AI Foundation, that standardizes how AI applications discover and call tools and read resources over JSON-RPC. It defines the message format and an optional OAuth 2.1 flow between client and server, and it does not define authorization policy, identity propagation to the data store, audit records, or cost limits, so the safety of an enterprise deployment is determined by what sits behind the server.

How Do You Secure and Govern MCP in an Enterprise?

Remove data credentials from MCP servers and route every tool call through a governed query layer that knows the delegated user. Enforce row filters and column masks per user in a policy engine such as Apache Ranger, federate identity through one provider such as Keycloak so agents and humans share a principal model, record one audit event per request with agent, user, tool, decision, rows, tokens, and reason, and add per-role token budgets so a looping agent has a cost ceiling.

How Does Model Context Protocol Handle Data Access Control?

MCP handles authentication between client and server through OAuth 2.1, requires servers to validate token audience, and forbids passing the client token upstream. Row-level and column-level access control is outside the protocol; the tools specification says only that servers must "implement proper access controls." Access control therefore has to live in the layer the MCP server queries, keyed to the human user the agent acts for.

How Do You Use MCP Safely in an Enterprise?

Assume every tool result may contain instructions, because indirect prompt injection through returned data is the mechanism behind the GitHub and Supabase incidents. Give agents only the entitlements a human in the same role already holds, evaluate policy at query time in the engine that touches the data, cap tokens and rows per request, and log every call with the delegated user. Pin client and server versions and track advisories such as CVE-2025-6514.

References

  1. Introducing the Model Context Protocol. Anthropic, November 25, 2024. https://www.anthropic.com/news/model-context-protocol

  2. New tools and features in the Responses API. OpenAI, May 21, 2025. https://openai.com/index/new-tools-and-features-in-the-responses-api/

  3. MCP joins the Agentic AI Foundation. Model Context Protocol Blog, December 9, 2025. https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/

  4. GitHub MCP Exploited: Accessing private repositories via MCP. Invariant Labs, May 26, 2025. https://invariantlabs.ai/blog/mcp-github-vulnerability

  5. Supabase MCP can leak your entire SQL database. General Analysis, July 2025. https://generalanalysis.com/blog/supabase-mcp-blog

  6. Model Context Protocol Specification (2026-07-28), Security and Trust & Safety. modelcontextprotocol.io. https://modelcontextprotocol.io/specification/latest

  7. Model Context Protocol Specification, Server Features: Tools, Security Considerations. modelcontextprotocol.io. https://modelcontextprotocol.io/specification/2026-07-28/server/tools

  8. Model Context Protocol Specification, Authorization. modelcontextprotocol.io. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization

  9. The lethal trifecta for AI agents: private data, untrusted content, and external communication. Simon Willison, June 16, 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

  10. LLM01:2025 Prompt Injection. OWASP Top 10 for LLM Applications. https://genai.owasp.org/llmrisk/llm01-prompt-injection/

  11. LLM06:2025 Excessive Agency. OWASP Top 10 for LLM Applications. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/

  12. MCP Security Notification: Tool Poisoning Attacks. Invariant Labs, April 1, 2025. https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks

  13. CVE-2025-6514: Critical mcp-remote RCE Vulnerability. JFrog Security Research, July 9, 2025. https://jfrog.com/blog/2025-6514-critical-mcp-remote-rce-vulnerability/

  14. Row-level filtering and column-masking using Apache Ranger policies. Apache Ranger Wiki. https://cwiki.apache.org/confluence/display/RANGER/Row-level+filtering+and+column-masking+using+Apache+Ranger+policies+in+Apache+Hive

  15. Server Administration Guide: Identity Brokering and User Federation. Keycloak. https://www.keycloak.org/docs/latest/server_admin/index.html

  16. Model Context Protocol Specification, Security Best Practices. modelcontextprotocol.io. https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices

  17. Public GitHub Issue Could Trick GitHub Agentic Workflows Into Leaking Private Repo Data. The Hacker News, July 7, 2026. https://thehackernews.com/2026/07/public-github-issue-could-trick-github.html

ABOUT

1115 Howell Mill Rd
Suite 430,
Atlanta, GA 30318
An Insight Partners Company


Product Updates and News

@2026 NexusOne® - All rights reserved.

ABOUT

1115 Howell Mill Rd
Suite 430,
Atlanta, GA 30318
An Insight Partners Company


Product Updates and News

@2026 NexusOne® - All rights reserved.

ABOUT

1115 Howell Mill Rd
Suite 430,
Atlanta, GA 30318
An Insight Partners Company


Product Updates and News

@2026 NexusOne® - All rights reserved.