How Marketing Teams Should Use MCP

with Sab Yahya

In this video, Sab, Marketing Automation Practice Lead at Ateko, explains how marketing teams should approach using MCP (Model Context Protocol) and AI agents safely. From access controls and code execution to sandbox limitations, logging, and human approval, Sab breaks down the key risks and rules teams need to follow before giving AI agents control of marketing platforms.

Transcript:

Sab:

Hi, I’m Sab, the Marketing Automation Practice Lead at Ateko

Today I’m going to talk about How Marketing Teams Should Use MCP

AI agents can now run marketing platforms for you. The thing that makes this work is called MCP. The Model Context Protocol. It’s an open standard that lets an AI assistant connect to a platform and do work on it using plain language.

Salesforce already has an MCP server for Marketing Cloud Engagement, and one for Marketing Cloud Next is coming. Other vendors will follow.

So the question is not if your team will use agents. The question is how.

That’s what I want to answer today. Because marketing platforms are risky places to let an agent run on its own. And the rules that keep you safe are the same, no matter which platform you use.

First: why is marketing riskier than most systems?

In a CRM, a bad change can usually be fixed. You fix the record, you move on. Marketing does not work that way.

A send is final. Once email goes out, there is no undo and no way to call it back. A bad query can quietly break an audience of millions. And it looks fine until a campaign goes out on top of bad data.

And if an agent changes consent or opt-out fields, that’s not just a data problem. That can break laws like CASL and CAN-SPAM, and that means real fines.

Now put an agent in that world. An agent is fast, it never gets tired, and it doesn’t understand what a mistake costs. That is exactly why safety rules matter here.

So here are the rules. Rule one: know which controls are real, and which are just advice.

Most MCP servers ship with safety features. Risky actions get flagged, and vendors tell you to preview changes before they run. But those features depend on the model choosing to stop. Nothing forces it.

The control that is real is access. In Marketing Cloud, for example, the agent can only do what the package and the user are both allowed to do. 

That’s the control you can count on. Treat the rest as helpful hints, not a wall.

Rule two: this is the one most teams miss. Access limits stop working the moment the agent can write code that runs inside the platform.

The limits control what the agent can do through the MCP connection. They do not control code the agent writes and then runs inside the platform itself.

Marketing Cloud gives us a clear example. Block the send permission, but allow the agent to create and run automations. And the agent can simply write a script that builds an email and sends it, then run that script. The script runs with full platform rights, far past what the package was allowed to do.

And the person asking needs zero coding skill. The agent writes the code. One sentence is enough.

In the worst case, a single prompt asking the agent to write and run a delete script can wipe out a whole business unit.

The general rule: if an agent can write code and run it, assume it can do anything that platform can do.

Rule three: give access at the lowest level the job needs, and learn where your test setup really ends.

In Marketing Cloud, a package placed at a parent business unit can reach every child unit under it. So you place packages at the lowest unit, never at the top.

And Marketing Cloud’s sandbox shares the same sending setup as production. A “test” send goes to real inboxes.

Whatever platform you use, check what your sandbox really blocks. Don’t assume.

Rule four: assume the logs won’t tell you who did it, and plan for that.

Agent actions are usually logged under the system account, not the person who wrote the prompt. When something goes wrong, you may never find out who asked for it. That’s true in Marketing Cloud, and it will be true in most platforms.

So don’t let the whole team share one set of keys. Keep one admin who can set up these connections. And save your logs while you still have them.

Put it all together, here’s how to run it.

Production gets read-only access. Full stop. Everything that creates or runs things lives in a test setup, split into small, single-purpose connections. And a person moves work to production by hand.

A human approves every write as a hard rule, not a hope. No write until the agent shows the record count and the exact query first. And keep test audiences limited to test data only.

So let me leave you with this.

MCP is worth adopting. It truly changes what marketing teams can do. But platforms come and go, and the next MCP server will have new settings and new gaps.

These rules don’t change. The agent will never understand that a send is forever. 

Your safety rules have to.