What Can AI Agents Do in Your Ad Accounts and CRM?

"Agentic marketing" is on every martech deck this quarter, and "connect in one click" is usually a couple of slides later. Neither slide says what the click grants.

So I went looking for the answer where it actually lives, which is the authorization server rather than the deck. One command against HubSpot’s, the way you would check a DNS record before believing a migration plan.

curl https://mcp.hubspot.com/.well-known/oauth-authorization-server

What came back had no registration_endpoint, no client_id_metadata_document_supported, and "scopes_supported": []. In plain terms: an agent cannot register itself with HubSpot, and HubSpot’s metadata will not tell you in advance what permissions it is about to hand over. That is not a criticism of HubSpot. It is the shape of the thing being sold, and it took one command to find.

I should say up front what this post is and is not. I have never connected an AI agent to a client’s ad account or CRM, and I would not have written this if I had. The interesting part is what the documentation commits to, not what one integration happened to do on a Tuesday. Everything below comes from vendor documentation I opened, GitHub issues I read, registry and vulnerability databases I queried, and commands I ran, all on August 21, 2026. Where a source contradicted my notes, the source won and I say so.

The one thing I do have first-hand is the other side of the table. This site registers agent tools in production. I wrote the permission boundaries on them myself, and that is the part of this story I did not expect to be relevant.

Quick answer

As of August 21, 2026, Google’s Ads MCP server is strictly read-only (three tools, no writes) while Meta’s opened to any developer’s app on July 16, 2026 documenting campaign, ad set, ad and custom audience creation. HubSpot and Salesforce both write to CRM records and both inherit the authorising user’s existing permissions. The dangerous part is not the tool list, it is the grant: Google’s read-only server still requires https://www.googleapis.com/auth/adwords, the Google Ads API’s only OAuth scope, which is full management. What I do before authorising anything is read the scope the consent screen requests and ignore the tool list entirely, because the tool list is the vendor’s promise and the scope is the actual permission.

Everything in this post was verified at its primary source on August 21, 2026. Treat it as a snapshot with a shelf life measured in weeks. A Google maintainer has already said write tools are coming, which flips the most important column in the table below.

Which of these servers can actually change something?

Here is the matrix I could not find published anywhere. Every cell was read off a vendor page or an API response on August 21, 2026.

Platform	Server	Read	Write	Tools documented	Client registration	Doc date	Published CVE
Google Ads	`googleads/google-ads-mcp`, self-hosted	Yes	No	3	Your own OAuth client	Updated Aug 19, 2026	None in NVD
Meta Ads	`mcp.facebook.com/ads`, Meta-hosted	Yes	Yes	28 on the ad-creation page alone	Facebook Login or bearer token	Opened Jul 16, 2026	None for Meta’s own
HubSpot	`mcp.hubspot.com`, HubSpot-hosted	Yes	Yes	Not published as a count	Neither DCR nor CIMD	GA Apr 13, 2026	None found
Salesforce	Salesforce-hosted MCP servers	Yes	Yes	Defined by your org	External Client App, pre-registered	GA Apr 29, 2026	None found
Microsoft Advertising	`partner.api.bingads.microsoft.com`	Not documented	Not documented	Not published	AAD app registration	ms.date Jul 22, 2026	None found
`pipeboard-co/meta-ads-mcp`, third party	Community package	Yes	Yes	Not audited	Operator-supplied token	—	CVE-2026-48039, CVSS 9.1

Two columns deserve a warning. "Published CVE" means I could not find one, not that none exists: a vendor-hosted server is patched silently and would never produce a CVE at all, so an empty cell there is close to meaningless for the four hosted rows. And "Tools documented" is what the vendor chose to publish, which for HubSpot and Salesforce is not a number.

The last row is a different animal from the five above it, and telling them apart is most of the job.

What can an AI agent actually do in Google Ads?

Nothing that costs money. Google’s own page for the Ads MCP server, last updated August 19, 2026, states it plainly: "This implementation is strictly read-only. It cannot modify bids, pause campaigns, or create new assets." The page lists mode as "Read-only (current release)" and documents exactly three tools: list_accessible_customers, search, and get_resource_metadata.

