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
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.
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.
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 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.
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.
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.
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.
If your team is deciding whether to enable MCP and how to scope it, here is the framework we recommend.
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.