The remote HubSpot MCP server became generally available on April 13, 2026. It connects any MCP-compatible AI client — Claude, ChatGPT, Cursor, custom agents — to your CRM over a HubSpot-hosted connection, authenticated with OAuth 2.1 and PKCE. The security reality behind it is simple: every tool call returns whatever data the authorizing user can already see. Securing it is less about the protocol and more about scope discipline, HubSpot's own sensitive-data controls, human checkpoints on writes, and the data-processing agreements GDPR requires once CRM data leaves for an external AI client.
Quick answer: The HubSpot MCP server is secure at the transport and permission layer (OAuth 2.1 + PKCE, user-level permissions enforced). The risk lives one layer up — in what the connected AI client does with the data it can now read and write, and in prompt-injection and tool-poisoning attacks that the protocol does not stop on its own.
The HubSpot MCP server is a Model Context Protocol endpoint, hosted by HubSpot at mcp.hubspot.com, that lets MCP-compatible AI tools read from and write to your CRM through natural language. The Model Context Protocol is a standard that lets AI agents request context from, and take actions in, external systems through a defined interface.
As of the April 2026 general-availability release, the server exposes:
One distinction matters before any security discussion: the remote HubSpot MCP server is separate from the developer MCP server, which is a local tool for building apps and CMS content. This article is about the remote server — the one that touches live CRM data.
The protocol itself is not the weak point. Three things are.
Inherited permissions become an AI's reach. Every MCP tool call returns the data the authorizing user can see. If a sales rep with broad portal access connects an AI client, that client can now read every contact, deal, and engagement that rep could. The blast radius of one over-permissioned connection is the whole surface that user touches.
Prompt injection. Attackers embed hidden instructions in content the AI processes — a note field, an email body, a web page the agent reads. The agent follows them. The OWASP Top 10 for Agentic Applications (2026) classifies this family as ASI01, Agent Goal Hijack. Security researchers have tracked prompt injection for years and still describe it as an unsolved problem, not a patched one.
Tool poisoning. AI agents trust the metadata a server advertises — tool names, descriptions, parameter schemas — to decide what to call. A malicious or compromised server can hide instructions inside that metadata, invisible to the user but read by the model. Invariant Labs demonstrated a case where a poisoned tool description on a secondary server caused an agent to exfiltrate a user's entire message history through a tool call that looked benign. Because users approve a tool once and rarely re-review it, a poisoned definition persists across every future session. The risk grows when one trusted server runs alongside several third-party ones: a malicious server's description can hijack behavior across the others.
No single control covers this. The working approach is layered.
1. Keep authentication managed. OAuth 2.1 with PKCE is required for every connection, and that is the right baseline. Create the connection through HubSpot's MCP Auth Apps so credentials are generated and managed by HubSpot rather than hardcoded into config files. Avoid pasting long-lived tokens into local setups.
2. Minimize scope, per connection. All MCP actions respect existing HubSpot user permissions — users can only access or modify records they already have rights to. Use that. Connect AI clients under accounts scoped to the minimum the task needs, not under admin or super-admin seats. The 2026 MCP specification update added incremental scope consent, letting clients request only the access a given operation needs rather than everything upfront; lean toward that pattern where your tooling supports it.
3. Turn on HubSpot's sensitive-data setting. This is the most direct, HubSpot-native control available. If your account has sensitive data turned on, engagement objects — calls, emails, meetings, notes, and tasks — are blocked from access through the MCP server. The restriction is specific to the MCP server; it does not apply to the standard CRM APIs. For regulated portals, this is the single switch that keeps the most sensitive free-text content out of AI clients without breaking the rest of your stack.
4. Put a human in the loop on writes. General availability added write access, which changes the risk profile. Creating, updating, and deleting records — and now creating engagements — are operations a mistaken or injected instruction can damage in ways that are hard to reverse. The MCP specification itself states there should always be a human able to deny a tool invocation. Enforce approval on destructive or bulk operations rather than letting an agent run them unattended.
5. Vet every other MCP server in the session. Because tool poisoning travels through metadata and across servers, treat each connected server as part of your trust boundary. Run trusted servers in isolation from unvetted third-party ones, and re-review tool definitions after updates rather than trusting a one-time approval.
6. Monitor and log at the MCP layer. Traditional bot and identity controls do not see these attacks, because they ride legitimate, authenticated channels. Behavioral monitoring, audit logging of tool calls, and MCP-layer data-loss-prevention give you the evidence trail and the chance to catch exfiltration that looks like normal traffic. Be aware of the trade-off: the moment you log prompts and outputs, that log becomes a new store of personal data you have to protect.
Compliance is not a property of the server; it is a property of your deployment. The HubSpot MCP server can be part of a GDPR-compliant setup, but connecting it does not make one.
The mechanism to watch: MCP routes CRM data to whatever AI client you connect. If that client's provider processes the data on your behalf, it is a processor under GDPR, and Article 28 requires a data-processing agreement before personal data flows to it. A personal or low-tier AI account without a DPA behind it is the gap most teams miss. In practice that means routing AI integrations through commercial or enterprise plans that carry a DPA, turning on the sensitive-data setting, and running a DPIA where the data involved warrants it — before you switch on content-level logging.
This is a compliance design question, not legal advice; confirm specifics with your own counsel for your jurisdiction and data.
Is the HubSpot MCP server secure? At the connection and permission layer, yes — it uses OAuth 2.1 with PKCE and enforces existing user permissions. The residual risk is in what the connected AI client does with that access, and in prompt-injection and tool-poisoning attacks the protocol does not block by itself.
Does the HubSpot MCP server respect user permissions? Yes. Users can only access or modify records they already have permission to view or edit. An AI client connected under a given user inherits exactly that user's reach — no more, no less.
Can the HubSpot MCP server expose sensitive data? It can return any data the authorizing user can see. HubSpot's sensitive-data setting blocks engagement objects (calls, emails, meetings, notes, tasks) from the MCP server specifically, which is the main native control for limiting exposure.
What is the difference between the remote and developer HubSpot MCP servers? The remote server (mcp.hubspot.com) connects AI clients to live CRM data. The developer MCP server is a local tool for building apps and CMS content. Security decisions about live data apply to the remote server.
Do I need a DPA to use the HubSpot MCP server in the EU? If the connected AI client's provider processes personal data on your behalf, GDPR Article 28 requires a data-processing agreement with that provider. The HubSpot MCP server moving data to that client is what triggers the requirement.