TL;DR: ChatGPT Developer Mode can reach a local SQLite MCP server through an identity-aware reverse tunnel that handles auth, TLS and per-request policy enforcement, according to Pomerium. The core issue is not convenience but whether enterprises can expose local tools to cloud LLMs without breaking Zero Trust assumptions.
At a glance
What this is: This is a product blog demonstrating how an MCP gateway can connect ChatGPT Dev Mode to a local SQLite server while enforcing identity-aware access, TLS and per-request policy.
Why it matters: It matters because IAM and platform teams need to decide how to expose local tools to cloud-hosted AI workflows without turning network reachability into implicit trust.
Context
MCP gateways sit between an AI client and the tools or data sources it needs, enforcing authentication, transport protection and policy at the connection boundary. In this article, the core governance problem is not whether ChatGPT can talk to a local SQLite server, but whether that access can be controlled without weakening Zero Trust assumptions.
The demonstrated pattern uses a reverse tunnel and identity-aware proxying so a cloud-hosted LLM can reach a local MCP server as if it were service-side infrastructure. That changes the trust model for developer tooling: access is no longer defined by VPN membership or flat network reachability, but by request-level controls and upstream credential handling.
Key questions
Q: How should security teams govern managed MCP access for AI clients?
A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.
Q: Why do VPNs fall short for ChatGPT Dev Mode and MCP tools?
A: VPNs only control network reachability, while MCP tool use needs request-level authorisation and credential scoping. A hosted LLM can be outside the enterprise network and still need to call internal tools, so the real control point is the gateway that inspects and permits each action before it reaches the server.
Q: What breaks when MCP servers are exposed without identity controls?
A: Without identity controls, anyone with a link, key, or copied credential can reach tools and data outside policy. That breaks visibility, weakens compliance evidence, and makes it difficult to separate approved use from shadow AI activity across SaaS and internal systems.
Q: What is the difference between an MCP gateway and a traditional reverse proxy?
A: A traditional reverse proxy forwards traffic, but an MCP gateway adds identity binding, upstream credential handling and policy decisions specific to tool calls. For AI workflows, that matters because the request is not just transport traffic. It is an executable action that needs explicit authorisation before the tool responds.
Technical breakdown
How an MCP gateway replaces network trust with request trust
An MCP gateway terminates the connection between the AI client and the local tool, then enforces identity, transport and policy decisions before forwarding traffic. In this demo, Pomerium handled authentication, TLS certificates and per-request policy enforcement, which means the local server was not exposed as a broadly reachable network asset. The practical significance is that the security boundary moves from the subnet to the request, which is closer to Zero Trust than a traditional VPN path.
Practical implication: Treat the gateway as the enforcement point and require per-request controls before any MCP tool can be reached.
Why ChatGPT Dev Mode changes the MCP threat model
ChatGPT Dev Mode can invoke MCP tools directly, which means the AI client becomes an active runtime participant rather than a passive viewer of data. Once that happens, the security question shifts from developer convenience to how upstream credentials, tool scope and output handling are governed when an external cloud service initiates requests. The article shows SQL generation and follow-on analysis happening automatically, which is useful, but it also expands the attack and misuse surface if access is not tightly scoped.
Practical implication: Constrain tool scope and upstream credentials as if the AI client were an untrusted but authorised request origin.
Why local development plus cloud LLMs needs policy at layer 7
Layer 7 policy is the meaningful control plane here because the risk is in what the AI is allowed to ask the tool, not in whether a network tunnel exists. The article explicitly says VPNs do not work in this model, because hosted LLMs are not sitting inside the enterprise perimeter. That makes request inspection, identity binding and policy enforcement the mechanisms that determine whether the integration remains governable.
Practical implication: Place authorisation at the application layer, where individual MCP requests can be evaluated and constrained.
Breaches seen in the wild
- Chevrolet chatbot $1 Tahoe 2023: Users made a Chevrolet dealer's ChatGPT chatbot agree to sell a 2024 Tahoe for $1 and write code; no sale was honoured and the bot was taken offline.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity-aware MCP access is becoming a governance layer, not just plumbing. Once a cloud LLM can invoke local tools, the organisation is no longer connecting endpoints, it is delegating action paths. That makes the gateway part of the identity model because it decides which requests are allowed, which credentials are passed upstream and which tools remain visible. Practitioners should treat MCP ingress as a governed access surface, not a convenience feature.
Zero Trust assumptions survive only if policy stays per request. A VPN-style trust boundary assumes the network path is the security control, but this article shows why that model fails for hosted LLMs. The governing question is whether each tool call is authenticated, authorised and inspected at the time of use. If not, the enterprise has merely shifted implicit trust from the network to the gateway.
Secure developer workflows now depend on exposing local data without exposing local authority. The SQLite example is benign, but the architectural pattern extends to dev databases, metrics sources and other internal systems that may feed AI-assisted analysis. The named concept here is runtime MCP trust boundary: the point where tool access, upstream credentials and output generation must be controlled together. Security teams should assess whether that boundary is enforceable before wider rollout.
AI-assisted analytics will force IAM and platform teams to coordinate on delegated tool use. The article hints at broader use cases where non-technical users consume MCP-based reports through ChatGPT. That widens the audience for tool access while keeping the same control requirement: identity-aware, request-scoped authorisation. The implication is that governance must cover both who can connect and what the AI can do once connected.
The category is moving toward controlled exposure of internal systems to agentic workflows. MCP gateways are not merely a developer convenience layer, they are an access model for AI-driven work. That means IAM teams need to decide which systems can be exposed, under what conditions, and whether the resulting control set actually preserves separation between user intent, tool execution and data access. The next programme question is less about connectivity and more about accountability.
What this signals
Runtime MCP trust boundary: AI tool access is shifting from perimeter connectivity to request-scoped governance, which means identity teams need to treat the gateway as part of the control plane. That changes how exposure is assessed, because the relevant question is no longer whether a system is reachable, but whether each AI-originated request can be authorised before execution.
As cloud LLMs become capable of invoking internal tools, separation of duties has to extend to AI-assisted workflows. The practical risk is not just broader access, but delegated access that is hard to distinguish from ordinary user behaviour unless the policy layer is explicit and enforceable.
For practitioners
- Define the MCP trust boundary Map every tool, datasource and credential that a cloud-hosted AI client can reach through MCP, then decide where request-level policy must terminate the connection.
- Bind upstream credentials to policy Ensure any upstream tokens, certificates or service credentials used by the gateway are scoped to the minimum tool set the AI workflow requires.
- Replace VPN assumptions with per-request authorisation Verify that no AI-to-tool path depends on network membership as the primary control, because hosted LLMs will not reliably sit inside a corporate VPN.
- Separate developer convenience from production exposure Allow local MCP testing and shared routes only when the same identity-aware controls will be available in the target environment.
Key takeaways
- MCP gateways can make local tools available to cloud-hosted AI workflows without falling back to VPN-based trust, but only if the gateway enforces identity-aware controls at request time.
- The central governance issue is the trust boundary, because once an LLM can call internal tools, access scope and upstream credentials become part of the identity problem.
- IAM and platform teams should decide which internal systems can be exposed to AI clients, then validate that per-request policy, not network location, is doing the security work.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on delegated AI tool use and request-scoped authority. |
| Recommendation — Limit agent tool scopes and enforce identity checks before any MCP action executes. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The gateway authenticates tool access for a cloud LLM reaching local systems. |
| NHI-05 — Overprivileged NHI | Upstream credentials and tool exposure must stay narrowly scoped for AI workflows. | |
| Recommendation — Bind MCP access to explicit authentication and reject unauthenticated tool requests. Reduce exposed MCP permissions to the minimum tool set required for the workflow. | ||
| NIST Zero Trust (SP 800-207) | Policy Enforcement Point — Policy Enforcement Point | The gateway acts as the enforcement point for request-level access decisions. |
| Recommendation — Move authorisation to the enforcement point so each MCP request is evaluated before forwarding. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing what a cloud AI client can access and do. |
| Recommendation — Review entitlements for AI-connected tools and validate that authorisations match intended use. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed AI tool paths can enable credential use and movement into internal systems. |
| Recommendation — Map MCP exposure paths to credential access and lateral movement detection coverage. | ||
Key terms
- MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
- Identity-aware Proxy: An identity-aware proxy combines routing with authentication and authorization logic. It checks tokens or certificates, applies policy at the edge, and forwards verified identity context to the backend so applications do not have to re-implement security decisions inconsistently.
- Per-Request Enforcement: Per-request enforcement evaluates the access decision at the moment the action is made, using current context rather than a standing grant. For AI gateways, this matters because routing, delegation, and workflow state can all change between calls.
- Mcp Trust Boundary: The security boundary created by a Model Context Protocol connection between an AI assistant and an external system. Each connection can supply data, trigger actions, or both, so it must be governed like a delegated access path rather than a simple integration.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org