That is a real constraint, honestly documented, and it will not last. On June 4, 2026, in issue #84 on the googleads/google-ads-mcp repository, a maintainer wrote: "We already have plans to add write access soon; each individual write tool will be configurable with the YAML file introduced in #82. Because of this, we won’t accept PRs adding write features. I won’t close this issue now to leave room for further discussion if needed." The proposal’s author closed it themselves half an hour later. So the read-only column in that matrix is a release note, not a policy.

Then there is the state of the thing. The repository has 876 stars and was created on October 3, 2025. It has zero releases and zero tags, and pyproject.toml on main still reads version = "0.0.1". Issue #107, opened August 13, 2026, is titled "Can we publish releases here?" and is open. Issue #102, opened August 10, 2026, reports that search, one of the three tools, is unreachable because customer IDs are digit-only strings that MCP clients serialise as JSON numbers, which the generated Pydantic model rejects: "No input both passes validation and is accepted by the API, so the tool is effectively unreachable." Also open.

I want to be careful about what that does and does not prove. It is a sample of the loudest users, not a defect rate. But if you are evaluating this for a client team, "the read tool does not currently work" is a different procurement conversation than "read-only for now."

The genuinely uncomfortable fact is elsewhere, and it is in the README rather than the docs page. To run this server you must supply credentials carrying https://www.googleapis.com/auth/adwords. Google’s OAuth guide for the Ads API says: "The scope for the Google Ads API is: https://www.googleapis.com/auth/adwords." One scope. There is no read-only variant. So the read-only server holds a token that can mutate every campaign in every account it can see. The restriction lives in the server’s Python, not in the grant, and the grant is what survives if the token leaks.

What can an AI agent actually do in Meta Ads?

Considerably more, and this is where I have to correct my own notes.

Meta’s announcement on July 16, 2026 says any app can now connect to the ads MCP server, and documents "Create, edit, and delete campaigns, ad sets, and ads" along with "Create, update, and delete custom audiences." My working brief said Meta shipped this with no documented safety guardrails. That was wrong, and I found out by opening the tool reference instead of the launch post.

Meta’s ad creation and management page states: "Write tools create entities in a paused state; your AI client asks for confirmation before activation." Each write tool repeats it: ads_create_campaign is described as "Create a new ad campaign (paused)," and the same parenthesis appears on ads_create_ad_set and ads_create_ad. A paused-creation default is real, it is documented, and anyone claiming otherwise (including me, two days ago) has read the blog post and not the docs.

Now read the same page for what it costs you. There are 28 tools on that page alone. One of them is ads_activate_entity: "Change a paused campaign, ad set, or ad to active — starts spending budget." The safety net is a default that the agent has a tool to remove, and the confirmation is explicitly the client’s job, not the server’s. Meta’s sentence says "your AI client asks for confirmation." Nothing in the protocol compels a client to ask. If you swap Claude Desktop for an unattended orchestrator you wrote yourself, you have kept the write tools and dropped the guardrail, and neither Meta nor the spec will stop you.

The second thing the tool reference tells you is that the launch post’s deletion claim has no dedicated tool behind it. There is no tool on that page that deletes a campaign, an ad set, or an ad. ads_update_entity updates fields, and the only delete tool is ads_delete_custom_audience. Whether deletion runs through that update tool’s status field is not documented either way. Both statements are Meta’s own. When a blog post and a tool reference disagree, the reference is the one your agent will actually call.

What can an agent change in HubSpot and Salesforce?

Both write, and both handle permissions better than the ad platforms do, which is the opposite of what I expected before I read them.

HubSpot’s remote MCP server went generally available on April 13, 2026. Its changelog splits the surface explicitly: it reads CRM records, marketing and content objects, and activities, and it creates and updates contacts, companies, deals, tickets, line items and products, plus calls, meetings, notes, tasks and emails. The permission model is the sentence that matters: "All actions respect your existing HubSpot user permissions — users can only access or modify records they already have permission to view or edit."

Salesforce’s hosted MCP servers reached GA on April 29, 2026 with the same posture, stated harder: "Your existing permissions automatically apply — CRUD, FLS, sharing rules, and all the other controls you’ve already mastered," and "Every transaction runs as the authenticated user, without anonymous service accounts or a new security model to learn." Setup is an External Client App with mcp_api and refresh_token scopes, and Salesforce is explicit that "A new OAuth scope provides access to MCP, but not our existing REST APIs."

