The Intercom MCP server lets Claude, Cursor, ChatGPT, and AI agents read conversations, contacts, tickets, and attachments. Setup, the real security risks, and how to deploy with DLP-grade redaction at the MCP layer.
The Intercom MCP server is a Model Context Protocol implementation that exposes Intercom's API as a standardized set of tools to AI agents. Once connected, an agent like Claude can perform search_conversations, get_conversation, get_contact, list_attachments, and macro operations on the authenticated user's behalf — turning Intercom's API surface into AI-actionable capabilities.
The setup pattern is consistent with other MCP integrations: an Intercom OAuth app registered in the Developer Hub, the appropriate scopes (conversations.read, contacts.read, depending on use case), and the server starts serving tool calls.
From the user's perspective, the AI agent suddenly knows every customer conversation in the org. From the security perspective, the AI agent now has read access — and often write access — to every conversation, contact record, and attachment the user can touch in Intercom.
That's the value. It's also where security teams need a control layer.
The risks fall into four categories that every healthcare, fintech, and consumer-app security team should price into the deployment.
1. Conversation search returns regulated payloads. search_conversations for "refund", "can't log in", or "payment" matches across every conversation the user can read — including conversations where customers have pasted full credit card numbers, account credentials, screenshots with PHI, and identity documents. The agent retrieves the matches and writes them into the model context.
2. Contact records carry full PII. get_contact returns email, phone, location, attributes, and custom fields. Healthcare apps store PHI in custom contact fields. Fintech apps store account identifiers. All of it flows back to the model on a single tool call.
3. Attachments include screenshots and image-based PDFs. list_attachments returns image-content (screenshots customers send to demonstrate a bug), image-based PDFs (insurance cards, IDs), and document attachments — all of which can contain regulated data invisible to text-only DLP.
4. Macros, articles, and AI Fin training data leak internal context. Internal-only macros and Help Center drafts often contain process notes, internal account IDs, and references to customer escalation patterns. An agent retrieving "summarize how we handle billing disputes" can pull internal-only operational content into the model.
The traditional DLP a company already runs does not sit in the MCP path. The tool response goes straight from Intercom into the AI agent's context window. That's the gap Strac Intercom MCP DLP fills.
The most common Intercom MCP deployment in 2026 is Claude as the AI client — particularly for "summarize today's escalations" or "find patterns in churn-risk conversations" workflows. The setup pattern:
.webp)
conversations.read, contacts.read, articles.read, depending on use case).search_conversations, get_conversation, get_contact, and related tools on the user's behalf.The Claude Cowork BAA gap matters here, especially for Intercom. Anthropic does not currently offer a Business Associate Agreement (BAA) for Claude consumer or Claude Cowork plans. For healthcare apps running Cowork against Intercom (where customer conversations routinely contain PHI), that's HIPAA exposure the moment a tool call crosses into the model context. Strac Intercom MCP DLP redacts PHI at the tool-call boundary so the model never sees the regulated data in the first place — closing the gap without depending on Anthropic to ship a BAA. See Is Claude HIPAA compliant? for the full vendor breakdown, and MCP security for the broader architecture.
For Claude Code / Cursor / ChatGPT deployments, the same Strac control plane applies — vendor-independent.
Strac wraps the official Intercom MCP server with a redaction engine. Every tool call from an AI agent passes through Strac before reaching Intercom — and every Intercom response passes through Strac before reaching the model.
Inspect every tool call payload using Strac's catalog of sensitive data elements — PII, PHI, PCI, credentials, source code, and any custom data class you define.
Redact sensitive fields inline, or tombstone entire responses based on policy. Conversation bodies with pasted credit cards are masked. Screenshots attached to bug reports are OCR-inspected for embedded PHI. Contact records with regulated custom fields are filtered.
Vault redacted content in Strac's encrypted store, with re-identification gated by RBAC for the small subset of users who need the raw value.
Audit every call with full provenance: agent identity, tool name, timestamp, returned-data classification, and remediation action. The same audit feed powers compliance evidence for SOC 2, HIPAA, PCI, ISO 27001, GDPR, and the EU AI Act.
Setup is agentless and under 10 minutes per Intercom workspace.
Strac's Intercom protection is not new. Strac ships Intercom DLP for the broader Intercom surface — real-time inspection of every conversation message, attachment, and macro for sensitive data, with redaction at the point the data enters Intercom (not just when an agent reads it). The MCP layer extends that protection into the AI agent path:
The MCP layer adds: agent-aware redaction at the tool-call boundary, on top of the message-time redaction that Strac Intercom DLP already provides.
Intercom joins Strac's MCP DLP coverage across every major SaaS surface AI agents touch:
Phase 1 — Inventory and BAA
Phase 2 — MCP layer protection
Phase 3 — Governance and audit
Yes. The Intercom MCP server is set up as a custom connector in Claude Desktop, Claude Code, or Claude for Cowork — the same pattern as other MCP integrations. You register an Intercom OAuth app, paste the client ID/secret into the Claude connector config, and Claude can call search_conversations, get_conversation, get_contact, and related tools. For HIPAA-regulated content, route the connector through Strac Intercom MCP DLP so PHI is redacted before reaching the model context. See Is Claude HIPAA compliant? for the BAA picture.
Customers routinely paste full credit card numbers into Intercom chat ("here's the card I was trying to use"). This is one of the most common PCI compliance failures in customer-facing apps. Strac Intercom DLP catches the paste at the conversation layer; Strac Intercom MCP DLP catches the same data again at the tool-call layer when an AI agent retrieves the conversation. Layered, agent-aware, audit-ready.
Yes. Strac inspects every attachment via OCR — screenshots customers send to demonstrate a bug, image-based PDFs of insurance cards or IDs, document attachments. Sensitive data inside images is detected and redacted at the MCP boundary.
Intercom's native AI features (Fin, AI Copilot) run inside the Intercom tenant on Intercom's infrastructure under Intercom's controls. The Intercom MCP server is the path where external AI clients (Claude, Cursor, ChatGPT) read Intercom data. Strac Intercom MCP DLP protects that external path — what Intercom's own AI controls cannot see, because the data has left Intercom's perimeter.
Yes. The MCP protocol is vendor-independent. Strac's Intercom MCP DLP sits between any MCP-aware client (Claude, Cursor, ChatGPT, Perplexity, custom agents) and the Intercom API.
Internal-only macros, Help Center drafts, and operational notes are sometimes used as Fin training data. An MCP-connected external agent retrieving "summarize our billing dispute process" can pull that internal context into the model. Strac filters internal-only content categories per policy so they don't leak out to external AI clients.
The Intercom MCP server itself is just a transport layer. Safety for healthcare depends on three things: (1) the Intercom tenant has a BAA in place (Intercom supports HIPAA on certain plans); (2) the AI client has its own BAA (ChatGPT Enterprise, M365 Copilot, Gemini Workspace yes; Claude Cowork no); (3) sensitive data is redacted at the MCP tool-call boundary before reaching the model. Strac handles (3). See MCP security for the full risk landscape.
Under 10 minutes per Intercom workspace. Agentless: no application code changes, no Intercom re-permissioning, no agent SDK rewrites.
Yes. Every tool call generates an audit event with full provenance — agent identity, tool name, timestamp, returned-data classification, and remediation action. Audit logs export to SIEM and GRC platforms; pre-built mappings cover SOC 2 CC6, HIPAA Security Rule, PCI Req. 3/4/7/10, GDPR Art. 5/25/30/32, EU AI Act Article 12, and ISO 42001 Annex A.8.
Strac Intercom DLP enforces user-facing policy at the Intercom conversation layer — real-time scanning of customer-pasted content, redaction of credit cards in messages, attachment OCR. Strac Intercom MCP DLP enforces agent-facing policy at the MCP tool-call layer — inspects and redacts what AI agents retrieve from Intercom. Most enterprises deploy both for full coverage — message-time + agent-time.
Intercom is the PII-richest SaaS surface in most consumer-facing apps. The 2026 risk is agent-aware: AI clients reading customer conversations via MCP get all of that PII in the model context. Strac is the data-layer control that closes the gap — built on top of Strac's existing Intercom DLP integration.
.avif){kind=icon}
.gif)
