MCP and Access Rights: What Your Marketing Agent Is Really Allowed to Do – and Who Ticked the Boxes?

A marketing agent that pulls reports from your ad account is an asset. A marketing agent that may also change campaigns, move budgets and delete audiences in that same ad account is a risk you may not have planned for. The difference between the two is not in the agent’s name or in the feature list on a product page. It is in a list that gets ticked off during setup: the access rights.

Technically, these rights are called “scopes”. When an AI agent is connected to tools and data through the Model Context Protocol (MCP), its access key carries a list of permitted actions. That list can be small and precise, for example “read reports only”. It can also be large and blanket, for example “everything”. Which of the two applies in your company decides how big the damage is in the worst case, how easily you can trace mistakes and how quickly you can react in an emergency.

This post is a primer, not breaking news. It rests on one clearly identifiable section of the official MCP documentation: “Scope Minimization” in the “Security Best Practices” on modelcontextprotocol.io, document version 2026-07-28, retrieved and read by us on October 26, 2026. We explain what it says in language that works without a developer background, and we turn it into a checklist for companies in the DACH region that want to connect agents to their ad account, CRM or content tools, or already have.

What MCP is, what is established and what we do not know

The Model Context Protocol is an open standard that lets AI applications access tools, services and data sources in a structured way. Instead of building a separate interface for every platform, agent and tool speak a common language. For you as a company this matters for one main reason: the easier an agent is to connect, the more often it will happen, and the more important the question becomes what the agent may do once connected.

Before we go into detail, a clean separation of what is documented and what is not:

• Documented: In version 2026-07-28, the MCP documentation has its own section “Scope Minimization”. It describes an attack, names risks, recommends a staged rights model and lists common mistakes. We read the section ourselves on October 26, 2026.
• Documented: According to its own introduction, the document is aimed at developers implementing authorization, at operators of MCP servers and at security professionals evaluating MCP-based systems. It is not a guide for marketing departments. We translate it here and present nothing as a statement of the documentation that is not in it.
• Not documented: Whether the connection of your specific ad account, CRM or content tool offers staged rights at all is not in the documentation. You have to check that with the respective provider. Nor does the documentation say which platforms use MCP. We therefore deliberately name no platforms as examples of MCP connections in this post.
• Availability: MCP itself is an open standard and not tied to a region. How far individual providers support the standard in their products differs from provider to provider and is not documented here. For DACH this means: the principle of rights minimization applies regardless of provider; whether your connection supports it is for you to clarify.

This is an evergreen topic. It does not become due on a date, but at the moment you first give an agent access. If that has already happened, the best time to check is now.

What the guidance on “Scope Minimization” describes

The section opens with a sentence that sums up the whole topic: poor scope design increases the impact of a compromised access key, increases friction for users and obscures the audit trail. Three problems in one sentence, and all three affect a company’s everyday life, not just security departments.

The documentation then describes an attack in sober terms. An attacker obtains an access key, a so-called access token. This can happen through a leak in log files, through scraping memory or through local interception. The token carries broad rights, given in the documentation as examples files:*, db:* and admin:*. These broad rights were granted up front for a technical reason: the MCP server had published every right it knows in its list scopes_supported, and the client had requested them all. With the stolen token the attacker can, according to the documentation, reach laterally into other data (lateral data access), chain rights together (privilege chaining), and is hard to lock out again without re-confirming the entire surface.

Translated into a marketing team’s world: imagine an agent that is supposed to pull reports from your ad account. During setup, “full access” was granted for simplicity so nobody has to ask again later. If this agent’s key is taken, the attacker does not just get reports but everything this access allows. That the example is constructed is intentional. The documentation describes exactly this structure, only in technical terms.

The risks the section lists read like a checklist for managing directors:

• Larger blast radius: A stolen key with broad rights also opens tools and data that have nothing to do with the actual task.
• Harder revocation: Revoking a key with maximum rights halts every workflow that hangs on that key. That is exactly why people hesitate in an emergency.
• Noise in the audit trail: A single blanket right hides what the agent actually intended with each action. The log then says “had access” instead of “wanted to read” or “wanted to change”.
• Privilege chaining: With broad rights, an attacker can call sensitive functions immediately, without any further prompt or elevation.
• Consent abandonment: When users see a long list of rights during setup, they decline or click “Allow” without reading. Both are bad.
• Unnoticed scope inflation: Without metrics, an over-broad request eventually becomes normal.

