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.
Why VPN reachability is the wrong control plane for ChatGPT Dev Mode and MCP tools
VPNs answer a network question: can a device reach a protected network segment. ChatGPT Dev Mode and MCP tools answer a different question: should this specific request, from this specific runtime, be allowed to invoke this specific tool with this credential scope. That makes the real control point the gateway and its per-request policy, not the tunnel.
A VPN can be useful as one layer in remote access, but it cannot distinguish a harmless prompt from a tool call that reads a repository, rotates a secret, or posts to an internal service. For that, you need request-level authorisation, scoped credentials, and a policy decision point that understands the action being attempted, not just the source IP.
That distinction matters even when the model is hosted outside the enterprise boundary. The hosted LLM may never sit on your network, yet it can still be delegated access to internal tools through MCP. The security question becomes whether the tool gateway verifies the requester, the target resource, the audience, and the permissions before forwarding anything downstream.
What MCP changes about access decisions
MCP introduces a protocol layer where tool invocation can be mediated, logged, and constrained independently of network access. That is why the MCP authorization specification is the right reference point: it treats the server as a resource server and expects audience-bound tokens rather than blind token passthrough.
In practical terms, the MCP gateway becomes the enforcement boundary for what the model can do, which tools it can see, and which credentials it can present. A VPN may still protect the transport path, but it does not provide the granularity needed to separate read-only discovery from write actions, or one workspace from another.
That is also why a zero trust pattern fits better than perimeter thinking. NIST SP 800-207 Zero Trust Architecture is relevant here because the model should not be trusted simply because it connected through a corporate tunnel. Each request needs explicit verification, least privilege, and continuous evaluation of context.
Why a gateway is more useful than a VPN for tool safety
The gateway can evaluate the request that actually matters: which tool is being called, what data or system it touches, whether the credential is correctly scoped, and whether the action is allowed for this session. That is a materially different control from granting broad network reachability and assuming trust will follow.
This is also where agentic risk appears. The danger is not only that the model reaches an internal system, but that a tool call is executed with broader authority than the task needs. OWASP Agentic AI Top 10 is useful because it frames tool misuse and identity and privilege abuse as primary failure modes, which is exactly the pattern a VPN cannot see.
For MCP specifically, the gateway should be able to reject unsafe requests even when transport access is already established. That means access decisions must be bound to the action, not just the connection, and must be capable of distinguishing delegated use from unrestricted reuse of a credential.
Risk and Threat Considerations
The main risk is that teams treat VPN access as if it were equivalent to application or tool authorisation. Once that assumption takes hold, a model or agent can move from permitted network presence to overly broad tool use, which expands blast radius and makes misuse harder to detect.
Failure mechanism: A valid tunnel grants network adjacency, then a weak mcp integration passes credentials or trusts the model session too broadly, allowing unauthorized tool calls, secret exposure, or destructive actions.
Impact: Attackers or misconfigured agents can reach internal tools, exfiltrate data, invoke write operations, or abuse delegated authority even when the original network connection looked legitimate.
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 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, 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 | MCP tool calls can be abused through excessive or mis-scoped agent authority. |
| Recommendation — Constrain agent permissions so each tool call is explicitly authorised and least-privilege. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Proxy) | MCP gateways and tool servers need service-to-service authentication and scoped trust. |
| Recommendation — Authenticate tool and gateway endpoints with scoped service credentials before permitting calls. | ||
| NIST Zero Trust (SP 800-207) | PA — Policy Decision and Enforcement | The question is about enforcing each request, not trusting network location. |
| Recommendation — Enforce per-request policy decisions at the gateway instead of relying on network reachability. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Tool invocation is a function-access problem, not just a connectivity problem. |
| Recommendation — Authorize each MCP action at the function level before forwarding it to backend services. | ||
| NIST CSF 2.0 | PR.AA-05 — Network integrity is protected | VPNs protect transport, but the topic shows why that is insufficient alone for tool access. |
| Recommendation — Treat network protections as a support control and add request-level authorization for tools. | ||
Practitioner Guidance
What to prioritise: Put the gateway in charge of tool admission, token scope, and action allowlisting. If the control cannot inspect the request and the target tool, it is the wrong control for MCP.
What to verify: Confirm that each tool call is authorised per request, that credentials are audience-bound, and that the gateway can differentiate read, write, and administrative actions. Also verify that network access and tool permission are not being conflated in the same policy.
Common mistake: Using VPN membership as the proxy for trust. That shortcut works for reachability, but it fails as soon as the hosted model needs to call internal tools from outside the corporate perimeter.
Practitioner takeaway: Treat the VPN as transport, not trust. For ChatGPT Dev Mode and MCP, the security boundary is the policy enforcement point that scopes each tool action before the request reaches the server.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org