Sit with that last clause, because it is the single best design decision on this whole board. Salesforce minted a scope that grants MCP and only MCP. Google reused a scope that grants everything. Same protocol, opposite answers to the same question, and you can only tell them apart by reading the consent screen.

Two more limits worth knowing, both from practitioners rather than vendors. On Salesforce, Agentforce will silently refuse to call a third-party MCP tool whose description has changed since you registered it. An answer on the Salesforce Stack Exchange thread from June 8, 2026 explains the mechanism: Agentforce saves a copy of the tool description at activation, compares it at runtime, and "should any of the content be different, the tool is flagged as having a description_mismatch and excluded from the list of available tools. This is done to prevent rug-pull attacks." That is a deliberate defence against a server that ships one description to get approved and another to get used. It is also, in practice, a tool that stops working with no error your marketing team will ever see.

On HubSpot’s CMS, the boundary is architectural rather than security-driven. Issue #6 on HubSpot/mcp-server, opened May 22, 2026 and still open, works out the actual rule: MCP can edit a module’s content when the module is hard-coded into the template as {% module "instance_name" %}, because the instance name is addressable, and cannot when the module was drag-and-dropped into a dnd_area or widget_container, because those instances get auto-generated numeric IDs at placement time. Practically: your coded landing pages are agent-editable and the page marketing built in the drag-and-drop editor is not. That distinction is invisible from the marketing side of the tool, which is exactly the kind of seam I keep meeting in how to plan a martech stack before buying tools.

What does connecting an agent actually grant?

This is the question the vendor deck skipped, and it has a different answer than the tool list on every single row.

Platform	Scope or permission requested	What the tool surface exposes	The gap
Google Ads	`https://www.googleapis.com/auth/adwords`, the API’s only scope	3 read-only tools	Full mutate access, held but unused
Microsoft Advertising	`https://ads.microsoft.com/msads.manage`	No tool list published in the setup guide	A management scope for an undisclosed surface
Meta Ads	`ads_mcp_management`, `ads_read`, `ads_management`, `catalog_management`, `business_management`, `pages_show_list`, `instagram_basic`	28 ad tools, paused by default	A general Marketing API token; anything holding it can call the Graph API directly and skip the pause
HubSpot	Not advertised, `"scopes_supported": []`	Read plus create and update on core CRM objects	The metadata document does not enumerate it: read the consent screen
Salesforce	`mcp_api` and `refresh_token`	Flows, Apex actions, named queries, sObject reads	MCP only, and no access to the REST APIs

The Microsoft row is the one I would put on a slide. Microsoft’s setup guide, dated July 22, 2026, tells you to configure the scope https://ads.microsoft.com/msads.manage offline_access and points at an endpoint carrying ?toolSetNames=OpenBeta. The guide documents no tool list at all, and its two example prompts are both reads. So you are asked to grant a management scope to a surface that is not published. It may be entirely read-only today. The token does not care.

The Meta row is the sharper one operationally. The paused-creation default lives in Meta’s MCP tooling. The permissions you approve are ads_management and friends, ordinary Marketing API permissions. Any process holding that access token can call the Graph API directly, where no MCP tool descriptions and no paused defaults apply. The guardrail is at the MCP layer; the grant is at the API layer underneath it. That is the whole answer to "what does connecting one actually grant," and it is why I stopped reading tool lists first.

Why can my AI client connect to HubSpot but my automation platform cannot?

Because the two clients authenticate to HubSpot’s token endpoint differently, and only one of them does it the way HubSpot accepts.

The MCP specification’s current revision, dated July 28, 2026, sets a priority order for client registration: use pre-registered credentials if you have them; otherwise use Client ID Metadata Documents if the authorization server advertises client_id_metadata_document_supported; otherwise use Dynamic Client Registration if it advertises a registration_endpoint; and otherwise, "Prompt the user to enter the client information if no other option is available."

HubSpot’s metadata document, which I fetched this morning, advertises neither. So every client lands on step four. A desktop AI client handles step four gracefully: it shows you a form, you paste in a client ID and secret from an app you created yourself, and it works. An automation platform whose MCP credential was built around the first three steps does not.

