A technical guide to public and private MCP endpoints, identity boundaries, database permissions, and safe AI access.
Problem statement
Consider an enterprise employee chatbot asked a simple question -
What's the reported average sales per day in Store 1234 for last 3 months and what are the top 3 and bottom 3 products sold by total sales for last 3 months?
Behind that interaction, an AI agent invokes a Model Context Protocol (MCP) tool, the MCP server queries Azure Database for PostgreSQL flexible server (henceforth, flexible server), and a sales dataset is returned.
The database has private connectivity (VNET injected or accessed via private link), public database access is disabled and connections are encrypted.
Whether the system is secure remains an open question?
An internet facing MCP server creates an application mediated path to private data that path can be entirely legitimate, but its security depends on authentication, authorisation, tool design, database permissions, data handling and operational controls rather than on the database’s network posture.
Now consider a harder scenario - An authenticated employee asks the agent for another employee’s sales profile, a retrieved document contains embedded instructions to extract the whole corporate directory, the agent chains several tool calls, and the MCP application connects to flexible server with a privileged application identity. The database accepts the connection and returns the data. No firewall has been bypassed, the application has simply used its legitimate permissions politely and inappropriately.
Top tip - The governing principle is that private database connectivity protects the database’s network boundary and does not establish the identity, authority or intent of the application accessing it.
Understand the impact area before judging its security
MCP lets AI applications discover and invoke tools exposed by a server. In a flexible server backed enterprise application, such tools might retrieve an employee sales profile, look up a corporate policy, check the status of a support request, create a service request or run a bounded analytical query.
The MCP server sits as an application component between client and database and it receives a tool invocation, validates it, applies application-level authorisation and translates it into a database operation. The request path therefore runs from the employee to the AI application acting as MCP client, over authenticated HTTPS to the MCP server, and from there to flexible server and the underlying business data.
That path contains several distinct trust boundaries as shown below -
Architecturally it is useful to separate three planes with different responsibilities -
- A control plane covering MCP server registration, tool discovery, policy management, identity governance and lifecycle
- A runtime plane covering authentication, tool invocation, application execution, database access and response delivery
- A data plane containing flexible server records, privileges, row level security policies, encryption and data governance.
MCP is not a replacement for flexible server wire protocol or its permission system. A tool invocation must still be translated into an application operation, authenticated database connection, and SQL statement.
Top tip - These planes should not be treated as a single security boundary and securing only the bottom plane leaves the others exposed.
Architecture pattern 1: Public MCP and Private Flexible Server Can Coexist
What you see here is an authenticated MCP endpoint hosted on Azure App Service (or your preferred container service) that can use outbound VNet integration to reach a privately accessible Flexible Server, so the database is private while the MCP endpoint is publicly reachable.
There's nothing glaringly wrong here because the two Az services have independently configured network boundaries.
Here Az App Service networking features should be categorzied across -
a) VNet integration provides outbound connectivity from the application into a virtual network private endpoints provide inbound private connectivity to the application; and access restrictions and public network access settings independently govern the default endpoint. VNet integration does not make inbound access private.
b) A private MCP deployment requires private ingress and, where appropriate, disabled public application access.
Top tip - Connecting an MCP application to a Az VNet does not make its MCP endpoint private. This pattern is useful when approved clients cannot join your private network.
Architecture pattern 2: Private MCP endpoint and Private Flexible Server
In this pattern, the MCP server is exposed only through private ingress, and communication from MCP to flexible server also remains on the private network path. Neither the MCP endpoint nor the database needs to be directly reachable from the public internet, materially reducing the external network attack surface.
However, private connectivity should be treated as an exposure control, not a security or authorization boundary. Once an application has legitimate network access to MCP, security depends on the identity presented, the MCP tools that identity is authorised to invoke, and the permissions available to those tools at the database layer.
A compromised AI application or a workload identity, malicious prompt or authorised insider could therefore still generate valid looking MCP requests.
Authentication, fine grained tool authorization, least privilege managed identities, database permissions, input validation and auditability remain essential controls.
Top tip - Private networking reduces who can reach the MCP server and identity and authorization determine what a caller can do once they reach it.
Architecture pattern 3: Public AI Gateway, Private MCP backend and Private database
In this pattern, Azure API Management (APIM) or AI Gateway becomes the controlled public entry point.
Client requests terminate at the gateway, where controls such as authentication, authorization, rate limiting, request validation, throttling and logging can be applied before traffic is forwarded to the MCP application over private connectivity.
The MCP application itself remains private and is not directly exposed to the internet.
Communication from MCP to flexible server also follows a private network path, creating a clear separation between the externally reachable API surface, the tool execution layer and the underlying data tier.
This architecture is particularly useful when multiple approved AI clients or agents need access to MCP capabilities but you want a single, governed ingress point rather than exposing each MCP implementation independently.
The critical design requirement is to prevent gateway bypass. Approved AI clients or apps should not be able to discover or reach an alternative public endpoint on the MCP backend. Otherwise, APIM policies can simply be circumvented.
Top tip - Expose the AI gateway, not the MCP implementation or database. Use APIM to control who can enter and under what conditions, then enforce least privilege again at the MCP tool and data layers.
Secure the caller to row-level boundary in Flexible Server
The most important part explained in above architecture patterns (1/2 and 3) is what happens after an MCP tool has been authorised. MCP should determine which capability the caller may invoke, but flexible server should independently determine what that capability is ultimately allowed to do with data.
The MCP application connects to flexible server using a dedicated runtime identity (workload identity) with deliberately narrow SQL grants (reader permission). That identity should not inherit broad application owner privileges simply because the MCP service is trusted to connect.
Where possible, the runtime role should have access only to the specific schemas, tables, views or functions required by the approved tool including and where appropriate using NOBYPASSRLS.
Equally important, the caller identity and workload execution identity are different security concerns.
The workload identity authenticates the MCP application to flexible server. The verified caller context, such as tenant and object identifiers derived from validated Entra claims, can be propagated separately into the database transaction and used by database policy to constrain the current operation.
This is where RLS (and CLS) becomes especially powerful!
Rather than trusting MCP to remember to add the correct WHERE employee_id = ... predicate to every query, RLS in database can enforce the row boundary itself. Even if the application contains a defect or a tool is invoked unexpectedly, the database still evaluates which rows the transaction is permitted to access.
Complimentary reading for Azure API management JWT validation
Private networking does not prevent data exfiltration
It is a misconception that data cannot leave or exfiltrate because the server has no public endpoint.
The authorised application can retrieve data and return it through an overly broad tool response to the external AI client, with no firewall bypass at all.
Preventing this requires per calling identity authorisation, sensitivity aware tool design, minimal response fields (consider flexible server features such as - RLS, CLS, views and locked down schemas), and monitoring for unusual access patterns.
Note that a private database server provides no end-to-end data residency or sovereignty guarantee.
Top tip- The AI platform, model endpoint, logging services and downstream integrations must each be assessed against organisational data governance requirements.
Final takeaway
Private connectivity reduces the externally reachable attack surface. It does not establish trust. Conversely, a carefully governed public endpoint can still provide a strong security boundary when identity, policy enforcement and backend isolation are designed correctly.
Moreover, network placement is only one dimension of the security model. The stronger architectural question is whether the entire invocation path remains controlled, from the AI client > APIM > MCP tool execution > Flexible Server and back!
The goal is not simply to make the database unreachable. It is to make every path to the database intentional, attributable, and observable.
Microsoft