The stakes are not hypothetical. IBM's 2025 Cost of a Data Breach report put breaches involving shadow AI at an average of 4.63 million dollars, above the 4.44 million global average, and found that 97 percent of AI-breached organizations lacked proper AI access controls. Suja Viswesan, IBM's VP of Security and Runtime Products, summarized it plainly: "The report revealed a lack of basic access controls for AI systems, leaving highly sensitive data exposed." The control gap is the story. MCP makes closing it more urgent, not less, because it gives one agent a standard way to reach everything.
| Governance requirement | Endpoint RBAC | MCP + OAuth (spec-native) | MCP + registry / allowlist | MCP + semantic execution layer |
|---|---|---|---|---|
| Authenticated user identity | Yes | Yes | Yes | Yes |
| Per-tool authorization | No | Partial | Yes | Yes |
| Row-level security enforcement | No | No | No | Yes, compile-time |
| Column-level security enforcement | No | No | No | Yes, compile-time |
| Metric-consistent access checks | No | No | No | Yes |
| Compile-time policy check | No | No | No | Yes |
| Audit trail with intent | Partial | Partial | Partial | Yes, full lineage |
| Confused-deputy protection | No | Partial | Partial | Yes, identity-in-compilation |
Read the table as a map of where each control can actually be enforced. MCP and its ecosystem cover the first several rows well. The bottom rows, the ones about which rows, columns, and cells a query may touch, are where MCP alone stops and where enterprise governance actually lives.
Why endpoint RBAC breaks once an agent acts for many people
In traditional systems, permissions attach to users and applications in predictable ways. A dashboard limits what a user sees, an API gateway validates a token, a warehouse applies row-level security. Agents break the pattern because a single agent identity often acts on behalf of thousands of people with different data rights.
This is the confused-deputy problem in its agentic form, described well in this analysis of row-level security for AI agents: "a user with no direct database access can extract any data the agent can reach, simply by asking the right question." One agent profile may serve the CEO and a warehouse worker. Endpoint-level RBAC cannot distinguish them once the request has been authorized to the agent, because the endpoint sees the agent's identity, not the human behind it. The same failure mode is why data catalogs cannot execute AI agents safely on their own: knowing a table exists is not the same as deciding, per requester, whether this row may be returned.
Allowed questions, restricted questions, and the gray zone between
The simplest way to think about agent governance is in terms of question boundaries. Some questions are clearly fine: revenue by region last quarter, current inventory levels by warehouse, support volume by category. Some are clearly not: individual employee salaries, customer PII for named accounts, unredacted security-incident detail. Those extremes are easy.
The boundary is rarely that clean in practice. Some users may see a detailed answer while others may see only an aggregate. Some data may be visible in one country and restricted in another. A question may be appropriate for a supervised human analyst but not for an autonomous agent acting unattended. The same query may be fine at row level for one role and permitted only in summarized form for another. Governance exists to make those distinctions explicit and enforceable, rather than leaving them to a model's judgment in the moment. When the distinction lives only in a prompt, it is not a boundary; it is a hope.
The stakes, in one paragraph
Beyond the IBM figures, the pattern shows up in named incidents. McKinsey's internal AI platform, Lilli, was compromised by a red team in under two hours, a useful example precisely because it is a firm with real budget and real security engineering that still failed. Bessemer's 2026 security research, which catalogs these cases in its report on securing AI agents, also reports shadow-AI adoption growing 485 percent year over year and 48 percent of employees uploading sensitive data to public AI tools. The risk is not that agents are malicious. It is that broad access plus weak per-request authorization is an easy accident to have at scale.
Authorization propagation is a workflow property, not a permission
The formal version of this problem is worth understanding, because it explains why bolting on more RBAC does not fix it. A May 2026 paper by Krti Tallam of Kamiwaza AI, "Authorization Propagation in Multi-Agent AI Systems", formalizes authorization propagation as a workflow-level property that RBAC, ABAC, and ReBAC do not solve on their own. It identifies three sub-problems that endpoint permissions miss entirely:
- Transitive delegation. Agent A delegates a task to Agent B. Whose permissions apply, and does B inherit more than the requesting human ever had? This is the same trust boundary that A2A's signed Agent Cards start to address at the coordination layer.
- Aggregation inference. Several individually authorized queries compose into an answer the user was never authorized to receive. Each step passes; the sum leaks.
- Temporal validity. Permissions valid when the request was made may no longer be valid when the query executes, especially in long-running or scheduled agent work.
None of these are caught by asking "is this agent allowed to call this tool." They are caught only by a control model that follows identity and intent through the whole workflow, down to the query itself.
The six layers of enterprise MCP governance
It helps to see governance as a stack, because different layers are enforced by different systems, and most teams only implement the top few.
- 1. Identity layer. Who is the human behind this request? Handled by OAuth 2.1, OpenID Connect, and, for agent-to-agent work, signed Agent Cards.
- 2. Delegation layer. Which agent is acting on whose behalf? Handled by on-behalf-of token exchange and the transitive-delegation model above.
- 3. Registry and allowlist layer. Which MCP servers is this agent allowed to talk to at all?
- 4. Tool authorization layer. Which specific tools may this agent invoke, under what conditions? Handled by per-tool policy, including Cedar-style rules.
- 5. Query and data authorization layer. Which rows, columns, and cells may the resulting query actually touch? This is where MCP alone stops, and where a semantic layer enforces compile-time RBAC, ABAC, row-level, and column-level security.
- 6. Audit layer. Every request, tool call, and result traceable back to a human, an agent, and a specific policy decision.
MCP and its ecosystem standardize layers one through four. Layers five and six are where enterprise governance is either real or absent, and they are exactly the layers a semantic execution layer is built to own, the case argued in full in why MCP is not enough without a governed semantic layer. The semantic layer behind the MCP server is what turns "the agent called an approved tool" into "the query this specific user triggered could only ever return rows they are entitled to."
What MCP and the major vendors already govern well
Governance in an MCP world is not starting from zero. The protocol itself has matured into identity-aware infrastructure: as of the specification line that began with the 2025-06-18 revision, MCP servers are OAuth Resource Servers, and the 2026-07-28 release candidate hardens OAuth 2.0 and OpenID Connect authorization further. That progression, covered in enterprise MCP adoption, is the protocol formally joining the enterprise identity stack.
The platform vendors have shipped real work at layers one through four, and it deserves credit:
- Salesforce made Hosted MCP Servers generally available in April 2026, where every transaction runs with the authenticated user's identity and CRUD, field-level security, and sharing rules apply automatically. Salesforce launched this partly to stop homegrown servers from spilling data across the trust boundary.
- AWS shipped AgentCore Identity on-behalf-of token exchange across 14 regions with Cedar-policy, tool-level authorization.
- Microsoft put MCP registry and allowlist controls into its developer tools and an on-device registry into Windows, providing identity and audit at the OS layer, and GitHub added registry and allowlist governance at the developer-tools layer.
- Cloudflare's workers-oauth-provider lets a remote MCP server act as its own OAuth 2.1 provider.
- Snowflake, Oracle, and Dremio push authorization into the data engine itself: Snowflake's Cortex MCP server applies RBAC per tool, Oracle's Deep Data Security embeds identity-aware row, column, and cell authorization in the database, and Dremio enforces RBAC on views, column masking, and row-access policies on every query. As KuppingerCole frames it, data access control is becoming the new security perimeter.
These are strong. The honest gap is that most of them govern well inside one platform. A multi-warehouse, multi-tool enterprise still needs one consistent answer at layer five that composes across all of them.
Fix the Context, Not the Model. A prompt that says "do not reveal sensitive data" is not a control; it is a suggestion. Governance that holds is enforced in the compilation of the query, where identity, policy, and business meaning meet, not in the instructions given to a model that can be argued out of them.
Why semantics and governance are the same problem
Governance is not only about denying access. It is also about answering correctly within safe bounds, and that requires knowing what the question means. Consider "show me top customers." Top by revenue, usage, profit, or lifetime value? Is this user entitled to named customers or only anonymized segments? Should the answer be scoped to one business unit? Without a governed definition, the system cannot even evaluate the policy, because it does not know which data the question actually touches. This is the same reliability gap behind metric drift in AI business intelligence: an answer that is wrong and an answer that leaks are both failures of resolving meaning before execution.
A semantic layer defines business meaning once; governance defines what meaning and what level of detail each identity may access. Bound together, they let the agent connect safely and answer safely. That binding is the job of a semantic control plane, and it is why fine-grained access control has to be evaluated where the query is compiled, not stapled on afterward.
Where governance should actually run
Agents need governance at more than one point in the request. Before the tool call, the system validates identity, classifies intent, checks policy, and restricts which tools and resources are even visible. During execution, it applies row-level security, column masking, join restrictions, and query rewriting through multi-tenant semantic isolation. After execution, it shapes the answer so the final response stays within business and regulatory rules. Across the lifecycle, it logs every request and decision so anomalies are visible and controls can be refined. The distinction that separates enterprise-grade governance from demo-grade access control is context: the same user may be allowed to ask a question in one situation and blocked in another, allowed an aggregate but not row-level detail, permitted a tool for supervised use but not autonomous use.
Governance shapes the answer, not only the access
One subtlety separates enterprise-grade governance from a coarse permission check: the same tool call can be authorized and still produce an answer that should not be returned as written. An agent may legitimately query a table and then summarize it in a way that reconstructs restricted detail, or aggregate several permitted results into an inference the requester was never cleared to draw. Governance therefore has to reach the final response, deciding whether it may be returned in full, in aggregate, masked, or not at all.
Concrete patterns make this tangible. A finance agent can answer quarterly revenue questions while executive compensation and unreleased planning assumptions stay restricted to authorized users. A healthcare agent can summarize treatment trends without surfacing patient-identifiable information outside an approved clinical context. An operations agent can report inventory and lead-time metrics while supplier contract terms remain closed. In each case the agent stays useful; governance does not kill the value, it makes the value safe to expose. The point is not to lock agents out of data. It is to make sure that what comes back is something the requester was actually entitled to receive.
Where Colrows fits: layer five, at compile time
Colrows sits at the query and data authorization layer, the one MCP does not reach. It composes with MCP's identity primitives rather than replacing them: OAuth and on-behalf-of identity flow in, and Colrows makes them enforceable at the point where intent becomes SQL. It enforces RBAC, ABAC, row-level, and column-level policy at compile time, so unauthorized queries fail compilation, not in production. Every compiled statement is traceable back to the original semantic intent and the requesting identity, which gives the audit layer real lineage rather than a log of tool calls. Because the same governed graph compiles across 16-plus SQL engines, a multi-warehouse enterprise gets one policy model instead of one per platform, the pattern behind regulated deployments like the Cipla case study and the governance-as-code approach. None of this replaces the good work vendors have shipped at layers one through four. MCP is the transport. The semantic layer is the logic. You need both, and the security-and-privacy stakes are exactly why, as covered in company brain security and privacy. See the Colrows MCP integration guide for the OAuth flow and tool catalog. These are controls that can assist in meeting your requirements; the accountable owner of the policy is still your organization.
Frequently asked questions
Does MCP handle authentication?
Yes. As of the 2025-06-18 specification, MCP servers are classified as OAuth Resource Servers, which is the point at which MCP formally joined the enterprise identity stack. That handles who the caller is; it does not decide which rows and columns the resulting query may touch.
How do I enforce row-level security for AI agents?
Row-level and column-level security must be enforced by the query layer or a semantic execution layer that compiles the agent's request, not by the MCP endpoint. The endpoint authorizes the connection; it does not see the final SQL, so it cannot filter rows the query should never return.
What is the confused-deputy problem for AI agents?
A single agent identity often serves many users with different data rights. Once a request is authorized to the agent, endpoint RBAC cannot tell a CEO from a warehouse worker. A lesser-privileged user can then extract data the agent can reach simply by asking the right question.
Can I audit what an AI agent queried?
Only if audit is enforced end to end: the human identity, the agent acting on their behalf, the tool call, the resolved query, and the returned data. Logging the tool call alone does not tell you which rows a user actually saw or why the policy allowed it.
What is authorization propagation?
It is the workflow-level property that permissions valid when a request is made are correctly carried through multi-agent delegation, through the aggregation of many authorized queries, and through the passage of time. Research formalizes it as a problem that RBAC, ABAC, and ReBAC do not solve on their own.
How much do shadow-AI breaches cost?
IBM's 2025 Cost of a Data Breach report put breaches involving shadow AI at an average of 4.63 million dollars, above the 4.44 million global average, and found that 97 percent of AI-breached organizations lacked proper AI access controls.
Does Salesforce Hosted MCP solve governance?
For Salesforce data, largely yes: every transaction runs with the authenticated user's identity, and CRUD, field-level security, and sharing rules apply automatically. For governance across multiple systems and warehouses, a single vendor's server cannot be the whole answer.
What is compile-time governance?
Compile-time governance embeds the policy checks in the step that compiles the agent's intent into SQL, so an unauthorized query fails compilation and is never sent to the database. Enforcement happens before execution rather than being discovered in production.
