MCP gateways reshape secure AI analyst workflows in ChatGPT Dev Mode

At a glance

What this is: This is an analysis of secure MCP access in ChatGPT Developer Mode, showing that an identity-aware proxy can bridge local tools to cloud LLMs with per-request policy enforcement.

Why it matters: It matters because MCP-based AI workflows create new access paths that IAM, PAM and NHI programmes must govern at the request layer, not just at the network perimeter.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Pomerium's analysis of secure MCP access with ChatGPT Developer Mode

Context

MCP changes the access problem for AI systems because it lets a model talk to external tools and data sources through a structured protocol instead of a browser session or a human-operated VPN. In this article, the important question is not whether ChatGPT can query SQLite, but how that request path is authenticated, authorised and constrained when the tool sits inside a local environment.

For identity teams, the control plane moves from network perimeter logic to request-level governance. That shift matters for NHI, because the upstream credentials, tool endpoints and policy decisions that support machine-driven workflows now need to be treated as governed identities, not just development plumbing.

Key questions

Q: How should security teams govern MCP access for cloud-hosted AI tools?

A: Security teams should govern MCP access as a request-level identity problem, not a network problem. Each tool call should be authenticated, authorised and logged with context about the model, the tool and the action. That approach lets teams apply least privilege to AI-driven workflows without depending on broad network trust or shared connectivity paths.

Q: Why do VPN-based controls fail for ChatGPT-style tool access?

A: VPNs fail because they authenticate network presence, not the specific tool request made by a cloud-hosted model. The model is outside the corporate perimeter, so a network tunnel alone cannot express whether a database query, file read or write action should be allowed. Identity-aware policy must make that decision instead.

Q: What should teams do with upstream secrets used by MCP servers?

A: Teams should treat upstream secrets as non-human identities with owners, expiry, rotation and revocation requirements. If those credentials let a model reach internal systems, they carry the same governance burden as service account keys or workload tokens. Leaving them in configuration without lifecycle control creates unnecessary exposure.

Q: How do you know whether an MCP gateway is actually enforcing Zero Trust?

A: You know it is working if access decisions are made per request and can distinguish among users, tools, actions and context. If the gateway only opens a path and then trusts everything over that path, it is acting like a tunnel, not a Zero Trust control. The test is whether policy can block one call without disabling the whole integration.

Technical breakdown

MCP gateways and request-layer control

Model Context Protocol gives an LLM a standard way to discover and call tools, but it does not itself solve trust, segmentation or authorisation. A gateway sits between the model and the tool, terminating the connection, handling TLS, authenticating the requester and enforcing policy on each call. In practice, that means the security boundary is no longer the laptop or the VPN headend. It is the combination of identity, transport protection and policy evaluation that decides whether a tool invocation is allowed, and under what conditions.

Practical implication: treat the gateway as the control point and define policy for every tool invocation, not just for network access.

Why VPNs fail for cloud-hosted LLM tool access

A VPN assumes the trusted actor is already inside the network and can reach internal resources once connected. Cloud-hosted LLMs do not fit that model because the model is not a user session on your corporate device, and the tool request originates outside the perimeter. That breaks the implicit trust model behind network-based access. If the model can reach a local database through a tunnel, the real question becomes whether each request is bound to identity, context and purpose, rather than to a blanket network path.

Practical implication: do not use network reachability as the security decision for AI tool access, because the model's identity must be evaluated per request.

Upstream credentials in MCP workflows

The article shows upstream tokens, certificates and OAuth flows being managed in configuration rather than embedded in custom MCP server code. That is a classic NHI pattern: credentials are used by a workload or service path, not by a human. The risk is not just exposure, but uncontrolled reuse across local development, shared demos and remote access paths. Once credentials support model-driven tool execution, they become part of the governance surface for secrets, rotation and offboarding.

Practical implication: inventory and govern the upstream secrets that enable MCP tool access as non-human identities, with rotation and lifecycle controls.

NHI Mgmt Group analysis

Request-layer governance is becoming the new control plane for AI tool access. The article shows why perimeter-first thinking fails when a cloud LLM needs to reach a local tool through MCP. The important trust decision happens at invocation time, not at network admission, which means IAM and NHI controls must move closer to the request itself. Practitioners should treat every MCP call as a governed access event, not a transport detail.

