Why the EHS Insight MCP Connector Is a Security Upgrade, Not a Security Risk

Start With the Uncomfortable Truth

Before we get into how the EHS Insight MCP connector works at a security level, I want to start with what is already happening in most organizations that use EHS software.

Your safety team exports incident records to Excel. They paste the data into ChatGPT to draft an executive summary. They copy CAPA tables into Claude to help write a corrective action narrative. They upload audit findings as a PDF to a generative AI to extract obligations. They are doing all of this because AI tools are useful and the work needs to get done.

None of that workflow appears in your security review. It does not show up in your data loss prevention logs in any structured way. It probably did not get a sign-off from your CISO. It happens anyway because the productivity gain is real and the alternative is doing the work the old way.

The first thing the MCP connector does is replace that workflow with something measurably better. Before we get into the protocol mechanics, that frame matters. We are not introducing AI access to your EHS data. AI access already exists. We are giving you a governed channel for it.

“MCP is a governed, structured, secure way of connecting EHS Insight data into an enterprise AI tool that employees are already using. It is so much better than the alternative of having users export data to countless Excel files and uploading them to ChatGPT over and over.”

- Eric Stevens, Chief Technology Officer, EHS Insight

How Authentication Works

MCP connections to EHS Insight use OAuth 2.0, the same standard your enterprise applications use today for delegated access. There are no shared service accounts. There are no embedded API keys. There is no need to provision an integration user.

The flow looks like this.

• Step 1. A user opens Claude, ChatGPT, or Microsoft Copilot and adds EHS Insight as a connector by entering the EHS Insight URL associated with their account (for example, yoursite.ehsinsight.com/mcp).
• Step 2. The AI tool redirects the user to EHS Insight’s authentication endpoint. The user logs in using their existing EHS Insight credentials, including SSO if your organization has SSO configured.
• Step 3. EHS Insight presents a permission approval screen describing what access the AI tool is requesting. The user explicitly approves the grant.
• Step 4. EHS Insight issues an OAuth token to the AI tool. That token is bound to the authenticated user and their permission set at the time of issue.
• Step 5. When the user asks a question in their AI tool, the tool uses the OAuth token to make authenticated API calls back to EHS Insight on the user’s behalf. Each call is identifiable to the originating user.

The token can be revoked at any time, either by the user (removing the connector from their AI tool) or by an EHS Insight administrator (revoking the grant in the platform). Standard OAuth lifecycle controls apply.

Permission Inheritance Is Strict and at the Query Layer

This is the part that most often gets misunderstood about MCP integrations, so I want to be precise.

When the AI assistant queries EHS Insight on behalf of a user, the query returns exactly the data that user’s role and permissions in EHS Insight already allow. Nothing more. The enforcement happens at the query layer, which is the same place EHS Insight enforces permissions for the UI and for our Power BI connector.

Two examples make this concrete.

First example. A site safety manager at the Houston facility connects EHS Insight to Claude. They ask Claude to summarize incident trends for the company. Claude makes the appropriate API calls, but the API returns only the Houston facility’s data, because that is what the safety manager’s role permits. Claude’s answer is scoped to Houston, even though Claude itself has no awareness of the permission model. The data simply was not returned for any other facility.

Second example. A corporate EHS director with enterprise-wide visibility connects EHS Insight to ChatGPT. The same query returns the full enterprise rollup, because that is what their role permits.

If a user does not have permission to see PII fields in EHS Insight, their AI sessions will not receive those fields. The AI assistant never sees them, cannot reason about them, and cannot disclose them. The permission model your team configured in EHS Insight is the permission model that governs every MCP query.

“MCP allows Claude to query EHS Insight servers using the credentials of the authenticated user. It is going to get back exactly what that user’s roles and permissions already allow. Nothing more.”

- Eric Stevens, Chief Technology Officer, EHS Insight

Every Query Is Audit Logged

Every MCP query against EHS Insight generates an entry in the same audit log that records UI sessions and public API calls. The log captures the authenticated user, the timestamp, the endpoint queried, and the records returned, with the same fidelity your team is already accustomed to in EHS Insight’s audit trail.

That has two implications for your security and compliance posture.

First, MCP activity is auditable in the same way as any other EHS Insight access. The same reports your team runs for UI access can include MCP access. You can answer questions like “who queried this set of incident records in the last 30 days” regardless of whether the query came from the UI, the API, or an MCP session.

Second, unlike the export-and-paste workflow we discussed at the top of this post, MCP queries are governed. The data does not leave through a Slack message or an unmonitored upload. It moves through an authenticated, logged channel that you can audit, attest to, and produce in a compliance review.

Why EHS Insight Is Not a New AI Subprocessor

One of the first questions I get from security teams is whether using the MCP connector adds a new vendor to their data flow. The answer is no, because of how the architecture is laid out.

The MCP connector is the integration. It runs as part of EHS Insight’s existing infrastructure. It does not introduce a new third party between you and your EHS data. We are the same vendor handling the same data we have always handled, under the same DPA and security commitments.

