How not to get burned wiring AI into your marketing stack

What can actually go wrong when you connect an AI to your tools?

More than the vendors advertise. Prompt injection, where hidden instructions in a document or email hijack the agent, tops OWASP's 2025 risk list for AI applications. One compromised connector package exposed more than 437,000 environments. And the danger is rarely dramatic. Usually a write fails silently, or the agent has more access than anyone meant it to.

Take the headline risks one at a time. Prompt injection is first on OWASP's 2025 list of risks for AI applications for a reason: an attacker hides instructions inside a document, web page or email that your agent reads, and the agent follows them as if they came from you. The indirect version is worse, because the malicious text rides in on content you retrieved for an ordinary reason.

Then there's the supply chain. One compromised MCP-related package, tracked as CVE-2025-6514, exposed more than 437,000 environments through a command-injection flaw. You didn't have to do anything wrong; you just had to have wired it. And over-permissioned agents make every one of these worse, because the damage scales with access. The Supabase incident involved an agent with privileged access processing attacker-controlled input, which is the blast radius made concrete.

But the failure you'll actually meet most often isn't an attack. It's mundane. A write fails silently and nothing tells you. An agent quietly has more access than anyone intended. A tool's behaviour changes after an update you didn't notice. Defending against the dramatic cases and the dull ones turns out to need the same posture.

How much access should an AI agent really have?

As little as the job needs. Treat an AI agent like a junior employee with elevated access: clear scope, tight permissions, close monitoring. Default every connector to read. Put a human in front of anything that writes, deletes, or sends. The serious vendors already design this way, which is why Google's Ads server only reads.

In practice that means two defaults. Read by default: a connector that only reads can't break anything, and as the first piece covered, reading is most of the value anyway. And a human in front of every write: anything that changes a record, deletes data or sends a message to a client goes through a person first. This isn't a fringe position. It's how the careful vendors already build. Google's Ads server reads but won't change a campaign. HubSpot honours each user's existing permissions and blocks sensitive activity objects. ChatGPT shows a confirmation step before it acts. The pattern is consistent: the further a tool can reach, the more friction the serious builders put in front of it.

Should you self-host your MCP server instead of using hosted connectors?

If you handle clients' data, seriously consider it. Hosted connectors are convenient, but they route your data through someone else's infrastructure. A self-hosted server keeps credentials and data on your own. We run our own, a semantic knowledge base on Supabase the team queries through MCP, precisely so client data never leaves our control.

This is the part of MCP security almost nobody writes about for marketers, and where an agency handling client data has to think hardest. A hosted connector is the easy path: someone else runs the server, handles the auth, keeps it up. The trade is that your data, and often your credentials, pass through their infrastructure. For your own marketing data that may be a fine trade. For data your clients trusted you with, it's a question you have to answer on purpose, not by default.

What's the minimum governance before you connect anything?

Six things, none of them heavy. Scoped tokens, not master keys. Read by default. Human approval on writes. A full audit log of every tool call. Version-pinned servers, so an update can't change behaviour silently. And a kill switch. If you can't tick all six, you're not ready to connect that tool to anything that matters.

Take them in turn, because each closes a specific failure from the first section:

1. 01

   Scoped tokens, not master keys.

   Give each connector the narrowest credential that does its job. If it leaks, the damage is bounded to what that token could reach.

2. 02

   Read by default.

   Reading can't break things. Make write access the deliberate exception, not the starting point.

3. 03

   Human approval on writes.

   Anything that changes, deletes or sends passes a person first. This is the single control that stops a hijacked agent doing real harm.

4. 04

   A full audit log.

   Every tool call recorded. If you can't see what the agent did, you can't catch the silent failure or prove what happened after one.

5. 05

   Version-pinned servers.

   Pin the version so a server can't silently change behaviour after you approved it. This is the defence against the rug-pull, where an approved tool turns malicious in an update.

6. 06

   A kill switch.

   A way to revoke access and stop the agent now, without a deploy. If you can't stop it fast, you don't control it.

Drew Price's rule of thumb sits over all six: monitor first, trust later. Gartner makes a sharper-edged version of the same point, cautioning against externally-facing remote MCP servers for internal services while the tooling is still maturing. The six aren't a compliance burden. They're the difference between an incident and a catastrophe.

Call it the blast-radius check.

When should you not connect a tool at all?

When you can't undo what the agent might do. If a connector can write to billing, delete records, or send to clients, and you have no log, no approval step, and no way to stop it, don't wire it. As one ops leader puts it, if an AI system can't be safely stopped or undone, it shouldn't have production access. That's the line.

Drew Price's framing is the cleanest disqualifier going: a system that can't be safely stopped or undone shouldn't have production access. Run a connector against that and the answer is often immediate. A tool that can send invoices to clients, with no audit log and no human approval and no kill switch, fails on three of the six at once. It doesn't matter how useful it is in a demo. You can't unsend the email.

So the real disqualifiers are specific. A connector that touches something irreversible, billing, deletion, outbound client comms, with no logging behind it. Sensitive data flowing through a tool you can't fully see into. Or, the quiet one, nobody actually owning governance, so the six controls are "someone's problem" and therefore no one's. If any of those is true, the tool waits, however much you want it.

Restraint is the feature.

The posture, in one line

Across the three pieces it comes down to this: AI mostly reads your stack today, so wire the few tools you'd query weekly, give them the least access the job needs, and keep a human and a log on anything that can't be undone. Read the reality, wire fewer, govern tight. That's how you get the upside of MCP without inheriting its worst day.