Upstream credentials used by AI toolchains are non-human identities, even when developers treat them as setup material. OAuth tokens, certificates and upstream secrets that connect a model to a database or service are identity artefacts with lifecycle, rotation and offboarding requirements. The governance error is to treat them as temporary integration glue. Practitioners should classify them inside NHI policy, because their exposure creates the same blast radius as any other workload credential.

Per-request policy enforcement is the only defensible Zero Trust pattern for hosted LLMs. A VPN can extend a network, but it cannot express whether a specific model action should be allowed on a specific resource at a specific moment. That is why the architecture in this article matters: it replaces ambient trust with decisioning at the edge of the tool. Practitioners should re-evaluate any design that still depends on network location as the primary safeguard.

MCP gateways create an identity boundary that many IAM programmes do not yet model. The article illustrates a growing class of access where a model, a gateway and an upstream service identity all participate in one request path. That creates policy, logging and accountability gaps if teams only inventory human logins or service accounts in isolation. Practitioners should expect MCP to force a broader identity map across human, workload and agent-adjacent access paths.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why AI toolchains that rely on upstream credentials need explicit ownership and review.
• For a broader control baseline, see NIST Cybersecurity Framework 2.0 and apply it to request-layer authorisation, logging and recovery for MCP-mediated access.

What this signals

Request-layer governance: MCP makes the access boundary observable at the tool call rather than the network edge, which is where AI programmes will increasingly be judged. Security teams should expect control mapping, logging and exception handling to move into the application and identity layers, especially when cloud LLMs consume local or internal data sources.

With 97% of NHIs carrying excessive privileges according to the Ultimate Guide to NHIs, the risk is that AI toolchains inherit overbroad upstream access by default unless teams redesign the credential path. That makes lifecycle control, least privilege and request auditing programme priorities rather than implementation details.

For practitioners

• Classify MCP upstream credentials as governed NHIs Inventory the OAuth tokens, certificates and API secrets that allow an LLM or MCP server to reach internal data sources. Assign ownership, expiry, rotation cadence and offboarding criteria so those credentials are managed like any other workload identity.
• Enforce per-request authorisation at the gateway Require the access decision to evaluate identity, resource, operation and context for each tool invocation. Separate read-only analytics from data extraction and write actions so the policy engine can block higher-risk requests without breaking the whole workflow.
• Remove VPN dependence from AI tool access design Map every local or internal tool exposed to a cloud model and replace blanket network trust with identity-aware routing. If the request path cannot be authorised independently of network location, treat the design as incomplete.
• Log model-to-tool requests as identity events Capture who or what initiated the request, which tool was called, which upstream credential was used and what data was returned. Feed those logs into IAM and security operations so agent-adjacent access can be reviewed alongside other privileged activity.

Key takeaways

• MCP turns AI tool access into an identity governance problem because every request now needs to be authenticated, authorised and logged.
• Upstream credentials that connect models to databases or services are NHIs and must be managed with rotation, ownership and offboarding controls.
• Zero Trust only holds in this pattern when policy is enforced per request, not when access is granted once through a VPN or static tunnel.

Key terms

• Model Context Protocol: A standard protocol that lets an AI model discover and call external tools and data sources in a structured way. In practice, it defines how the model reaches capabilities, but it does not decide who is allowed to use them. That decision still belongs to identity and access control.
• Identity-aware proxy: A control point that authenticates a requester and enforces policy before traffic reaches an upstream resource. For AI tool access, it matters because the proxy can validate context and request intent instead of allowing broad network reachability to stand in for authorisation.
• Upstream credential: A token, certificate or secret used by one service or workload to authenticate to another service. In AI toolchains, upstream credentials often sit behind the scenes, but they still require ownership, rotation and revocation because they can expose internal systems if reused or leaked.
• Request-layer authorisation: A decision process that evaluates each individual call before it reaches a tool or data source. It is stronger than blanket network access because it can distinguish between actions, resources and context at the moment the request is made.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pomerium: Secure SQL AI analyst, enabled by Pomerium and ChatGPT Developer Mode. Read the original.