That is not a hypothesis. On July 28, 2026, one reporter filed the same bug against n8n three times in under seven minutes (#35093, #35094 and #35096, the first two withdrawn within seconds as duplicates), all titled "MCP OAuth2 API credential cannot authenticate with HubSpot Remote MCP Server." The reporter did the work I would have done: replaced the token URL with a webhook to capture the outgoing request, and diffed it against MCP Inspector, which authenticates against the same HubSpot application successfully. HubSpot returns {"status": "BAD_CLIENT_SECRET", "message": "missing or invalid client secret", "error": "invalid_client"}. The cause is in the metadata I curled: HubSpot lists "token_endpoint_auth_methods_supported": ["client_secret_post"] and nothing else, so the credentials must arrive in the request body, and n8n was sending an Authorization: Basic header. The working client also sends resource=https://mcp.hubspot.com/, which n8n had no field for.

The MCP spec revision is background here, not the subject, but it does explain the direction of travel: the July 28 revision deprecates Dynamic Client Registration in favour of Client ID Metadata Documents, keeping DCR "available for backwards compatibility with authorization servers that do not support Client ID Metadata Documents," under a minimum twelve-month deprecation window. HubSpot supports neither the deprecated mechanism nor its replacement. If you are picking the tool that will drive these connections, that is a live selection criterion, in the same family as the integration questions in CDP vs. CRM vs. marketing automation.

What did registering agent tools on my own site teach me about this?

More than reading the specs did, because writing the permission boundary is a different act from reading someone else’s.

This site registers four browser tools for agents, two of them in AgentTools.jsx. They are read-only and same-origin: one lists published content, one returns the Markdown rendition of a page. That is the write side of a question I took the read side of in whether AI engines can read your site at all. That is a deliberately small surface. Where I use agents in content work the interesting question is workflow rather than permissions, and I wrote that up separately in AI agents for SEO content. Four decisions in this file map onto everything above.

The path allowlist. read_page_as_markdown takes a path argument and validates it against /^\/(articles|resources|ressources)\/[a-z0-9-]+$/ before it fetches anything. Without that regex the tool is a same-origin fetch proxy for whatever path an agent can be talked into passing. Tool arguments are attacker-influenced input: the model on the other end has read a web page, and the web page may have had opinions. I verified it rejects external URLs and ../ traversal. That check exists because the alternative is a tool whose real capability is much larger than its description, which is exactly the Google Ads scope problem written small.

Revocation is the caller’s job, not the platform’s. The API has no unregisterTool() method; Chrome’s "Unregister tools" section removes a tool by AbortSignal instead, so you pass a signal when you register and fire it yourself on cleanup. Get it wrong and capability you believe you removed is still live on a page that no longer shows it. That is step eight of the checklist above, written small. Every grant in this post has the same property: someone has to own turning it off, and no consent screen will ever remind them.

The correct API is document.modelContext.registerTool(). A large share of the write-ups I read while building this quote navigator.modelContext.provideContext() instead, including tools that audit sites for agent-readiness. That shape is simply wrong, and it is a useful tell: a page repeating it has not run the code. The same tell works on the ad platforms. Anything describing Meta’s server without the paused-creation default is quoting the launch post.

Which brings me to the analogy I actually trust here, and it is not a technology one. On a financial services program, the work that made the difference was getting data architects, DBAs, developers and external vendors to agree on the shape of the data before any of it moved. Not a tool decision. A definition-of-done decision, made by the people who would own the consequences, before the first byte crossed a boundary. Granting an agent write scope to a CRM is the same class of decision wearing newer clothes, and it is being made in most organisations by whoever clicked Approve on a consent screen.

A checklist before you authorise any agent integration

Run this in order. Each step has a failure mode I can point at.

Read the consent screen, not the tool list. Write down the exact scope string before approving. Fails when the tool list and the scope disagree: Google’s server is read-only and asks for https://www.googleapis.com/auth/adwords, the Ads API’s only scope, which is full management. The tool list is a promise. The scope is a permission.
Establish who publishes the server. Vendor-hosted, vendor-published open source, or a community package? Fails silently because the names collide: Meta’s server is mcp.facebook.com/ads, and pipeboard-co/meta-ads-mcp is an unaffiliated package that carried CVE-2026-48039. Same words, different blast radius.
Check whose credentials the server runs as. HubSpot and Salesforce run every transaction as the authenticated user and inherit that user’s permissions, so a restricted CRM user is a real control. A self-hosted server running on an operator’s environment variable is not, and that is the shape CVE-2026-48039 exploited.
Fetch the authorization server metadata before you commit to a client. One curl on /.well-known/oauth-authorization-server. Fails when you standardise on an automation platform first and discover the wall second. HubSpot advertises no registration_endpoint, no client_id_metadata_document_supported and "scopes_supported": [], and the token endpoint accepts credentials only in the request body, which is where an automation platform sending an Authorization: Basic header fails.
Look up the namespace in the official MCP registry. Fails on a false sense of vetting: the registry’s own design principles state "No built-in ranking, curation, or quality judgments" and delegate source-code security to npm and PyPI. A listing is a name claim, not an audit.
Ask where the guardrail is enforced, server or client. Meta’s write tools create entities paused and "your AI client asks for confirmation before activation." Fails the day you replace the client with your own orchestrator and keep the write scope.
Test against a sandbox or a deliberately restricted user first. Fails in ways nobody warns you about: Agentforce excludes third-party tools whose description changed with a description_mismatch and no user-visible error, and HubSpot’s MCP cannot edit modules placed in a dnd_area at all.
Write down the revocation path and the expiry, and put a date on the review. Fails by omission. Every fact in this post has a doc date inside the last five months, and a Google maintainer has already announced writes are coming. A permission decision made in August 2026 on August 2026 evidence needs a re-read in the autumn.

Steps one through three are the ones I would not skip under deadline pressure. If you want the wider version of this conversation, the interactive martech stack assessment covers the surrounding architecture, and the martech glossary defines the vocabulary these vendor decks assume you already share.

Is any of this actually dangerous?

Once, verifiably, and not where the marketing conversation is looking.

CVE-2026-48039 was published on August 7, 2026 with a CVSS 3.1 base score of 9.1, critical, classified CWE-287. It affects pipeboard-co/meta-ads-mcp before version 1.0.109, a community package, not Meta’s hosted server. NVD’s description is worth reading closely, because the failure chain is ordinary rather than exotic: the auth middleware "unconditionally forwards unauthenticated Streamable HTTP requests to downstream MCP tool handlers without issuing a 401 response, allowing any network-reachable caller to invoke MCP tools without authentication." With no per-request credential, handlers fall back to the operator’s META_ACCESS_TOKEN. And when the downstream Graph API call fails, the code "serialises the raw httpx request URL — including the operator’s access_token as a query parameter — into the JSON-RPC response body, delivering the credential to the unauthenticated caller."

Three ordinary mistakes, stacked. A missing 401, a fallback credential, and an error handler that echoes a URL. The result is that a failed request hands your ad account token to whoever asked. CISA’s SSVC assessment on the same record marks exploitation as proof-of-concept, automatable, with total technical impact.

That package is listed in the official MCP registry, under the namespace co.pipeboard. So is the same publisher’s Google Ads server, published May 21, 2026. The version listed there today, 1.0.120, is past the 1.0.109 fix. The point is that the listing itself never told you either way. Listing is not endorsement, and the registry says so in its own design documents: "No built-in ranking, curation, or quality judgments," "Let consumers (MCP clients, aggregators) make their own curation decisions," "Avoid features that require constant human intervention or moderation." It leans on npm and PyPI for source security, "obviating the need to reinvent source code security." That is a defensible architecture for a metaregistry. It is not a safety signal, and the ecosystem is being read as though it were. For scale: a keyword search for "mcp server" in the National Vulnerability Database returned 288 entries (184 for the exact phrase) entries on August 21, 2026.

Then there is the finding I keep coming back to. The registry supports DNS and HTTP verification for domain namespaces such as com.example.*, and GitHub OAuth for io.github.*. I checked seven martech vendors. com.hubspot, com.salesforce, com.adobe, com.klaviyo, com.braze, com.twilio and com.segment hold zero servers between them. Search the registry for HubSpot and you do get results; every one of them sits under somebody else’s namespace, mostly io.github.*. Google holds fifteen verified namespaces, every one of them com.googleapis.* (Compute, Firestore, Cloud Run, Monitoring and so on), and none for Ads or Analytics. Meanwhile com.stripe/mcp has been listed since October 28, 2025, pointing at mcp.stripe.com.

So this is not a capability gap. Stripe proves a vendor can claim its namespace when it decides the ecosystem matters. The martech vendors have shipped MCP servers and have not claimed theirs, which means an agent discovering a "HubSpot" server through the registry today is finding somebody else’s code with HubSpot’s name on it.

My working take

The read/write matrix is the least interesting thing on this page and it is the only thing most coverage reproduces. Read-only versus write is a release-note distinction that a maintainer comment can invalidate in a sprint. The scope is the durable fact.

If I were advising a marketing ops lead this week, the position would be narrow. Connect read tools freely; the value is real and the downside is a report you have to sanity-check, which is the same downside reporting always had. Treat any write scope as a change to your access model, not a productivity feature, and route it through whoever owns access to that system, the same people who would have to be in the room before data moved anywhere else. And prefer the platforms that scoped this properly: Salesforce minting an MCP-only scope and both CRMs inheriting the authorising user’s permissions are meaningfully better postures than a single all-powerful ads scope, and that ordering is not the one the marketing conversation assumes.

What I do not know is the operational failure rate. I have read the documentation carefully and I have written agent tools with permission boundaries on them, and neither of those tells me how often a write-capable agent does something expensive in a real ad account. Nobody I can find has published that, and I am not going to estimate it. The other thing I do not know is how much of this survives September. The most consequential sentence I read all week was a maintainer saying write access is coming soon, which is why the honest form of this post is a snapshot with the verification date printed on it, and why any version of it you read without one is not telling you something it should.

A boring conclusion: read the scope, not the tool list. I think it is the right one, and it will still be right after the tool lists change.

Frequently asked questions about AI agents in ad accounts and CRM

Can an AI agent pause a Google Ads campaign?

Not through Google’s official MCP server. Its documentation, last updated August 19, 2026, states: "This implementation is strictly read-only. It cannot modify bids, pause campaigns, or create new assets." Only three tools are exposed: list_accessible_customers, search and get_resource_metadata. A maintainer confirmed on June 4, 2026 that write access is planned, so treat this as a current-release fact rather than a design commitment.

Can an AI agent create Meta ads without approval?

It can create them, and Meta’s documentation says they arrive paused: "Write tools create entities in a paused state; your AI client asks for confirmation before activation." Confirmation is the AI client’s responsibility, not the server’s, and a separate tool called ads_activate_entity exists to switch a paused entity to active. A custom or unattended client keeps the write tools and loses the prompt.

What permissions does connecting an AI agent to HubSpot grant?

Whatever the authorising user already has. HubSpot’s GA changelog from April 13, 2026 states that "All actions respect your existing HubSpot user permissions — users can only access or modify records they already have permission to view or edit." The server reads CRM records, marketing content and activities, and creates and updates contacts, companies, deals, tickets, line items, products and activities. Its authorization metadata returns "scopes_supported": [], so you cannot enumerate the grant in advance: restrict the connecting user instead.

Is the official MCP registry safe to install from?

It is a directory, not a review board. Its published design principles state "No built-in ranking, curation, or quality judgments" and delegate source-code security to package registries such as npm and PyPI. A registry listing verifies a namespace claim, nothing more. pipeboard-co/meta-ads-mcp, which carried the critical CVE-2026-48039, is listed there.

Do martech vendors publish official MCP servers in the registry?

Not as of August 21, 2026. Checked directly against the registry API, the namespaces com.hubspot, com.salesforce, com.adobe, com.klaviyo, com.braze, com.twilio and com.segment hold zero servers, and Google’s fifteen verified namespaces are all com.googleapis.* with none for Ads or Analytics. com.stripe/mcp has been listed since October 28, 2025, so vendors clearly register when they choose to. Get your connection details from the vendor’s own documentation, not from a search result.

Sources I used

Verified at source: August 21, 2026.