MCP Servers as the Access Control Boundary for Agent Data

Most teams that have wired an AI agent into an MCP server believe they have solved access control, but they have not [1][2][3]. What they have built is an authenticated channel: a connection where the agent can prove who it claims to be to the server on the other end. That is a different thing from a governed channel, where someone has decided what the agent is allowed to see, do, and return once the connection is live. Treating the first as the second causes most of the risk in agentic data deployments, because the connection working at all feels like proof that it's been secured.

Palo Alto Networks' Secure AI Agents analysis names the deeper issue directly: AI agents form a new class of privileged identity, carrying traits of both human users and machine processes, and most MCP deployments never give that identity a place inside the organization's IAM system. Security teams, as a result, often cannot say with confidence which databases, cloud environments, and SaaS applications their agents are reaching into, and agents move through those systems at machine speed, far faster than any human reviewer could track in real time. That gap between what MCP provides and what teams assume it provides is the subject of this piece, and closing it requires rethinking where enforcement actually belongs.

What MCP's own architecture does and does not enforce at the access layer

The Model Context Protocol defines how an agent talks to a server: the message format, the discovery of available tools, the negotiation of a session. It does not define what an agent is allowed to do once that session exists. That responsibility falls entirely on whoever implements the server, and the protocol's own specification does not fill the gap for them.

The March 2025 revision of the spec (version 2025-03-26) brought OAuth 2.1 in as the standard for authenticating remote MCP servers, and then the November 2025 revision (version 2025-11-25) extended it further with OpenID Connect Discovery and incremental scope consent. Both are real improvements to how an agent proves its identity to a server. Neither one decides what that agent can do after the handshake completes, since authentication answers "who is this," not "what is this allowed to touch." Native platform tools can often tell a team that an MCP server exists or that an agent is active, but Palo Alto Networks' analysis notes they frequently stop short of the visibility, identity context, and access governance that enterprise deployments need.

The attack surface that opens when MCP servers are treated as the trust boundary rather than the enforcement point

Nothing about the risk here is exotic. The failures that matter most in agentic data access are ordinary mistakes, the kind application security teams have handled for two decades, but now they sit behind a caller that acts autonomously and moves fast.

A misconfigured MCP server doesn't need to be malicious to do damage. The fix is audience-validated tokens, scoped so tightly that a credential issued for one server simply cannot be used against another. A third pattern runs through prompt injection: a server the agent trusts fetches a web page, a document, or a database record, and that content carries text written to look like an instruction. Because tool results land inside the agent's context window as part of its working prompt, that injected text can steer what the agent does next, without the agent ever registering that it has been redirected.

Supply chain compromise adds a fourth pattern, and it played out at scale in the Deadbugz campaign of August 2026. None of these five patterns depend on some novel weakness in how language models reason. They are path traversal, command injection, server-side request forgery, and access-control failures that web application security has dealt with for years, made more dangerous by a caller that acts autonomously and operates at a speed no human reviewer matches. Between January and February 2026 alone, security researchers filed more than 30 CVEs against MCP servers, spanning both client implementations and server-side logic, and the pace shows no sign of slowing.

What "enforcing the boundary" actually requires: identity, scope, and auditability at the gateway layer

A boundary that actually holds needs three properties, and you cannot skip any of them. Every agent needs a named, scoped identity of its own. Every tool call needs authorization checked at the moment it executes, against a least-privilege policy, not just when the tool list is first handed to the agent. And every action needs to trace back to a specific agent-user pair inside one audit trail that spans every server the agent touches.

Start with identity. An agent should not operate as an anonymous service account that happens to hold a valid token. It needs an identity that IAM can see, scope, suspend, and audit on its own terms, independent of any human user it happens to be acting for. Palo Alto Networks' architecture for this problem places an agent identity broker between the agent and the remote MCP server, so the agent itself never holds standing credentials and every request gets brokered and checked in the moment. Governance can go further than table-level access, too: row-level security limits what records come back to only what the agent is cleared to see, and column-level masking strips sensitive fields even out of queries the agent is otherwise permitted to run, so a fraud detection agent can read transaction amounts while payment card numbers stay hidden because the data layer itself filters what it gets back.

Audit is the third leg, and it has to live somewhere outside any single server, because MCP's specification has no shared field for tracking a given agent-user pair across different servers. The only place that record can live coherently is a gateway: a layer sitting between the agent and every MCP server it talks to, so every tool call from every connected server passes through one choke point. Built as a reverse proxy or middleware layer, a gateway centralizes authentication enforcement, rate limiting, circuit breaking, audit logging, and policy enforcement in one place, so none of it has to be rebuilt separately inside each MCP server a team stands up.

How production MCP gateways implement these controls today

A handful of production gateways already implement pieces of this architecture, and they differ in which of the three properties they lean on hardest, so evaluating them means checking each against identity, scope, and audit.

