Why I Don't Give Claude Code Write Access to HubSpot (or any CRM)

Non-deterministic workflows for CRM writes are a hard no for me. Here's the split I run instead.

There's been a shift lately towards moving outbound GTM workflows out of Clay and fully into Claude Code. Part of this is Clay moving towards a usage-based pricing model where you're charged per action (Clay docs).

Which can be rather expensive especially when the actions add up.

I’ll admit I’ve been migrating out of Clay too for some of the workflows I’ve been building. But not all of them. Specifically, not the ones that touch HubSpot.

Here’s why.

Where HubSpot fits in my GTM workflows

Two things I use HubSpot for:

1. Net-new checks. Before reaching out to a company, I want to know:

→ Is the company already in our CRM?

→ If yes, has there been any BD or AE activity within the last X months?

→ Are they an existing customer?

This tells me whether the company is safe to put into my outbound motion.

2. Writing company + prospect data into the CRM.

Once a prospect is in outbound, the company and contact records get written into HubSpot, along with the right tags and properties that trigger downstream HubSpot workflows.

Both workflows touch HubSpot but only one needs write access.

Why I don’t give Claude Code write access to HubSpot

If you’re running Claude Code at scale (I don’t mean outbound for 10 or 20 companies, I mean over 1,000 companies) hallucinations become very noticeable. This is even with guardrails.

I’ve had Claude Code hallucinate URLs in agentic workflows (using fake URLs that but didn’t exist). For a research step, that could be somewhat liveable.

For a CRM write, it’s not. You’re not sure of the data integrity, and once bad data is in the CRM, it triggers downstream workflows that weren’t supposed to fire.

Take a look at this hallucination example below.

Then there’s the other risk: API keys.

The Axios npm package (~100M weekly downloads) was compromised on March 31, 2026. Two malicious versions were published using the lead maintainer’s hijacked npm account, injecting a fake dependency that dropped a cross-platform RAT on macOS, Windows, and Linux (CSA Singapore advisory).

Even though the exposure window was only ~3 hours, but anyone who ran npm install in that window had to assume every credential on the machine was compromised. If your Claude Code agent has a HubSpot API key sitting in an .env file or a config somewhere, it’s now part of the attack surface for any supply chain compromise of any package the agent uses.

This scares me. Honestly with all the npm packages that I’m using within Claude Code, it feels like it’s a matter of time before one such package gets compromised.

So that’s why I am mitigating my downside. For any service that’s mission-critical, I don’t give Claude Code write access. Only Read-only access.

My approach: a two-prong workflow

I split my GTM workflows into agentic work (via Claude Code) and deterministic work (via Clay).

Claude Code → Push to Clay webhook → Clay writes to CRM

Here’s a recent example for webinar prospecting:

Claude Code (agentic side):

→ Finds companies and people organizing webinars

→ Filters by HubSpot net-new (read-only access)

→ Filters them according to my ICP rules

→ Enriches relevant prospects using Apollo.io

→ Crafts an opening line and body paragraph contextualized to the prospect’s job title and role

→ Pushes to Instantly

→ Pushes to a Clay webhook

Clay (deterministic side):

→ Writes the prospect and company into HubSpot

→ Adds the right notes for the AE to action

Claude Code does the messy, judgment-heavy work upstream. Clay handles the deterministic CRM writes downstream. The HubSpot API key never touches the agentic side of the pipeline.

The takeaway

Deterministic workflows running in tight, contained environments with scoped credentials are structurally safer than agentic workflows holding long-lived API keys with write access to your CRM.

This isn’t a Claude Code problem. Claude Code is doing exactly what it’s supposed to. It’s an architectural choice about where you draw the line between agentic and deterministic — and for me, that line runs right at the CRM.