TL;DR
- Model Context Protocol lets any employee connect a corporate SaaS MCP server — GitHub, Jira, Salesforce, Slack — to their personal ChatGPT or Claude account in under two minutes, sending corporate data to a third-party AI with no audit trail, no signed DPA, and no corporate oversight.
- 67–73.8% of enterprise ChatGPT usage already happens through unmanaged personal accounts. When those accounts carry MCP connectors to company systems, every conversation becomes an uncontrolled data transfer.
- Traditional security controls — SSO logs, network DLP, CASB — cannot see this: MCP calls travel server-to-server between OpenAI and your corporate SaaS, completely bypassing the employee's device.
- The Ethira browser extension detects the threat through five correlated browser-level signals: AI provider recognition, personal account inference from missing corporate SSO, outbound prompt interception and PII scanning, and third-party corporate domain cross-correlation.
- When signals align, Ethira attributes the event to a named employee, records the PII categories detected, and can block the request in real time before data reaches OpenAI's servers.
What the threat actually looks like
Model Context Protocol (MCP) was designed to solve a genuine productivity problem: connecting AI assistants to the systems that hold the data they need. An engineer can point Claude or ChatGPT at a GitHub MCP server and get their pull requests summarised. A sales manager can connect Salesforce and ask for a pipeline summary. A support lead can connect Jira and triage their backlog in a conversation.
The problem is that MCP does not care whether the AI client is a corporate account or a personal one.
When an employee goes into ChatGPT's developer mode and adds a custom MCP connector — something that takes less than two minutes — they are linking your corporate SaaS to their personal OpenAI account. Every conversation that follows can pull live company data: source code, customer records, Slack messages, financial figures, or whatever the MCP server exposes. That data flows from your corporate SaaS, through OpenAI's servers, and into a personal account that your security team has no visibility over and no contractual relationship with.
The data flow looks like this:
- The employee opens their personal ChatGPT account and types a work-related prompt.
- ChatGPT calls the connected corporate MCP server on OpenAI's infrastructure — not from the employee's browser.
- The MCP server, authenticated with the employee's corporate credentials, returns company data.
- That data is processed by OpenAI's models, stored in conversation history, and potentially used under the personal account's terms of service — not your enterprise DPA.
A September 2025 demonstration by security researcher Eito Miyamura made this concrete: a malicious calendar invite, read via a Google Calendar MCP connector connected to ChatGPT, silently exfiltrated the victim's emails to an attacker using a Zapier write-action connector. The approval prompt was deliberately obscured to read only "Would you like me to help you prepare for it?" The user approved. Their emails left the organisation. The same attack chain works without any malicious actor — every routine prompt against a corporate MCP connector is, structurally, an uncontrolled data transfer to a personal account.
Why traditional security tools miss it
Every standard control in the enterprise security stack has a structural blind spot for this threat.
| Control | What it catches | Why it misses MCP + personal AI |
|---|---|---|
| SSO / IdP logs | Apps employees authenticate to via corporate identity | Personal ChatGPT accounts bypass SSO entirely — no authentication event is generated |
| Network DLP / proxy | Outbound traffic to known AI domains | MCP calls happen server-to-server on OpenAI's infrastructure, not from the employee's device |
| SaaS CASB | API activity within sanctioned SaaS tools | Sees the MCP server being called but cannot attribute it to a personal AI session |
| GitHub / Jira audit logs | API access events tied to user credentials | Records that credentials accessed data, but not where that data went next |
| Endpoint DLP | File transfers and clipboard activity | Prompt-based data transfer with MCP leaves no file on disk |
The critical gap is architectural. Standard DLP and proxy solutions inspect traffic that originates from the employee's device. The MCP call that retrieves your Jira tickets or GitHub code is initiated by OpenAI's servers, not by anything in the employee's browser. By the time company data appears in a ChatGPT response, the transfer has already happened — server-side, silently, outside every perimeter control the organisation has deployed.
The Noma Security analysis of ChatGPT MCP (2025) summarised the governance gap directly: "Security teams currently lack adequate tools to manage authorised MCPs, enforce controls over transmitted data, or monitor MCP interactions at scale."
How the Ethira browser extension detects it
The Ethira browser extension operates at the one layer that is present regardless of where MCP calls travel: the employee's browser. It does not attempt to intercept server-to-server traffic — it cannot and does not need to. Instead, it correlates five browser-level signals that, taken together, reliably identify a personal AI session consuming corporate data.
Signal 1 — AI provider detection and session confirmation
The extension maintains a catalogue of known AI provider hostnames — including chatgpt.com, claude.ai, gemini.google.com, chat.mistral.ai, and dozens more — alongside heuristic matching for AI-adjacent hostname patterns (gpt, llm, copilot tokens and common SaaS subdomain prefixes). When an employee navigates to any of these hosts, the extension records the visit.
A visit alone is a weak signal. The extension upgrades it to a confirmed AI interaction when it detects a text/event-stream response — the server-sent events (SSE) stream that every major AI chat interface uses to deliver streaming completions to the browser. An SSE stream from an AI provider domain means the employee is not just browsing; they are receiving AI-generated output in an active session.
Signal 2 — Personal account inference from absent corporate SSO
Enterprise-managed ChatGPT and Claude accounts authenticate via corporate SSO. When an employee on a managed device visits chatgpt.com, the extension watches for an OAuth redirect carrying corporate IdP parameters — the pattern that appears when a corporate account bounces through Okta, Azure AD, or Google Workspace before landing in the AI tool.
When a login flow fires on chatgpt.com but no corresponding SSO redirect to a corporate IdP is detected, the extension records a personal account indicator. This is not a hard classification on its own — it contributes a weighted signal to the session's risk profile. Combined with the other signals below, it becomes the anchor that distinguishes a managed corporate subscription from an unmanaged personal account.
Signal 3 — Outbound prompt interception and AI-specific body parsing
The extension installs a thin wrapper around fetch and XMLHttpRequest in the browser's main world. Every outbound request that leaves the browser is visible to this wrapper. For requests destined for known AI API endpoints — api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, and equivalents — the extension applies a provider-specific parser.
Rather than scanning the entire raw request body (which for AI API calls includes system prompts, tool definitions, and context that is not employee-authored), the parser extracts only the fragments that the employee actually typed or pasted. This precision matters: it focuses scanning on the data the employee is actively choosing to send, and substantially reduces false positives from benign tool or system context.
Signal 4 — PII category detection via scanner and optional NER model
The extracted prompt fragments pass through a layered PII scanner:
- Regex patterns covering email addresses, phone numbers, payment card numbers, IBANs, national ID formats, postal addresses, passport identifiers, and GDPR special-category field names (health markers, political opinion indicators, biometric data references).
- Optional ONNX inference using the Piiranha named-entity recognition model (
detect-personal-information) to confirm or filter regex hits, reducing noise on ambiguous matches.
When the scanner identifies one or more PII categories, it emits a detection event containing: the destination domain (api.openai.com), the detected categories (for example, EMAIL, NATIONAL_ID, IBAN), an anonymised snippet sufficient for context without re-exposing the raw data, and the session timestamp. The employee's identity — resolved from the managed browser profile — is attached to the event server-side.
In enforcement mode, the extension blocks the request before it reaches OpenAI's servers and displays a modal explaining what was detected and why the transmission was stopped.
Signal 5 — Third-party corporate domain cross-correlation
The extension's network request observer records every third-party domain that receives or responds to a request during a browser tab's session. For a tab open on chatgpt.com, this captures any domains the ChatGPT web interface contacts in the background.
When an employee is setting up or refreshing an MCP connector, the ChatGPT interface initiates OAuth or discovery requests from the browser to the MCP server's authentication endpoint. These requests appear in the third-party domain log for the chatgpt.com tab. If those domains match known corporate SaaS endpoints — api.github.com, api.atlassian.com, api.salesforce.com, slack.com/api — Ethira flags the correlation: a personal AI session with an active corporate SaaS connection visible at the browser level.
What detection looks like in practice
Consider a typical scenario. An engineer at a financial services firm connects their company's GitHub MCP server to their personal free-tier ChatGPT account to speed up code review. They begin using it daily.
Here is how the detection unfolds:
- The engineer opens
chatgpt.com. The extension recognises the hostname from the AI provider catalogue and begins monitoring the tab. - The browser receives SSE responses from OpenAI. The streaming signal fires, confirming an active AI conversation.
- A login flow was observed without a corporate SSO redirect — the personal account indicator is set.
- The engineer types a prompt that includes an internal module name and pastes in a code snippet that contains a customer identifier format. The browser sends a POST to
api.openai.com/v1/chat/completions. - The extension's
fetchwrapper intercepts the request. The OpenAI-specific parser extracts the user-authored fragment from the messages array. - The PII scanner finds an EMAIL pattern and a customer ID pattern in the extracted fragment. A detection event fires to the Ethira API.
- Meanwhile, the tab's domain observer has logged a request from the
chatgpt.comcontext toapi.github.com— the OAuth handshake that occurred when the engineer set up the MCP connector earlier in the session. - Ethira receives both events: the PII detection and the third-party domain signal. It correlates them against the engineer's named profile and the organisation's known MCP server inventory.
- An incident is created: "Personal AI session — PII categories: EMAIL, CUSTOMER_ID — Corporate domain signal: api.github.com — Employee: [name] — Team: Platform Engineering."
If enforcement mode was enabled, the POST in step 4 never reached OpenAI. The data stayed on the employee's device, and the modal explained precisely why.
What Ethira does with the signal
Detection without action is monitoring theatre. Ethira connects the browser signals to its broader risk governance layer.
Named owner attribution. Every detected session is attributed to a named employee via the managed browser profile. The employee's team, function, and legal entity are resolved automatically from your HRIS and SSO directory — no manual tagging required, and the attribution updates as your org structure changes.
Vendor and DPA gap flagging. Personal ChatGPT accounts have no enterprise DPA. When an employee sends company data through a personal AI account, there is no GDPR Article 28 processor agreement covering that transfer. Ethira flags the vendor gap and queues it for review in the vendor register, with the relevant PII categories pre-populated.
Enforcement mode. Workspace administrators can configure body rules that block outbound requests matching specific PII categories for specific destination domains. In this mode, the browser extension prevents the data transfer before it completes rather than reporting it after the fact.
Continuous inventory. Detection is not a point-in-time scan. Every new session is evaluated in real time. If an employee sets up a new MCP connector, switches from a corporate to a personal account, or begins using ChatGPT on a new managed device, the change appears in the Ethira console the moment it is first detected.
Regulatory exposure
The combination of personal AI accounts and corporate MCP connectors creates compliance gaps that regulators are actively addressing.
GDPR Article 28 requires a signed Data Processing Agreement with any processor that handles personal data on your behalf. A personal ChatGPT account is not a processor relationship — it is the employee's own account, with no corporate legal nexus. Any personal data that passes through it sits outside a valid legal basis, and your organisation remains the controller responsible for it.
The EU AI Act requires documented governance over the AI systems an organisation deploys. An employee running agentic workflows against corporate data via MCP on a personal account is, in practice, deploying an AI system — one the organisation has no record of, no control over, and no ability to audit.
DORA requires financial entities to identify and manage ICT third-party risk. A personal ChatGPT account connected to corporate systems via MCP is an unmanaged ICT dependency. DORA's Register of Information cannot account for it because the organisation does not know it exists.
ISO 42001 requires a documented AI system inventory. Like the EU AI Act, it cannot be satisfied if employees are running unregistered AI workflows against corporate data on personal accounts.
In each case, the gap is a visibility failure before it is a policy failure. The organisation cannot govern what it cannot see. Browser-level detection closes that gap and gives governance something to work with.
Frequently asked questions
Does the Ethira extension read the content of my employees' conversations?
No. The extension intercepts outbound request bodies to known AI endpoints and scans extracted prompt fragments for PII category signals. It does not log or store conversation content. The detection event records the identified categories and an anonymised snippet — not the raw prompt text. Full conversation content never reaches Ethira's servers.
What if an employee uses the ChatGPT mobile app instead of a browser?
The browser extension only operates in managed Chrome or Edge deployments. Mobile app usage falls outside its scope. Complementary controls — mobile device management (MDM) or a network-level egress proxy — are needed to address that channel. Ethira's SSO-based discovery will also miss it if the employee is using a personal account, which makes the browser layer the last meaningful detection point for browser-based sessions.
Can the extension see the actual MCP calls that ChatGPT makes to corporate SaaS?
No. MCP calls initiated by OpenAI's servers to your corporate SaaS happen on OpenAI's infrastructure, not in the employee's browser. The extension detects the setup activity (OAuth flows during connector configuration), the prompt content the employee sends (before it reaches OpenAI), and the browser-level session characteristics. This is sufficient to attribute the risk and, in enforcement mode, prevent sensitive data from entering the AI pipeline before the MCP call is ever triggered.
Does deployment require any action from employees?
No. The extension deploys via a browser policy push to the entire managed device fleet — the same mechanism used for safe browsing policies. Individual employees do not need to install anything, grant permissions, or take any action.
Sources
- LayerX Security — AI Is Now the #1 Data Exfiltration Vector in the Enterprise (2025) — layerxsecurity.com
- Noma Security — Critical Recommendations for the Secure Use of Model Context Protocol Servers via ChatGPT (2025) — noma.security
- PromptArmor (Board Security Inc) — ChatGPT + Custom MCP Data Exfiltration (September 2025) — promptarmor.substack.com
- Checkmarx — MCP Security: Risks, Best Practices, and Security Controls (2025) — checkmarx.com
- Red Hat — MCP Security: The Current Situation (2025) — redhat.com
- Aaronshenhao et al. — Securing the Model Context Protocol (MCP): Risks, Controls, and Governance — arXiv:2511.20920 — arxiv.org
- Heitmann et al. — Enterprise-Grade Security for the Model Context Protocol (MCP): Frameworks and Mitigation Strategies — arXiv:2504.08623v2 — arxiv.org
- IBM Security — 2025 Cost of a Data Breach Report (Ponemon Institute) — ibm.com
- Menlo Security — 2025 Shadow AI in the Modern Enterprise Report — menlosecurity.com
- BlackFog — Shadow AI Threat Grows Inside Enterprises (2025) — blackfog.com