Model Context Protocol (MCP): Risks, Limits and Governance Rules

Before MCP, connecting an assistant to each tool needed a custom integration. MCP standardises that connection, so one assistant can work across many systems. That makes tasks like pull last week’s campaign results from the ad platform and summarise them in a doc much easier.

The same convenience is the source of risk. An assistant with access to ten systems can do ten times as much damage if it is misled or misconfigured.

Prompt injection

If an assistant reads a web page, email or document containing hidden instructions, it may follow them. Combined with MCP tools that can send messages or change data, a malicious instruction could cause the assistant to leak information or take unwanted actions. Security researchers have demonstrated such attacks against several MCP setups.

Over-broad permissions

Many servers authenticate with a single token that grants everything the user can do. An assistant meant only to read reports might, through the same token, be able to delete campaigns.

Untrusted servers

Anyone can publish an MCP server. A server from an unknown source could log data, change its tool descriptions after installation or contain vulnerable code. Running unverified servers locally gives them access to the machine.

Credential exposure

API keys stored in plain configuration files, shared between staff or committed to repositories are a common weakness. The MCP specification added OAuth-based authorisation for remote servers, but implementations vary.

• Assistants can choose the wrong tool or pass wrong parameters
• Large data pulls may exceed context limits and be truncated
• Server quality varies widely; some are maintained by vendors, many by individuals
• Not every client supports every MCP feature or transport
• Audit logging is often left to the server author and may be minimal

• Approved server list: only official vendor servers or ones reviewed internally
• Read-only by default: write and delete actions need explicit approval per use case
• Least privilege credentials: separate tokens with minimal scopes for each server
• Human confirmation for any action that sends, publishes, spends or deletes
• No servers that combine untrusted content reading with sensitive write access in one session
• Logging: record which tools were called, by whom and with what result
• Owner per server: someone responsible for updates and reviewing changes

The rule about combining capabilities deserves emphasis. An assistant that browses the open web and also has permission to email customers is a high-risk pairing. Separate them, or require confirmation for every outbound action.

Check who publishes it, whether the code is open, when it was last updated and what permissions it requests. Read the tool descriptions, because they are effectively instructions to the model. Test it in a sandbox account with no real customer data before connecting it to production systems.

Prefer remote servers with OAuth and scoped permissions from the tool vendor itself where available. Many major platforms now publish official servers.

A good first project is a read-only reporting assistant. It connects to Google Analytics, Search Console and the ad platform with read scopes only, and produces a weekly summary for the team. Nothing can be changed, and the worst case is an inaccurate summary that a person checks before sharing.

Once that runs well, a team might add write access to a single low-risk destination, such as creating draft documents in a shared folder, still with confirmation.

When an assistant pulls customer data through an MCP server, that data may pass into the AI provider’s systems. Under GDPR and KVKK, the provider becomes a processor, and the business needs a data processing agreement and a clear purpose for the transfer.

Check where the AI provider processes data, whether business plans exclude it from training, and how long conversation logs are kept. For servers that touch personal data, prefer aggregated queries, such as campaign totals, over pulling individual customer records into the conversation.

Document these choices in the same policy that lists approved servers, so a single page answers both security and privacy questions.