Poor scope design increases the impact of a compromise, increases friction for users and obscures the audit trail. (paraphrase, modelcontextprotocol.io, “Security Best Practices”, section “Scope Minimization”, version 2026-07-28, retrieved October 26, 2026)

For a mid-sized company, the second point is the most underestimated. You only notice in an emergency that a revocation does not stop “just” one agent but several workflows at once, because everything ran through one shared, broadly authorized access. At that point the choice between “limit the damage” and “keep operating” is uncomfortable. With separate, narrow accesses the dilemma never arises.

The common mistakes and why they are so tempting

The section names six “Common Mistakes”. We list them and put them in context, because each has an understandable reason for happening.

First: all possible rights are published. The MCP server lists its entire rights offering in scopes_supported. That is convenient because nothing needs maintaining. But it has a side effect that the documentation notes elsewhere in the same section: if the server’s first challenge gives no specific rights, the specification directs clients to fall back to requesting all rights listed in scopes_supported. The specification’s reasoning is that general-purpose MCP clients lack domain knowledge about individual rights and that the decision should be left to the authorization server and the user at consent. In practice: if nobody actively narrows things down, the convenient path can be the broad one. That is no accusation against anyone, but the reason someone has to look actively.

Second: blanket rights such as *, all or full-access. They are short and solve every permission problem before it arises. That is exactly why they show up so often, and exactly why the documentation lists them as a mistake.

Third: unrelated rights are bundled to avoid later prompts. From a team’s perspective that is understandable: nobody wants to file another request three weeks later. From a security perspective it is the opposite of rights minimization.

Fourth: the entire rights catalog appears in every challenge. Instead of asking only for what the current action needs, everything is requested at every opportunity.

Fifth: silent changes to what a right means, without versioning. What meant “read” yesterday allows more tomorrow, and nobody noticed. For you as a user this is why a one-off check is not enough and should be repeated at intervals.

Sixth: rights in the token are treated as sufficient, with no check on the server itself. A token says what was requested. It does not replace the server-side check of whether the concrete action is allowed. You cannot solve this point yourself as a user, but you can ask providers about it.

The counter-model: rights in stages instead of everything at once

The documentation recommends a “progressive least-privilege model”. That sounds technical, but the idea is simple and familiar from everyday life: a new employee does not get the key to the safe on day one, but access to what they need for their first tasks. More rights follow when they are needed and someone grants them deliberately.

Specifically, the section names these building blocks:

• Minimal start: At the beginning there is only a small set of low-risk rights for discovery and reading. The documentation gives a scope named mcp:tools-basic as an example.
• Incremental elevation: When the agent first attempts an action with higher risk, the server requests precisely the right needed for it, via a challenge in the WWW-Authenticate header with a scope value. Only then is the right granted.
• Tolerance for fewer rights: A server should accept keys with reduced rights, and the authorization server may issue only a subset of the requested rights.

For server operators the documentation adds: precise rights challenges instead of the entire catalog, and logging of elevations, meaning which right was requested and which subset was granted, with correlation IDs so a process can be traced later. For clients, the agent’s side, the rule is: begin with baseline rights. On how many rights a challenge carries, the documentation leaves the server room to choose, from “only what is needed” through “what is needed plus rights that commonly go together” to “also what will likely be needed soon”. The choice depends on weighing user experience against friction.

Note the honesty of this trade-off: staged rights take a little more work. There is occasionally one more prompt, and someone has to answer it. The documentation does not claim rights minimization is free. It says it limits the impact of a compromise, makes the audit trail clearer and reduces consent abandonment. Whether this trade is worthwhile for your company is a judgment call. For access to ad budgets or customer data it usually comes out in favor of narrow rights.

Daniel and Kai: where the rights question becomes concrete in marketing

On amazing-agents.com we describe two roles where the question of access is especially tangible. Here we explain only how the website describes the roles and place the rights question in context. Which connections are technically used in an individual case is part of a setup and not the topic here.

