MCP itself is not the risky part. The specification ships its own security document, it names eleven attacks in detail, and it mandates real protections against every one of them. What it does not do — and does not claim to do — is stop a model from following instructions hidden in a tool description, or hold a write for a human to approve. Those two gaps are where the actual risk to a marketing account lives, and both are properties of the individual server you connect, not of the protocol.
Last updated September 14, 2026. If you are not sure what any of this is yet, start with what MCP is. This page assumes you are about to connect something to an account that matters.
"Is MCP safe" is two different questions
People asking it mean one of two things, and the answers are opposite.
- "Is the plumbing sound?" Yes, and unusually so for a two-year-old standard. The security best practices document is long, specific and full of
MUSTrequirements. Read on for what it covers. - "Can this thing do something stupid with my ad account?" That depends on one server and one product decision, and the protocol has nothing to say about it.
What the specification actually secures
Eleven named attacks, each with an attack description and mandated mitigations. Abbreviated, with the requirement that matters:
| Attack | What it is | What the spec requires |
|---|---|---|
| Confused deputy | A proxy server with a static client ID lets an attacker reuse your consent cookie to get an authorization code. | Servers MUST implement per-client consent before forwarding to a third-party authorization server. |
| Token passthrough | A server accepts a token that was issued for something else and forwards it downstream. | Servers MUST NOT accept any token not explicitly issued for them. |
| SSRF | A hostile server returns metadata URLs pointing at internal addresses such as the cloud metadata endpoint. | Clients MUST consider SSRF and SHOULD block private IP ranges and enforce HTTPS. |
| State handle hijacking | Since the protocol went stateless, servers mint their own handles; guessing one reaches another user’s state. | Servers MUST NOT treat possession of a handle as authentication, and SHOULD bind handles to the authenticated user. |
| Local server compromise | A configuration entry runs an arbitrary command on your machine with your privileges. | Clients offering one-click local setup MUST show the exact command untruncated and require explicit approval. |
| Malicious OAuth URLs | A server hands back a javascript: authorization URL, or one carrying shell metacharacters. | Clients MUST allow only http and https, and MUST NOT open URLs through a shell. |
| Mix-up attacks | One authorization server tricks a client into redeeming another server’s code at its endpoint. | Response validation binds the response to the recorded issuer; PKCE alone does not prevent it. |
| Scope inflation | Broad up-front scopes make a stolen token far more useful and make consent screens people decline. | Least privilege, with step-up challenges rather than an omnibus grant. |
That is a serious document, and a server that ignores it is the problem rather than the protocol being one. The authorization specification carries the rest.
The attack that is not on that list
Read the eleven again and notice what is missing. Every one is about transport, tokens, consent or process execution. None is about the model reading something and believing it.
That gap has a name. Tool poisoning: a hostile or compromised server puts instructions inside a tool's description or its response, and the model — which reads tool descriptions as guidance, because that is the entire mechanism by which it decides what to call — follows them. OWASP classifies it as an indirect prompt injection where injected text lands in the context window and is treated as trusted input, letting the model call restricted tools, leak data or work around its own system prompt.
Academic threat modelling of MCP across the host, the model, the server, the data stores and the authorization server reaches the same conclusion: tool poisoning is "the most prevalent and impactful client-side vulnerability", and a comparison of seven major MCP clients found "significant security issues with most tested clients due to insufficient static validation and parameter visibility" (Huang et al., March 2026). The Cloud Security Alliance has a research note on the same surface combined with IDE auto-execution.
Anthropic says the operational version of this in one sentence in its own connector documentation: only connect to trusted servers, because "malicious MCP servers may include hidden instructions" (Anthropic). That is not boilerplate. It is the vendor telling you the protected boundary ends at your judgement about who wrote the server.
The second gap: nothing holds a write
Search the specification for an approval primitive and there is not one. A tool is a name, a description and a JSON schema; calling it does whatever the server does. So this sequence is entirely within spec:
- You ask a vaguely-worded question about a campaign that is underperforming.
- The model decides the helpful next step is to pause it.
- A
pause_campaigntool exists and takes one argument. - The campaign is paused. Nothing was violated, nothing was exploited, and nobody approved anything.
Whether a change is staged as something you look at and click is a product decision by the individual server. It is the single most important question to ask about any connector that can touch money, and it is invisible from the outside — a tool list looks the same either way. It is why every write through the Sprites connector comes back as an approval card with the before, the after and the reason, rather than as a change that already happened.
Remote and local are different risk profiles
12,461 of the 31,793 servers in the official registry are local-only packages. For a non-developer that is the higher-risk category, and the specification agrees — it devotes an entire section to local server compromise and none to the remote equivalent.
| Remote server | Local server | |
|---|---|---|
| Where the credential lives | A scoped OAuth grant held by the server | Usually a long-lived API key in a plain JSON file on your disk |
| Revocation | From your assistant’s settings; the next call fails | Delete the file, rotate the key, remember every machine it is on |
| Code execution on your machine | None | A process running with your privileges |
| Who can read the credential | The server operator | Anything running as you |
| Updates | The operator ships them | You, whenever you remember |
The trade is real in the other direction too: a remote server means a third party holds a grant to your account, so who operates it matters more than it would locally. The question is not which is safer in the abstract, it is which failure you would rather be exposed to.
Six questions before you connect anything
Two minutes, in this order. If you cannot answer all six, do not connect it to an account that spends money.
- Who publishes it? The vendor whose data it reaches, or a third party. Both can be fine; only one of them has a reputation riding on it.
- Remote or local? If local, you are installing software and storing a credential. Decide that deliberately rather than discovering it at step three of a tutorial.
- What does the consent screen actually say? This is the one moment you see the scopes. Read them. A read-only job asking for write scopes is the whole signal.
- What gates a write? If the answer is "nothing", the server can change things because a sentence was ambiguous.
- How many tools does it add? Every tool description is read on every turn. A server exposing forty is forty ways for the model to pick wrong, and it degrades everything else you have connected.
- How do I revoke it? Know the answer before you need it, and confirm the next call actually fails rather than running on a cached token.
What this means for an ad account specifically
Marketing connectors are an unusually attractive target and an unusually forgiving one to abuse: the systems they touch move money continuously, the changes look like ordinary optimisation, and nobody audits a budget edit the way they audit a login.
- A budget change is a plausible-looking action. Fraudulent spend does not look like an intrusion. It looks like a campaign that got more aggressive.
- Ad platforms have their own fraud detection. Unofficial API access at volume can flag an account, which is a risk a community wrapper carries and an official partner integration does not.
- Creative and copy are exfiltration surfaces. Unreleased positioning pasted into a thread with a poisoned connector attached is gone.
- The audit trail is the recovery plan. When something does go wrong, "which change, by whom, when, and why" is the difference between a fix and a forensic exercise.
None of that is an argument against connecting an agent to your accounts. It is an argument for asking the six questions, preferring a server that proposes over one that executes, and keeping the number of connected servers small. The MCP servers worth connecting and the Claude connector shortlist both say, per entry, which category each one is in.
MCP security questions
Is MCP safe?
The protocol is not the risky part — the specification publishes a detailed security document and mandates real protections. The risk is the individual server you connect and what it is allowed to do afterwards, because MCP defines no approval step. Treat adding a connector like installing an app with account access, not like opening a web page.
What is MCP tool poisoning?
A hostile or compromised server writes instructions into a tool description. The model reads tool descriptions as guidance rather than as data, so the text can tell it to call another tool, reveal something from the conversation, or ignore an earlier instruction. Academic threat modelling of MCP identifies it as the most prevalent and impactful client-side vulnerability.
Can an MCP server read my whole conversation?
Not by itself. A server sees the arguments the model sends to its own tools. But a model that has just read a poisoned description can be persuaded to put conversation contents into those arguments, which is how a read-only-looking server becomes an exfiltration route.
Does the MCP specification protect against prompt injection?
No, and it does not claim to. Its security document details eleven attacks — confused deputy, token passthrough, SSRF, state handle hijacking, local server compromise, malicious OAuth URLs and more — all of which are about the protocol and the authorization flow. Defending the model against text it reads is left to the client.
Are remote MCP servers safer than local ones?
Generally yes, for a non-developer. A remote server holds a scoped OAuth grant you can revoke from your assistant’s settings, and nothing runs on your machine. A local server is a process running with your privileges, usually configured with a long-lived API key in a plain text file, and the specification devotes a whole section to how that goes wrong.
What should I check before connecting an MCP server?
Six things: who publishes it, whether it is remote or local, what scopes the consent screen actually asks for, whether writes are staged for your approval, how many tools it adds, and how you revoke it. If you cannot answer all six in two minutes, do not connect it to anything that spends money.
Can an AI agent spend my ad budget by mistake?
If the server exposes a write tool with no approval gate, yes — a single ambiguous sentence is enough, and nothing in the protocol stands between the model deciding and the change applying. Whether a change is held for a human to click is a property of the individual server, never of MCP.
Is it safe to connect MCP to Google Ads or Meta Ads?
It depends entirely on who holds the credential. A server that connects through an official partner integration and stages every write as an approval you edit is a different risk profile from a community wrapper holding your developer token in a config file. Ask which one you are installing before you paste the URL.