ChatGPT MCP access expands the attack surface for AI governance

At a glance

What this is: ChatGPT can now connect to remote MCP servers and trigger tools during normal use, creating a wider governance and data-exposure surface.

Why it matters: Identity and security teams need to treat MCP-connected sessions as governed access paths, because tool use, data flow, and approval boundaries can now be expanded by ordinary users.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Noma Security's analysis of ChatGPT MCP governance and AI tool risk

Context

Model Context Protocol, or MCP, is the connective layer that lets an AI system call external tools and data sources. In this case, ChatGPT’s access to remote MCP servers turns what looked like a chat experience into a governed access path, which is why the primary question is identity control, not interface convenience.

The security issue is not that MCP exists, but that remote tool access can be enabled with minimal friction while policy, approval, logging, and data handling controls remain immature. That creates a familiar identity problem in a new form: a non-human runtime acting through tool permissions that may be broader than the organisation can currently observe or justify.

For identity teams, this sits at the intersection of NHI governance, AI runtime access, and shadow AI discovery. The article describes a practical adoption path that is already ahead of most control models, which is typical whenever a new AI access pattern becomes available before governance catches up.

Key questions

Q: How should security teams govern MCP servers used by AI coding assistants?

A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

Q: When do AI tool integrations become a privileged access risk?

A: They become privileged access risk whenever the AI can reach sensitive systems, move data across trust boundaries, or execute write actions. The risk rises sharply when approval is broad, context is forwarded automatically, or the organisation cannot explain which data a tool received. At that point, the integration behaves like NHI privilege, not a simple productivity feature.

Q: What do organisations get wrong about approval for AI actions?

A: They often assume a single approval step is enough for a whole conversation. In practice, broad approval can give an AI carte blanche to reuse context and act beyond the original intent. Approval has to match the specific action, the specific tool, and the specific data being sent, or it becomes a weak control.

Q: Who is accountable when an AI assistant overshares sensitive content?

A: Accountability sits with the team that owns the policy, the attribute feeds, and the enforcement points, because ABAC only works when all three are managed together. If any one of them is missing, the organisation has not built a defensible control path, even if the model itself appears constrained.

Technical breakdown

MCP server access as a new non-human identity path

Remote MCP connections matter because they extend an AI session from text generation into tool invocation. The AI system becomes a broker between user intent, connected tools, and external data sources, which means the server receiving the request also receives context that may include sensitive information. From an identity standpoint, that context is part of the access transaction. The challenge is not just authentication to the MCP server, but authorisation scope, data minimisation, and traceability for each tool call.

Practical implication: inventory all remote MCP servers as governed NHI touchpoints and classify them by data sensitivity, tool scope, and approval requirements.

Why write actions change the control model

Write actions are materially different from read-only access because they can modify systems, send communications, or trigger downstream automation. The article’s concern is that human approval gates depend on the system correctly recognising what is destructive, while AI reasoning can misclassify intent or impact. That creates a control dependency on classification accuracy inside the AI session itself. Once that happens, the security question becomes whether approval is tied to the actual effect of the action, not merely the label attached to it.

Practical implication: require explicit, action-by-action approval for any write-capable MCP integration and monitor the approval trail as part of privileged access oversight.

Prompt injection and supply-chain exposure through connected tools

Prompt injection becomes more dangerous when the AI can be steered toward an external server that is either malicious or compromised. In that case, the server can receive the full query context, harvest sensitive details, or return instructions that influence later tool use. The article also points to supply-chain risks such as typosquatting and server compromise, which means the trust problem sits both in the model interaction and in the server lifecycle. This is why MCP governance has to cover discovery, vetting, and continuous monitoring, not just onboarding.

Practical implication: enforce allowlisting, periodic revalidation, and telemetry review for every MCP server before it can participate in production workflows.

Threat narrative

Attacker objective: The attacker aims to turn a trusted AI session into an access broker that leaks data or performs harmful actions through remote tool calls.

1. Entry occurs when a user or attacker gains a ChatGPT session that can reach a remote MCP server and the AI sends the server conversation context or tool-request metadata.
2. Escalation occurs if prompt injection or server compromise persuades the AI to call a malicious tool, expose more data, or execute a write action that exceeds the user’s expected scope.
3. Impact occurs when sensitive data is exfiltrated, communications are altered, or connected systems are modified through the trusted AI-to-tool path.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Remote MCP access turns a chat interface into an NHI governance problem. Once an AI session can trigger tools against external servers, the security unit is no longer a prompt but an identity-bearing access path. That shifts control expectations from conversational safety to authorisation, logging, and server trust. Practitioners should treat every connected MCP server as a governed non-human identity dependency, not as an optional integration.