The AI side of the conversation, the part where Claude or ChatGPT or Microsoft Copilot is reasoning about your question and presenting an answer, is governed by your existing agreement with that AI vendor. If your organization is running Claude Enterprise, the data passed through your MCP session is handled under your Claude Enterprise agreement. Same for ChatGPT Enterprise. Same for Microsoft Copilot. Those vendor relationships, their security reviews, their data handling commitments, all of that is already in place. The MCP connector does not modify them.

The practical implication is that adopting the EHS Insight MCP connector does not require your team to evaluate a new subprocessor, sign a new DPA, or extend any data handling agreement. The connector reuses the agreements you already have.

Where the Customer’s Responsibility Sits

Honesty is important here. The MCP connector handles a set of security concerns. It does not handle all of them. Your team retains responsibility for a few things.

• Choosing which AI vendor your team uses, and managing the enterprise agreement with that vendor. EHS Insight does not control how Anthropic, OpenAI, or Microsoft handles data within their environments. That is your vendor relationship to manage.
  
  
• Defining who in your organization is allowed to enable MCP. By default, any EHS Insight user can connect their own AI session. If your team prefers central control, EHS Insight administrators can scope MCP enablement to specific users or roles.
  
  
• Setting and maintaining the underlying permission model in EHS Insight. Since MCP inherits those permissions, the integrity of MCP’s access controls depends on the integrity of your EHS Insight role configuration.
  
  
• Educating your users on what AI tools are appropriate for what conversations. MCP gives your AI tool access to live data. The judgment about what to ask, and about whether the answer should be acted on without human review, remains with the user.

Alignment With SOC 2 and ISO 27001

EHS Insight maintains SOC 2 Type II and ISO 27001 certifications. The controls that apply to UI and public API access apply equally to MCP access. There is no separate compliance posture for MCP; it operates inside the same control environment.

Specifically, the controls that govern authentication, authorization, audit logging, change management, vulnerability management, and incident response apply to MCP traffic. Our certification reports cover the platform as a whole, including the MCP endpoint.

A Decision Framework for IT

If your team is deciding whether to enable MCP and how to scope it, here is the framework we recommend.

• Step 1. Confirm your organization has an enterprise agreement in place with Anthropic, OpenAI, or Microsoft for the AI tool you intend to use. If your team is on consumer-tier ChatGPT or Claude, the agreement that governs how data is handled is the consumer agreement, which most organizations consider insufficient for sensitive operational data.
  
  
• Step 2. Decide whether MCP enablement is open to all EHS Insight users or scoped to specific roles. The default is open. Scoping requires an administrator action in EHS Insight.
  
  
• Step 3. Review your EHS Insight permission model and confirm it reflects your current desired access posture. Because MCP inherits these permissions, this is a useful checkpoint for the permission model itself.
  
  
• Step 4. Communicate enablement to your user base, with light guidance on appropriate use (for example, what kinds of questions to ask, when to verify AI output, what not to share with the AI assistant beyond the MCP-returned data).
  
  
• Step 5. Add MCP traffic to your existing periodic audit log review. It uses the same log surface as UI and API access, so no new tooling is required.

Frequently Asked Questions

Does the AI vendor retain our EHS data after a session ends?

That depends on your agreement with the AI vendor. Anthropic, OpenAI, and Microsoft each have enterprise data handling policies that typically include data isolation, retention controls, and assurances against training on customer data. Review your specific agreement with the AI vendor you use. EHS Insight does not modify those terms.

Can MCP queries be intercepted in transit?

All MCP traffic between EHS Insight and the AI tool is encrypted in transit using TLS, the same encryption protocol used by your web browser and EHS Insight UI sessions. The OAuth token used for authentication is also transmitted over TLS and is bound to the authenticated user.

What happens if a user is offboarded?

When a user is deactivated in EHS Insight (or in your identity provider if you use SSO), any active MCP connections they have are invalidated. The OAuth token associated with the user no longer authenticates against EHS Insight, and subsequent queries fail. This applies the same way as any other authentication path.

Can I see a list of all active MCP connections for my organization?

Yes. EHS Insight administrators can view the active OAuth grants associated with their organization’s users and can revoke any individual grant at any time.

Does MCP increase our exposure to data exfiltration?

MCP changes the shape of AI-related data access, but it does not increase the upper bound of what an authenticated user can already access through the UI or public API. A user who could already export the data through the EHS Insight UI can now query it through their AI tool. The data perimeter is the same. What changes is that MCP access is governed, logged, and auditable in a way the export-and-paste workflow is not.

Is the EHS Insight MCP endpoint included in your SOC 2 Type II and ISO 27001 scope?

Yes. The MCP endpoint operates as part of EHS Insight’s production environment and is covered by the same control framework documented in our certification reports.

How is read access enforced today versus future capabilities?

The current release of the MCP connector is read-only. The connector exposes endpoints that retrieve data but does not expose endpoints that create or modify records. Additional capabilities are in active development. When those capabilities ship, they will be governed by the same authentication, permission inheritance, audit logging, and certification framework documented in this post.