Before You Give Claude, ChatGPT or Codex Write Access to Your Marketing Tools: The Draft-Only Rule

You are about to connect an AI assistant to the tools that email your customers. Somebody, probably the founder or whoever owns security, is going to ask what the assistant can actually do to the list. This post is the answer you can hand them.

The short version: the safety of a marketing connector is decided by its tool list, not by the assistant, not by the permission prompt, and not by how careful your team is. If a connector has a tool that can send, launch or delete, then a mistaken click, a stale instruction or a poisoned web page can reach customers. If every write lands as a draft that a person approves inside the tool, the worst outcome is a bad draft in a queue. We call the second design the draft-only rule.

Here is why prompts are not enough, what has already gone wrong for other people, how to read a connector’s tool list, and a one-page policy you can paste into a security review.

Permission prompts are the wrong layer

Every assistant ships with approval prompts, and every vendor tells you to use them carefully. Anthropic’s custom connector guide says to click “Allow always” only for a server and tool “that you trust to run unsupervised”, and warns that “malicious MCP servers may include hidden instructions.” Its guide to using Cowork safely offers three modes for tool calls (approve manually, approve automatically, skip all) and tells you to stay on manual when mistakes “would be hard to undo, like sending messages.” It also says not to schedule tasks that send messages on your behalf.

That advice is right, and it also tells you where the limits are.

Prompts fatigue. The tenth “Allow this tool?” of the morning gets the same click as the first. The OWASP MCP security cheat sheet lists approval fatigue as a standing risk, because it is one.

Unattended runs skip them. Claude Code’s Routines documentation, as of September 2026, states that during a scheduled run Claude can use every tool from an included connector, including writes, without asking for permission. That is the whole point of a routine. It is also why a connector with a send tool should never be in one.

A prompt cannot tell you whose idea it was. The dialog shows the action, not its origin. If the instruction to send came from a web page the assistant just read rather than from you, the prompt looks identical.

Prompts are a good second gate. They are a bad first gate. The first gate has to be in the tool design.

What has already gone wrong

None of this is hypothetical. A short list of incidents people in security now cite by name:

• GitHub MCP, May 2025. Invariant Labs showed that an instruction planted in a public GitHub issue could steer an assistant connected to the GitHub MCP server into leaking data from private repositories. The assistant did exactly what the tool allowed; the attacker never touched the user’s machine.
• Supabase and Cursor, July 2025. Supabase’s defense-in-depth write-up describes how text in a support ticket could drive a privileged MCP connection to read and exfiltrate data, and why they changed the defaults.
• Postmark MCP server, September 2025. Infosecurity Magazine reported a third-party MCP server for the Postmark email service that quietly added a BCC to every email it sent. The tool worked; it just also copied someone else.
• The Meta alignment director’s inbox, February 2026. A widely shared account of an agent that deleted hundreds of emails despite an explicit “don’t action until I tell you to” instruction. The instruction was in the chat; the delete tool was in the connector.
• Poisoned tool descriptions, June 2026. Microsoft warned that the descriptions MCP servers hand to the model can themselves carry instructions, so a malicious or compromised server can steer the assistant before you type anything.

The pattern is the same each time: untrusted text reached a model that held a tool capable of doing damage. Simon Willison named it the lethal trifecta: access to private data, exposure to untrusted content, and a way to communicate externally. Remove any one leg and the attack fails.

The lethal trifecta, marketing edition

Now map that onto a marketing assistant. Private data: your contact list, your pipeline, your unreleased launch. Untrusted content: it reads competitor websites, review pages, Reddit threads, inbound emails and chat transcripts all day, because that is what marketing research is. External communication: an email tool.

A marketing assistant with a send tool holds all three legs at once, by design, on a normal Tuesday. Indirect prompt injection is not an edge case for this job. It is the base rate.

The leg you can remove is the third one. Keep the private data (the assistant needs it). Accept the untrusted content (research requires it). Take away the ability to communicate externally without a person in the loop. That is the draft-only rule stated as a threat model, and it is the same mitigation WorkOS lists for MCP deployments generally: human approval gates and least-privilege writes.

Judge a connector by its tool list

Every MCP connector publishes the names and descriptions of its tools. Read them before you connect. The question is not “does it have write access” but “what is the most damaging thing one tool call can do.”

Two things stand out. First, the tools that can reach a customer are usually the headline feature, because “your assistant can send the campaign” demos well. Second, independent builders keep arriving at the same conclusion on their own: the developer who built his own HubSpot email server left out send on purpose. That is the market converging on a convention, and it is worth asking any vendor why their connector does not follow it.

Where does your connector actually work?

The second thing a security reviewer will ask is which surfaces the connector reaches and what gates each one applies. The answer, as of September 2026, is fragmented.

The lesson from the table is that you cannot rely on a gate you do not control. Routines have none. Codex modes are per-user settings anyone can change. The only gate that is the same on every row is the one inside the connector: what the write tools are allowed to create.