Human approval for write actions is a fragile control when the system itself decides what counts as destructive. The article exposes a control assumption that approval can safely rely on the AI’s classification of action type. That assumption fails when the tool chain can misread impact, because the approval decision is only as accurate as the model’s internal judgment. The implication is that review gates designed for deterministic workflows are being asked to supervise probabilistic action labelling.

Prompt injection plus trusted tool connectivity creates a practical identity breakout pattern. The dangerous part is not prompt injection alone and not MCP alone, but the combination of steerable context and privileged external reach. That combination creates what we would call a context-to-action trust bridge: data from one conversation can influence a tool call that reaches further than the user intended. Security teams need to recognise that this is a governance boundary failure, not just a content-safety issue.

Governance at scale will lag adoption unless organisations formalise MCP inventories now. The article is right that manual controls cannot keep pace with broad employee access to remote AI toolchains. What matters for the field is that discovery, allowlisting, and telemetry become baseline NHI controls for AI-connected systems. Without those controls, enterprises will keep extending access faster than they can explain it, review it, or revoke it.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• For a deeper threat lens, see The 52 NHI breaches Report for breach patterns that show how identity gaps become operational incidents.

What this signals

Context-to-action trust bridge: once an AI session can pass conversational context into an external tool, the governance problem shifts from access control to data-flow control. Teams need to know which tool calls are permitted, what data can cross the boundary, and how quickly a server can be removed from the allowlist when trust changes. That is why MCP governance belongs alongside NIST AI Risk Management Framework thinking, not as an add-on after deployment.

Enterprises should expect MCP-style integrations to accelerate shadow AI discovery work because the user with ordinary ChatGPT access may now become an entry point to external systems. The operational signal to watch is not just volume of use, but whether the organisation can prove who approved the server, what data it received, and whether the connection was still valid at the time of access.

As more AI platforms expose remote tool connectivity, identity programmes will need to extend lifecycle controls to AI-connected servers and the humans who onboard them. That means discovery, periodic recertification, and revocation need to be applied to the integration itself, not only to the human account that clicked connect.

For practitioners

• Establish an approved MCP inventory Create a centrally managed list of permitted MCP servers, grouped by data sensitivity, business purpose, and write capability so every connection has an owner and review cycle.
• Separate read and write permissions Block write-capable MCP actions unless the workflow has explicit per-action approval, because conversation-level approval is too broad for privileged operations.
• Log every tool call and context transfer Capture the server identity, action type, request payload, and approval decision for each MCP interaction so investigations can reconstruct what the AI exposed or changed.
• Apply DLP and session containment Inspect ChatGPT sessions for sensitive data before it reaches external tools and terminate sessions that attempt to send restricted content to untrusted servers.
• Run periodic MCP trust reviews Revalidate every connected server for compromise, ownership changes, and configuration drift, then remove anything that no longer meets policy.

Key takeaways

• ChatGPT-to-MCP connectivity creates an identity and governance problem because tool use now crosses from conversation into external system access.
• The core failure mode is broad approval combined with weak visibility into what data the AI sends and what actions the server can trigger.
• Organisations need allowlists, action-level approvals, logging, and session-level data controls before remote MCP access becomes routine.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Tool Invocation: Tool invocation is an action where an AI agent calls an external system such as a database, API, or file service. Each invocation should be treated as an auditable identity action because it is the point where the agent can move data, trigger changes, or widen its reach across the environment.
• Review Scope: Review scope is the set of identities, entitlements, and systems included in an access certification cycle. Narrow scope makes the process easier but can hide the highest-risk access, while risk-based scope focuses reviewer attention on privileged, external, inactive, and unused entitlements.
• Context Leakage: The unintended exposure of conversation details, connected-system data, or prior prompts to an external tool or server. In AI-integrated environments, context leakage is a governance issue because the AI may send more information than the user expected or intended.

What's in the full article

Noma Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Practical guidance on how to vet remote MCP servers before allowing production use
• Specific recommendations for supervising write-capable AI actions at the approval step
• Examples of runtime protection and kill-switch patterns for destructive AI behaviour
• Policy language ideas for employee education, escalation, and audit logging

👉 The full Noma Security post covers MCP server trust boundaries, approval practices, and runtime protections.

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.