How to Block Sensitive Data from HubSpot MCP
Your sales team wants Claude connected to HubSpot. Your security team wants to know why an AI agent needs every closed-won deal amount and every note on the strategic accounts pipeline. Both sides are right, and HubSpot’s MCP server doesn’t let you split the difference.
The one switch HubSpot does offer makes the trade-off visible. If an account has Sensitive Data turned on, HubSpot blocks calls, emails, meetings, notes, tasks, and conversations from access through the MCP server. That setting applies to the whole account, removes the activity history that makes a CRM agent useful, and leaves deal records, amounts, and pipeline fields fully readable.
This guide shows how to build a custom rule engine on MCP Manager’s gateway that blocks or redacts specific pipelines, deal stages, and properties before they reach the model, while the rest of HubSpot stays available to the agent.
Key Takeaways
- HubSpot’s MCP server acts with the connecting user’s permissions, with no narrower layer for the agent.
- Sensitive Data blocks activity and conversation data through MCP account-wide, but not deals or pipelines.
- An MCP gateway rule sends each HubSpot tool call to a webhook you build, which returns pass, modify, or block.
- This is a custom rule engine, not a managed blocker. Your team writes, hosts, and maintains it.
- Two extra layers complement the custom rule: feature provisioning trims the tool list, and Presidio or regex rules catch PII in free text.
Why HubSpot MCP Access Is an All-or-Nothing Problem
HubSpot’s remote MCP server at https://mcp.hubspot.com authenticates each user through OAuth 2.1 with PKCE. Since the server became generally available, it reads and writes CRM records, activities, campaigns, and marketing content, and every action respects the user’s existing HubSpot permissions. Whatever the person can see, their agent can query.
What HubSpot’s Native Controls Can and Can’t Do
HubSpot has granular controls for people: owned-only or team-only record access, property-level view and edit access on Enterprise tiers, and pipeline rules that limit who can edit records in specific stages.
All of these bind to the user, and the agent inherits everything the authorizing rep can see. HubSpot’s documentation states that connector scopes aren’t defined manually. They follow from the server’s tools and the permissions the user grants at install time. The documented connector settings and tools include no agent-specific role and no pipeline-level restriction.
That leaves three native options, and each costs more than it protects:
- Narrow the person’s permissions until they match what the agent should see. This breaks the rep’s daily work.
- Turn on Sensitive Data. This removes notes, calls, emails, and conversations for every agent, while deal amounts and pipeline data stay exposed.
- Don’t connect the MCP server. Your AI rollout then produces meeting summaries instead of pipeline insights.
Human Access Is Not Agent Access
A person opens a deal record on purpose. An AI agent asked to “summarize all open deals” runs a CRM search across every pipeline in scope, because deals in the strategic accounts pipeline are technically open deals too.
What the agent reads is also model input. Notes and conversations from live chat, email, and WhatsApp contain text written by people outside your company, and an instruction planted there can steer an agent that has write tools or other servers connected. Keeping the agent away from records it doesn’t need reduces what such content can reach.
How MCP Manager’s Custom Rule Engine Works with HubSpot
MCP Manager sits between your AI client (Claude, ChatGPT, Cursor, or an agent you build) and the HubSpot MCP server. A gateway rule can hand each tools/call to a custom rule engine, an HTTPS webhook you host, on the request leg, the response leg, or both.
What Happens to a HubSpot Tool Call at the Gateway
Your AI client connects to an MCP gateway, which forwards each tool call to HubSpot under the calling user’s brokered identity. When the call or its result reaches the rule’s detection hook, the gateway POSTs the JSON-RPC message plus metadata (userEmail, serverGuid, toolName, direction, requestId) to your webhook. Your webhook returns HTTP 200 with pass, modify, block, or error, and the gateway enforces that verdict before anything reaches the client. If the engine is unreachable or returns error, the rule’s failure mode decides, and for custom engines it defaults to Block.
Why Tool-Level Controls Don’t Reach the Pipeline
HubSpot’s MCP server exposes generic tools: search_crm_objects, get_crm_objects, and query_crm_data read every CRM object type, and manage_crm_objects creates and updates all of them. The 2026-07-28 MCP spec puts the tool name in the Mcp-Name header so gateways can authorize without parsing the body, but that header only says which tool ran. The pipeline ID lives in the arguments and returned records, so pipeline-level policy requires inspecting the JSON-RPC body.
What You Can Block
Because you control the webhook logic, you can act on anything present in the HubSpot payload:
- Deal pipelines: drop or block deals whose
pipelineproperty matches a restricted pipeline ID. - Deal stages: allow early-stage deals but withhold stages where contract terms and final amounts live.
- Properties by name: remove or redact properties such as
amountor a custom “competitor intel” field, using the strip-or-redact recipe. - Records by owner: withhold companies or deals whose
hubspot_owner_idmatches named account owners.
Step-by-Step Guide to Blocking Sensitive HubSpot Deals from AI Agents
The setup covers preparation, the rule engine and its PII layer, and a pilot test. Prerequisites are access to HubSpot’s Development section, an MCP Manager role with the Manage integrations capability, and an engineer who can host a small HTTPS service.
Step 1: Map the Pipelines, Stages, and Properties to Block
List the HubSpot objects and properties that should never reach a model, then collect their internal identifiers:
- Pipeline IDs for restricted pipelines
- Deal stage IDs, not labels, because each pipeline has its own stages and two pipelines can share a label like “Closed won”
- Internal names of restricted properties
- Owner IDs for named-account owners
The server’s get_properties tool returns enumeration values for pipelines and stages. Run it through an admin-only gateway before any rule exists.
A blocklist is simpler when one or two pipelines are sensitive. An allowlist fails closed, so a new pipeline stays out of reach until someone approves it.
Step 2: Connect the HubSpot MCP Server
HubSpot’s server supports OAuth with PKCE but not dynamic client registration. Create an MCP connector in HubSpot under Development, set MCP Manager’s OAuth callback as the redirect URL, and copy the client ID and client secret. Add https://mcp.hubspot.com on MCP Manager’s Servers page and supply both values when detection lands on OAuth client pre-registration.
Each user then approves HubSpot’s consent screen, so calls run as their own identity and every log entry is attributable to a person.
Read the Connect HubSpot guide for the complete connection steps and common pitfalls.
Step 3: Create a Gateway and Trim the Tool Surface
Create a dedicated gateway, for example “HubSpot Sales,” and assign the server. Then use feature provisioning with “Allow if conditions are met” to expose only the tools your team needs. This layer needs no code:
- Read-only CRM: allow the read tools your team uses and leave every
manage_*tool, includingmanage_crm_objects, off the allowlist. - Aggregates: leave
query_crm_dataoff unless your engine can validate its SQL. It returns aggregated values, such as a summed amount per pipeline, that have no record for a rule to inspect. - Attribution reports:
get_campaign_attribution_reportsreturns closed-won deal attribution. Expose it only if those deals are not restricted.
Pin tools by name. Tool annotations such as read-only are unvalidated hints, not a security control. The allowlist also keeps tools HubSpot adds later away from agents until someone reviews them.
Step 4: Build the Response-Leg Rule
The custom rule engine is a single webhook that handles both the request leg (the call heading to HubSpot) and the response leg (the result heading back to the client), receiving the message as a JSON-RPC body plus metadata that includes direction, and answering with pass, modify, block, or error.
Most HubSpot reads take a query or a list of IDs, not a pipeline, so the response rule does the main work. It checks each record’s pipeline, dealstage, and owner against your lists and returns modify with restricted records removed, so a search across all deals still returns the permitted ones. Rules have no per-tool selector, so the engine checks serverGuid and toolName first and passes anything it wasn’t written for.
HubSpot adds cases that a simple pipeline match misses:
- Missing properties: a record only carries the properties the call returned. If
pipelineis absent from a deal, treat the record as unverified and withhold it, or resolve it with a lookup. - Associations: contacts, companies, and notes can reference a restricted deal without carrying its pipeline. With header forwarding on, the engine receives the caller’s credentials and can resolve associations as that user. Test which HubSpot endpoints accept the forwarded token before designing around it.
- Totals and pagination: rewrite counts and paging fields to match the filtered list.
- Unparseable results: block them rather than passing them unchecked.
Capture real payloads first and inspect them in the logs, so the parser follows what HubSpot actually returns.
Step 5: Add a Request-Leg Rule for Writes
If agents keep write access, a request-leg rule inspects manage_crm_objects arguments before the call reaches HubSpot. Creates that set a restricted pipeline are blocked from the arguments alone. Updates carry a record ID, so the engine resolves the record’s pipeline first and blocks when it can’t. HubSpot’s in-client confirmation for writes is a prompt to the user, not a policy boundary.
Step 6: Deploy, Register, and Apply the Rule
The engine needs a public HTTPS endpoint with a public CA certificate, HTTP 200 for every verdict, responses well under the 30-second timeout, and idempotent handling, since failed attempts are retried. Authenticate calls with a static header and allowlist MCP Manager’s static outbound IP.
Open Rule Engines, click Add, and choose the Custom provider. Then open the HubSpot gateway’s Rules tab, add a rule, and select your engine as the detection method, keeping the failure mode at Block.
Registering an engine does not apply it. Until a rule on the gateway’s Rules tab references the engine, HubSpot traffic on that gateway is unfiltered.
Step 7: Layer PII Detection on Top
Personal data also sits in fields no pipeline rule targets, such as notes and conversation threads. Add a PII filtering rule on the same gateway:
- Regex for values with a fixed shape, such as card numbers and national IDs.
- Microsoft Presidio for contextual entities such as names, email addresses, and phone numbers. It is less reliable for names in free-form text, so tune it against your own traffic.
- Guardrail templates such as Amazon Bedrock Guardrails, Google Model Armor, or Lakera Guard, connected as custom rule engines.
Rules run in order within each hook. A block stops processing, while modifications chain, so place the pipeline rule first and the PII rule after it.
Step 8: Test with a Pilot Team, Then Roll Out
Provision the MCP gateway to a team of two or three administrators. Run prompts that should be filtered, such as “summarize every open deal” across a restricted pipeline, and prompts that should pass, such as “list contacts created this week.” Confirm each verdict in the logs, where blocks appear as policy_enforced_abort and rewrites as policy_enforced_mutation. Read result bodies, not only statuses: under the MCP spec, an upstream tool failure returns a normal result with isError: true.
Then widen access. Rules only apply to gateway traffic, so a direct client connection to mcp.hubspot.com bypasses them. Close that path with the MCP Enterprise Lockdown Checklist, which shows how to route all MCP traffic through governed gateways.
Build Your Own or Wait for a Managed Engine
Blocking sensitive Google Drive folders is possible with a managed engine, the Google Drive Folder Blocker, where an admin pastes folder IDs and writes no code. Blocking HubSpot pipelines, stages, and properties currently runs only on a custom engine, which is code your team owns, and three things need an owner:
- Maintenance: HubSpot adds tools and changes scopes, and the people who administer HubSpot are usually not the people who maintain a web service.
- Security review: a self-built engine needs its own test cases and log evidence.
- Operations: with the default failure mode, an engine outage blocks HubSpot calls until the service recovers.
Even if there is no managed HubSpot engine yet, the build does not have to start from scratch. Let a coding agent draft the engine from the MCP Manager docs for agents, register it with the custom rule engine tutorial, and use product support when questions come up. Most of the effort goes into testing against captured payloads. Because the engine is just a detection method on a gateway rule, it can be swapped later.
Common Patterns for Blocking CRM Data from Agents
Most HubSpot rollouts hit one of a few recurring boundaries. The scenarios below show which control fits which situation.
- Forecasting without the strategic accounts pipeline: sales leadership wants agents to summarize pipeline health, but one pipeline holds enterprise terms. A response-leg rule removes deals with that pipeline ID, so searches still return everything else.
- Deals readable, amounts withheld: reps need deal context for call prep, but
amountand a custom contract-terms property must stay out of the model. A redact rule keeps each key and replaces the value with{{REDACTED}}, so the agent knows the value is withheld and doesn’t retry another way. - Marketing analytics with no CRM access: a content team wants campaign, email, and page analytics only. A dedicated gateway allowlists tools such as
read_campaign_data,get_content_analytics_report, andget_marketing_email_analytics. Record search stays off, and no code is needed. - Support and success with contact data in notes: account managers need conversation context, but threads contain pasted email addresses and phone numbers. A Presidio rule set to Replace turns them into typed tags such as
<EMAIL_ADDRESS>. Regex rules cover structured identifiers, since Presidio is less reliable for names in free text.
Govern HubSpot MCP Instead of Blocking It
Switching HubSpot MCP off and letting agents read everything are not the only options. HubSpot’s permissions decide what a person may see, and Sensitive Data removes activity history for everyone. A gateway rule withholds specific pipelines, stages, and properties from agents only, with every decision logged.
If a few deal pipelines are holding back your HubSpot MCP rollout, book a demo with MCP Manager and scope the rule that unblocks it.
FAQ
Can MCP Manager block specific HubSpot deal pipelines from AI agents?
Yes. A response-leg custom rule engine removes deals from restricted pipelines before results reach the model, and a request-leg rule can block writes to them.
Should I still use HubSpot’s Sensitive Data setting?
Yes, if you store regulated data in Sensitive Data properties. The setting protects designated properties and blocks activities through MCP for the whole account. A gateway rule is an agent-specific layer on top of it, not a replacement.
Does a gateway rule change anyone’s access in HubSpot?
No. The rule only changes what agents receive through the gateway. HubSpot permissions and the HubSpot UI stay untouched.
Can I block HubSpot write operations without a custom rule?
Yes. Leave manage_crm_objects and the other manage_* tools off the gateway’s allowlist in feature provisioning. A direct call to a disallowed tool is blocked and logged as gateway_feature_blocked.
What happens if my custom rule endpoint goes down?
Rules that use a custom engine fail closed by default. If the endpoint is unreachable, too slow, or returns invalid data, the call is blocked. The failure mode can be set to Allow, but Block is the safer setting for a data boundary.
Can I use MCP Manager’s PII detection on HubSpot data?
Yes. Regex, Presidio, and guardrail templates such as Amazon Bedrock run on HubSpot tool results, including free-text notes and conversations.
Does MCP Manager log which HubSpot requests were blocked and why?
Yes. Every rule run is logged with the engine, its verdict, and the comment your engine returned, alongside the user and tool. Logs can be exported to a SIEM over OpenTelemetry, or to Splunk through its HTTP Event Collector.
