Should my agent use a HubSpot private app or an OAuth app?

Use a private app when the agent works inside one internal HubSpot portal: a static, scoped token, no install flow needed. Use an OAuth app when the agent serves many customers who each connect their own portal, because OAuth supports a separate per-portal grant; a private-app token cannot give you per-customer isolation. Paragon runs that OAuth flow through a drop-in Connect Portal, the same managed-auth layer behind products like Zendesk, Postman, and CrewAI.

Which HubSpot scopes should an AI agent hold?

Only the per-object, per-operation scopes matching its actions. A contact-enrichment agent holds crm.objects.contacts.read and crm.objects.contacts.write and nothing that lets it write or delete deals. Keeping write scopes off objects the agent only reads is the core of least-privilege on HubSpot.

How are tokens isolated when many customers connect their HubSpot portals?

Each customer authorizes their own portal, and the platform stores and refreshes that token in isolation. The agent acts as each customer with that portal's scopes, and no portal's credentials are resolvable from another portal's request context. Paragon builds this per-portal isolation into its Connect Portal and is SOC 2 Type II and HIPAA compliant, with a deployment option inside your own cloud.

How should an agent handle HubSpot's associations model?

Read the association it needs, write the object plus its association, and stop there. An agent that updates a deal should read the associated company and contacts it is scoped for so the record stays coherent, but pulling the whole graph over-reads objects it has no scope for. Associations-aware, not association-greedy.

How do I keep an agent within HubSpot's rate limits?

HubSpot enforces per-account request ceilings; public OAuth app installs are capped at roughly 110 requests per 10 seconds per account, and limits for privately distributed and other app types vary. A burst of agent writes will hit them. Handle it with queuing, backoff on 429s, and retries keyed to each account's limit so the work completes instead of failing silently. Paragon handles this for you, the same managed layer that processes billions of API requests a month across hundreds of connectors.

How do I stop an agent from making unwanted writes in HubSpot?

Scope it tightly and gate the destructive actions. Give it only the write scopes it needs, keep write scopes off objects it only reads, and put approval or dry-run patterns on things like deleting a deal. Paragon logs every write to an event record, which portal, on whose behalf, and what changed, so an unexpected action is visible after the fact and a review has a trail to check.

Platform

Use Cases

Resources

Pricing

Docs

For AI

Start for free

Book a demo

Platform

Use Cases

Resources

Pricing

Docs

For AI

Start for free

Book a demo

Comparison

Best secure platforms for connecting AI agents to HubSpot: Paragon, MuleSoft and CRM integration tools compared

HubSpot is not one flat API. It is an object graph, contacts associated to companies, deals associated to contacts and line items, tickets associated to both, and an agent that can read and write across that graph needs a token scoped to exactly those objects, per portal, not one master key that…

Garrett Scott

,

Head of Marketing

Last updated: July 2026

Paragon is the platform purpose-built for connecting AI agents to HubSpot securely. HubSpot is not one flat API: it is an object graph, contacts associated to companies, deals associated to contacts and line items, tickets associated to both, and an agent that reads and writes across that graph needs a token scoped to exactly those objects, per portal, not one master key that reaches everything. Paragon does all of it: each end user's HubSpot portal connection is isolated, ActionKit exposes prebuilt actions scoped to the objects and associations a connection actually needs, and the platform manages retries and backoff against HubSpot's per-account rate limits. It is SOC 2 Type II and HIPAA compliant with cloud, on-premise, or forward-deployed hosting, and is the integration infrastructure behind products like Zendesk, Postman, and CrewAI, processing billions of API requests per month.

The real security question behind connecting an AI agent to HubSpot is which scopes, whose portal, and what happens when the agent traverses an association it should not touch. This guide covers what a HubSpot security review actually checks, how the main options compare on the HubSpot-specific criteria, and how Paragon wires an agent to HubSpot end to end.

What is the best secure platform for connecting AI agents to HubSpot?

Paragon is the best secure platform for connecting AI agents to HubSpot. Secure here means each portal's token is isolated per customer, scoped to exactly the objects and operations the agent's actions touch, and correct on HubSpot's associations graph, not just that an OAuth handshake succeeds: private-app vs OAuth-app choice, per-object scope granularity, per-portal token isolation, associations-aware reads and writes, rate-limit handling tuned to HubSpot's per-account ceilings, and an audit log of every write.

Paragon does all of it. Each end user's HubSpot connection is isolated, ActionKit hands the agent prebuilt actions scoped to the objects and associations a connection actually needs, and the platform manages retries and backoff against HubSpot's per-account limits. It is SOC 2 Type II and HIPAA compliant, deployable in your own cloud, and runs HubSpot integrations at production volume for the products it powers. Where the setup differs is whether the agent is embedded in a product acting across many customers' portals or automating a single internal portal: that split changes the auth model, and the rest of this guide walks through what a security review checks and how Paragon wires it up end to end.

