Secure HubSpot access for AI agents

Through HubSpot, agents can read and manage CRM objects (contacts, companies, deals, tickets), query campaign and attribution data, create and analyze marketing emails, pull content analytics, manage landing pages, and search conversations – every call runs through your policies and is logged for audit.

Server URL: https://mcp.hubspot.com

Credential modes

HubSpot supports bring your own app only. It does not support dynamic client registration, so your organization registers its own app in a HubSpot developer account and supplies the client ID and secret. See Credential modes for how the modes compare.

Before you begin

• A HubSpot developer account, at developers.hubspot.com, that can create apps.
• A HubSpot account with the CRM and marketing permissions your agents need.
• Administrator access to your Agent Authority workspace, to add the resource.

Setup moves between two consoles. You copy a redirect URI in the Agent Authority console, register an app in HubSpot, then return to the console and paste the credentials. Keep both tabs open as you work.

Setup

1. Copy the redirect URI

In the Agent Authority console, go to Resources → Add Resource and select HubSpot. HubSpot is bring-your-own-app only, so the credentials form opens as soon as you select it, with no mode to pick.

Copy the Redirect URI shown on the form. It includes your tenant's region, so copy it rather than typing it. It takes the form https://oauth.aisecurity.services.<region>.connect.secureauth.com/auth/callback.

Leave this page open. You come back to it in step 3.

2. Register a public app in HubSpot

The gateway needs a HubSpot app with a client ID and secret, which is HubSpot's public app. HubSpot now files these under Legacy apps in the developer account, so the "legacy" label is expected and is the right place to be.

In your HubSpot developer account, go to Development → Legacy apps, then create an app or open an existing one and go to its Auth tab:

• Under Redirect URLs, add the Redirect URI from the form in the Agent Authority console, using the Copy button next to it.
• Under Scopes, add the scopes your organization wants agents to use. See Required scopes.
• Copy the Client ID and Client Secret from the Auth tab.

3. Finish in the console

Back on the HubSpot form in the Agent Authority console, paste the Client ID and Client Secret. Leave Token Endpoint Authentication on Auto-detect. Then click Add.

The gateway sends you to HubSpot to sign in and authorize the app. HubSpot asks which account to connect, so pick the one your agents should reach, review the requested access, and approve. You return to the console with your HubSpot account connected.

Verify the connection

The gateway syncs the HubSpot tools automatically. To check the connection end to end, ask your agent to run a request:

Get my HubSpot user details

If your user, team, and hub details come back, the connection is working.

How users connect

Access is per user. Each additional user connects their own HubSpot account the first time their agent calls a HubSpot tool: the gateway returns a sign-in link, the user authorizes once, and the tools work from then on. Go to Connections to manage linked accounts.

Each user picks the HubSpot account to connect during sign-in, and HubSpot's own account permissions control what they can reach. The gateway does not widen access beyond what the authenticated user could already do in HubSpot.

HubSpot serves the OAuth authorization and token endpoints from the MCP host itself, at https://mcp.hubspot.com/oauth/authorize/user and https://mcp.hubspot.com/oauth/v3/token.

Available tools

manage_landing_page is the tool to watch. It carries both read and write actions behind one name, so a policy that denies it also removes its read actions.

Required scopes

The catalog entry requests no scope list, so the scopes you select on the app's Auth tab are what the connection gets. This is the one setting on the HubSpot side that decides how much your agents can reach, so choose it deliberately.

Match the scopes to the tools you intend to allow:

• CRM object read scopes, for example crm.objects.contacts.read, crm.objects.companies.read, and crm.objects.deals.read, cover get_crm_objects, search_crm_objects, query_crm_data, get_properties, and search_properties.
• The matching CRM write scopes, for example crm.objects.contacts.write, are needed for manage_crm_objects.
• Marketing scopes cover the campaign, marketing email, landing page, and content analytics tools.

Leaving a scope out is a valid way to keep a capability away from agents: the tool still appears in the catalog, and the call fails at run time. To block a tool cleanly instead, deny it in a policy. See the examples below.

Policy examples

Rules are evaluated top to bottom and the first match wins. Allow rules on their own restrict nothing, because your org starts with a seeded Allow all rule and anything your allows do not cover falls through to it. A restrictive recipe needs a catch-all deny scoped to this resource, ordered below the allows. New rules are inserted at the top of the list, so create them in reverse order or drag them into place. See Policies.

• Read-only access. Deny manage_crm_objects, manage_campaign_objects, manage_marketing_email, manage_landing_page, and submit_feedback. Those are every write HubSpot exposes here, leaving the get_*, search_*, query_crm_data, and read_campaign_data reads.
• CRM without marketing. Allow get_crm_objects, search_crm_objects, query_crm_data, get_properties, search_properties, search_owners, get_user_details, and tool_guidance, then deny * below them.
• Block changes to published marketing assets. Deny manage_landing_page, manage_marketing_email, and manage_campaign_objects, which leaves the analytics and reporting tools available.
• No feedback to HubSpot. Deny submit_feedback, which sends connector feedback to HubSpot.

Next steps

• Create a policy – start from the read-only pattern in Policy examples above.
• Connections – manage the HubSpot accounts your users have linked.