Daniel is the analytics specialist in the research team under Nadja. According to the website, he collects performance data across all social media channels, delivers a weekly performance report and flags anomalies before they become a problem. His task is essentially read-only: fetch numbers, compare, interpret. From a rights-minimization view this is a textbook case of a role that should manage with a narrow read-only access. An analytics agent that may also change campaigns has more rights than its task requires.

Kai is the outreach lead and department head for sales outreach. According to the website, he defines strategy and sequences, the pipeline runs from sourcing through personalization to sending and follow-up, it is “pausable at any time”, and Kai “pauses when you say so”. He also respects opt-outs immediately and permanently. The rights question is different here, because outreach writes: it produces messages that reach people outside your company. The further the rights reach that such an agent has in your CRM or mailbox, the more important it is that they are granted deliberately and narrowly, and that the ability to pause does not hang on a single access that is hard to revoke.

The thought behind this carries over to every role: reading and writing are two different rights, and they should not sit in the same key just because it is more convenient. Daniel usually needs no write rights for campaigns. Kai needs write rights for drafts and sending, but no access to accounting data. Whether your connection allows this separation is the question for the provider that we marked as open above.

The checklist for your company and how we proceed in the audit

A list can be derived from the guidance that any company without a developer team can work through. We worded it so it can be checked in about an hour per connected agent. It is our approach in the audit, not a statement of the MCP documentation. The documentation provides the reasoning; the implementation for marketing teams is our translation.

1. Inventory: Which agents are connected, to which tools and with which access? Who set up the connection? Without this list nothing can be checked.
2. Look at the boxes: Which rights are actually set for each access? Not only whether the agent works, but which boxes are active at the access. Watch for terms like “admin”, “full access”, “all” and for asterisk rights.
3. Separate reading and changing: For each task, decide whether it only needs to read or also to change. Reading reports is different from changing budgets. Where only reading is needed, a read-only access applies.
4. One access per task: Instead of one shared key for everything, each task gets its own. Then one access can be revoked without stopping the other workflows.
5. Ask the provider: Does the connection offer staged rights? Can rights be added individually later? Is there a log showing who received which right and when? Record the answers in writing.
6. Check the log: Can you tell afterwards which action the agent performed and with which right? If not, the audit trail is the first problem.
7. Practice revocation: Walk through once how an access is blocked, who may decide that and what stops as a result. If revoking one access paralyzes half the operation, the rights are bundled too broadly.
8. Date for repetition: Rights change, providers change meanings. Set a fixed rhythm for re-checking, for example quarterly.

This is how we proceed in the audit: we start with the inventory, have the granted rights shown to us and assign each connection to one of three groups: read only, produce drafts, changes with effect outside the company. For the third group we define where a person approves. The result is a short list of changes in order of risk. We claim nothing about cases we do not know: where a provider does not support staged granting, we record that as an open point instead of glossing over it.

Agent with limits and an approval step: two different safeguards

Rights minimization and the approval step are often confused. They belong together, but they protect against different things.

The limit defines what an agent can do at all. It works before anything happens, and it works even when nobody is looking, for instance because an access key falls into the wrong hands. An agent with read-only access cannot change a campaign, no matter what goes wrong. That is the documentation’s message on rights minimization, applied to your marketing: the damage in case of error stays limited.

The approval step defines who decides before something takes effect outside. Even an agent with correctly granted write rights should not carry out changes affecting customers, budgets or data without a person’s consent. On amazing-agents.com this frame applies to all agents: approval steps for critical actions, and emails are created as drafts, not sent directly.

Without a limit and without an approval step: The agent has full access and acts alone. A mistake, a misunderstood instruction or a stolen key takes effect immediately and in full breadth. The log shows that the access was allowed, but not what was intended. A revocation paralyzes everything.

With a limit and an approval step: The agent works with an access that allows only what is needed. Everything that takes effect outside is a draft until a person approves it. The decision has a name, the audit trail is readable, and a revocation affects only the workflow concerned.

If you take away only one thing from this post: look once at every connected agent to see which boxes are ticked. Not whether it works, but what it may do. The answer to that question decides whether a mistake becomes a footnote or an incident.

Source and status: modelcontextprotocol.io, “Security Best Practices”, section “Scope Minimization”, document version 2026-07-28, retrieved October 26, 2026. This post is not legal or security advice for an individual case.