The draft-only rule, and what it does not solve

The rule: only connect marketing tools whose write actions land as drafts a person reviews and publishes inside the tool, and whose connector contains no send, launch, publish or delete tool at all.

What it buys you. The worst case of any tool call, mistaken or manipulated, is a draft in a queue. The audit trail is complete because every draft records who created it and through which surface. The approval step is the same one your team already uses, so nobody learns a new safety ritual. And unattended runs become useful rather than terrifying: a Monday routine can draft the week’s pieces and leave them waiting.

What it does not buy you. A draft can still be wrong, off-brand or badly targeted, so the review step has to be real; we make the case for that in human in the loop AI marketing. Read tools still expose data to the model, so the connector should see only what your login sees, through your own sign-in rather than a shared API key. And it does not replace basic hygiene: sign in per user with OAuth, never paste API keys into a chat, and revoke access from the assistant’s settings when someone leaves.

A one-page policy you can paste into a security review

Use this as a starting point for your internal standard on AI assistants and marketing systems.

1. Authentication. Assistants connect to marketing systems through per-user OAuth sign-in only. No shared API keys, no keys pasted into chats or config files.
2. Read scope. The assistant may read only what the signed-in user can read in the tool.
3. Write scope. Every write action must create a draft that is reviewed and published by a person inside the tool. Connectors that expose send, launch, publish or delete tools are not approved for marketing systems.
4. Unattended runs. Scheduled or automatic runs (Routines, agents, cron) may use only connectors that meet rule 3.
5. Approval settings. “Allow always” and equivalent settings may be used only for connectors that meet rule 3. Workspace admins disable always-allow for write tools elsewhere.
6. Untrusted content. Assume any web page, email, ticket or transcript the assistant reads may contain instructions. This is why rule 3 is not optional.
7. Audit. Every draft records who created it and through which assistant. Review the queue, not the chat logs.
8. Offboarding. Access is revoked from the assistant’s connector settings and from the marketing tool’s user list on the same day.

Eight rules, one page, and the answer to “what can it do to our list” is: it can make drafts.

How to connect, on each surface

The server is https://app.marqeable.com/mcp. In Claude, open Settings > Connectors, add a custom connector with that address, and sign in. In Claude Code, run claude mcp add --transport http marqeable https://app.marqeable.com/mcp, then /mcp to sign in. In ChatGPT, turn on Developer mode under Settings > Connectors > Advanced, create a connector with the address and OAuth, and sign in. In Codex, add the server to ~/.codex/config.toml and run codex mcp login marqeable. A good first prompt on any of them is “Run whoami, then get_business_context, then tell me what is on the calendar this month.” If you are choosing between assistants for a small team, pick by connectors, not by model, and if you are evaluating other tools in the stack, ask each one whether it has an MCP server and what its write tools can do.

Frequently asked questions

Is it safe to give Claude or ChatGPT write access to marketing tools?

It depends on what the write tools can do, not on the assistant. If a connector exposes a tool that can send, launch or delete, a single mistaken or manipulated call reaches customers. If every write creates a draft that a person approves in the tool, the worst case is a bad draft in a queue. Check the tool list before you connect.

What is prompt injection and why does it matter for marketing connectors?

Prompt injection is when text the assistant reads, such as a web page, an email or a support ticket, contains instructions that the model follows as if they came from you. Marketing assistants read competitor sites, review pages and inboxes constantly, so they see untrusted text all day. A connector with a send tool turns that into a way for a stranger to trigger a send.

Do permission prompts protect me?

Partly, and less over time. People click Allow always after the tenth prompt, scheduled and unattended runs may execute connector writes without prompting, and a prompt cannot tell you whether the action it is approving was your idea or an injected one. Prompts are a useful second gate. The first gate has to be the tool design.

What is the draft-only rule?

Only connect marketing tools whose write actions land as drafts a human reviews and publishes inside the tool. No send, launch, publish or delete tool should exist in the connector at all. Marqeable’s MCP server is built this way: ten read tools, six draft-only write tools, zero send tools.

The bottom line

The question to ask about any AI marketing connector is not whether it can write, but what the most damaging thing a single tool call can do is. The incidents of the last eighteen months all share one shape: untrusted text reached a model holding a tool that could cause harm. Permission prompts help and then fatigue; unattended runs skip them entirely. The gate that holds on every surface is the one built into the connector. Only connect tools whose writes are drafts, and the answer to your security review becomes one sentence.

See the draft-only design in practice: Marqeable’s agents build and run your campaigns, run behavior-triggered automations across text and email, answer and qualify every visitor with AI website chat, and tie revenue to the exact message with attribution.

Marqeable runs your campaigns, answers every visitor, text, and email in seconds, and turns them into booked jobs and meetings - even at 9pm on a Saturday. We’re in private beta with a small early cohort. Get early access