IBM's ContextForge, open source, aggregates several MCP servers and merges their capabilities into virtual servers, so a curated set of tools looks to the agent like one logical endpoint, a design that suits teams that want full control over how and where they deploy. Kong's AI Gateway added an MCP Registry in early 2026 for cataloging and governing approved MCP servers; the Gateway itself carries native OAuth 2.1 support and access control lists that constrain exactly which tools an agent can call, down to the individual tool. Amazon's Bedrock AgentCore Gateway is a managed AWS service that turns REST APIs, OpenAPI specs, Smithy models, and Lambda functions into MCP tools, and can also proxy existing MCP servers, all behind a single endpoint, with identity and audit wired directly into IAM, Cognito, and CloudTrail, a natural fit for any team already living inside the AWS identity model. Palo Alto Networks' Idira Secure AI Agents takes a different structural approach: it acts as the authorization server for the MCP itself, routing agent communication through a centralized identity broker that proxies requests out to the target MCP servers, so the agent never holds standing credentials of its own.

Comparing these options in practice means asking a short list of concrete questions: whether authorization gets enforced at the level of the individual tool or only at the level of the whole server; whether each end user authenticates under an identity of their own or every agent shares one admin token; whether a tool call executes automatically or waits on an explicit approval step; whether the gateway runs inside the team's own infrastructure, which matters because the gateway ends up holding every credential the agent uses; and whether its audit records export cleanly to a SIEM for incident response that spans more than one system.

Why gateway controls alone are insufficient when agents access raw databases

A gateway can govern who calls which tool and still do nothing to stop an agent that reaches a raw production database and composes its own query across a schema no one has mapped for it. The boundary holds at the network layer in that scenario and gives way entirely at the data layer.

A read-only parameter, activated by adding ?read_only=true to the endpoint URL, routes the connection through a read-only Postgres role, so the agent can query but never write. That's a real control, and it's also a narrow one: it says nothing about what data comes back or how the agent strings tables together to get there. An agent asked "What was MRR last month?" has no business joining tables it found by poking around in pg_catalog, because that path produces a different answer every time depending on which tables it happens to find, since the raw schema carries no encoded definition of what "MRR" actually means. What that question needs is a governed metric definition the team has already agreed on and built into the data layer. The practitioner consensus that follows from this is specific: raw warehouse or database access through MCP is fine as a fallback for ad-hoc, one-off exploration, while any defined metric or governed dataset needs to be the default, reached through a semantic or analytical layer.

Pre-modeled, governed datasets as the data-side enforcement layer

The data sitting behind an MCP server carries as much weight in this architecture as the gateway sitting in front of it. Pre-modeled, governed datasets that agents query instead of raw tables are what make the boundary mean something at the semantic level, not only at the network level.

Routing a question to a defined metric first is what keeps the answer consistent: when an agent's question maps onto a metric someone has already defined, it calls that definition and returns the same number every other surface in the company would produce from it. A distinct pattern has formed around this idea under the name headless analytics, which separates the analytics engine from any front-end UI and exposes governed, pre-calculated datasets directly as agent-callable MCP endpoints. Informatica's move at Informatica World 2026, exposing its full range of data management capabilities as governed microservices callable through MCP, and Salesforce's Headless Data 360 for MCP, which exposes governed customer context to agents through a large suite of APIs, both point to the same conclusion: grounding an agent in trustworthy data has become its own purchasable layer in the agent stack, not an afterthought bolted onto the model.

Teams running Supabase or Postgres already have the analytical home they need. The right move is not to extract that data into a separate warehouse and rebuild governance there from scratch, but to pre-model governed datasets directly from the existing Postgres schema and expose them through a governed MCP surface, with no ETL pipeline and no changes to the underlying schema required. The two layers of this architecture do different jobs and need each other to function: the gateway enforces identity, scope, and auditability over who is allowed to call what, and the governed dataset layer enforces what data that call is permitted to return and what a term like "MRR" means when it does.

Building the complete enforcement architecture: a practical decision framework

Getting this right requires two decisions made in a specific order. Govern the data sitting behind the MCP surface first, since ungoverned data undermines any gateway controls placed in front of it later. Enforce identity, scope, and audit at the gateway in front of it second. Reversing that order produces something that looks like security without actually being any.

On the data side, that means identifying which metrics and datasets agents will actually query and modeling them as governed definitions before any MCP surface goes live at all, and it means directing analytical queries at read replicas or pre-calculated datasets rather than ever pointing an agent at the production database directly. Row-level and column-level permissions belong in the dataset model itself, not scattered through application code where no one will think to check them later. Teams running Supabase or Postgres can use Supabase's branching model to let an agent create a branch database, test a schema migration, and merge it back, keeping every experiment off production entirely, while keeping the analytical surface separate from the operational one it serves.

On the gateway side, every agent needs a named, scoped, independently revocable identity rather than a shared service account that half the team can authenticate as. Authorization needs to run at the level of the individual tool, and it needs to be checked again at the moment of execution. Audience-validated token scoping means a credential issued to one MCP server cannot be used against another, so it closes off the confused deputy attack class at the structural level instead of relying on anyone noticing the misuse after the fact. And the default posture throughout should be to deny: a tool that hasn't been explicitly permitted should not be reachable, not merely discouraged by a policy no one is enforcing.

The signal that an architecture has gotten this backward is easy to spot once you know what to look for: agents holding production database credentials directly, metric definitions scattered across dashboard configuration instead of living in a governed layer, and audit logs that can answer what a server did but never what a particular agent did for a particular user across every system it touched. The MCP server is the natural place to enforce all of this, but only when a governed dataset sits behind it and a real gateway sits in front, because it takes both layers together to define a boundary that actually holds.