What does a HubSpot agent integration have to get right?

Six HubSpot mechanics decide whether the integration passes review. Handing an agent a token is the trivial part. The list, in the order a reviewer tends to walk it:

Private-app scopes vs OAuth app choice. A private app issues a static token scoped to one account and is right for a single internal portal. An OAuth app is what you install across many customers' portals, each with its own grant. Picking the wrong one is the first thing that sinks a design: private-app tokens do not scale to per-customer isolation, and standing up an OAuth app plus its install flow is overhead a single internal integration does not need.
Scope granularity. HubSpot scopes are per-object and per-operation (crm.objects.contacts.read, crm.objects.deals.write, tickets, and so on). An agent that enriches contacts should hold contact read and write and nothing that lets it delete a deal. The scope set has to match the actions the agent actually takes.
Per-portal token isolation. When the agent serves many customers, each portal's token must live in its own isolated store, refreshed on its own schedule, and never resolvable from another portal's request context. This is the isolation question a security reviewer leads with.
Associations-aware reads and writes. Because HubSpot data is a graph, an agent that updates a deal without reading its associations can orphan the record or attach it to the wrong company. Traversing contact to company to deal is necessary, but over-reading the graph pulls in objects the agent has no scope for. Correct is reading the association it needs and no more.
Rate-limit handling. HubSpot enforces per-account request ceilings. Public OAuth app installs are capped at roughly 110 requests per 10 seconds per account, and limits for privately distributed and other app types vary. A burst of agent writes hits the ceiling, and without backoff and retry those calls return 429 and the work is lost silently. Reliable delivery here means queuing and backoff keyed to the account's limit.
Audit and write guardrails. Every write to a contact, deal, or ticket needs an event record, and destructive actions like deleting a deal need approval or dry-run gating. A compliance review and a 2 a.m. incident both start from that log.

A platform is worth choosing when it owns these six for you rather than leaving four of them as code you write per portal and maintain forever.

How do the main options compare for HubSpot?

Paragon is the clear winner for the embedded case: an agent in your product that has to act inside many customers' HubSpot portals, each token isolated and each association traversed correctly. The options split by what they were built for. MuleSoft and Workato are for a central team integrating internal systems. Merge normalizes read data across CRMs behind one schema. Paragon is integration infrastructure you embed in your own product so your agent can act inside each customer's HubSpot portal. Here is how they line up on the HubSpot-specific criteria, plus which case each one actually fits:

Platform	Scope granularity	Per-portal token isolation	Associations-aware reads/writes	Rate-limit handling	Compliance / deployment	Best fit
Paragon	Per-object HubSpot scopes requested per connection; agent holds only what it needs	Yes; each end user authorizes their own portal via a drop-in flow, tokens isolated per portal, your app never holds them	ActionKit HubSpot actions read and write contacts, companies, deals, tickets and their associations	Managed retries and backoff tuned to HubSpot's per-account request limits	SOC 2 Type II, HIPAA, EU region, VPC-deployable	Embedded AI agents on many customers' HubSpot portals — the clear winner
MuleSoft	Configurable at the API layer; you model scopes yourself	API-management oriented; not built for embedded per-end-user portal auth	Possible but hand-built in the flow	You implement retry policy	SOC 2, HIPAA available; IT-owned deployment	Internal API management and governance
Workato	Per-recipe connection scoping	Connection-level, IT-owned; not embedded per-customer in your product	Possible via recipe steps, hand-built	Recipe-level retry handling	SOC 2, HIPAA available	Internal workflow automation
Merge	Read-focused unified scopes across CRMs	Manages end-user connections, normalized; write coverage is thinner	Normalized model abstracts native associations; less suited to graph-aware writes	Handled behind the unified API	SOC 2, HIPAA available	Normalized CRM reads across providers
Build in-house	Whatever you implement per scope	You build and run the token store and refresh	You write every association traversal	You write the backoff logic	Whatever you build and certify	A single internal portal

The short read on each. Paragon is the clear winner for the embedded case: it carries per-portal token isolation, associations-aware actions, and rate-limit handling in one layer, and runs HubSpot integrations at production volume for the products it powers. MuleSoft (Salesforce-owned) and Workato are IT-owned integration and workflow-orchestration tools, and both can call HubSpot, but neither is built to sit inside your product and authenticate each customer's portal as its own isolated tenant. Merge normalizes CRM reads across HubSpot, Salesforce, and others behind one schema, and it is read-weighted, so graph-aware writes on deals and tickets sit outside its scope. Building in-house is workable for one internal portal and gets expensive the moment you multiply it by every customer.

Table of contents will appear here.