The Model Context Protocol gives AI models access to real-world tools. Here's why that's a security problem.
MCP is an open protocol that lets AI models call external tools — read files, query databases, control hardware.
The Model Context Protocol (MCP) defines a standard way for AI models to communicate with external tools and data sources. Instead of being limited to text generation, an AI with MCP access can take actions in the real world.
The pattern is simple: a user sends a message to an AI model. The model decides it needs to use a tool. It sends a structured request to an MCP server, which executes the tool and returns the result. The model incorporates that result and continues.
As AI agents become more autonomous, they increasingly need real-world access. MCP is becoming the standard way to provide it — which makes its security properties critically important.
MCP defines the transport, but leaves authorization to each implementation.
MCP servers typically implement access control through API keys, role-based tool filtering, and per-tool permission checks. A 'warehouse' role might see LED tools but not motor controls. An 'operator' role sees everything.
The critical gap: MCP itself has no built-in authorization standard. Each server implements its own permission model. This means inconsistent security approaches, easy mistakes, and difficult auditing.
Most implementations rely on a two-layer defence: the AI's system prompt tells it what it's allowed to do (Layer 1), and the server enforces permissions in code (Layer 2). Layer 1 is persuadable — an AI can be convinced to ignore its instructions. Layer 2 is code — but code has bugs.
From prompt injection to header manipulation, MCP servers face multiple attack categories.
The AI is a persuadable intermediary, not a security boundary. If the system prompt says 'you cannot use motor tools,' a creative user can often convince the AI to try anyway. The AI doesn't enforce security — it just follows instructions, and instructions can be overridden.
Server-side authorization logic is only as strong as its implementation. Common weaknesses include: header values that override API key roles, missing permission checks on specific tools, and overly permissive defaults that grant access unless explicitly denied.
Status and discovery endpoints often reveal too much. A tool listing might show all available tools regardless of the caller's role. A status endpoint might expose connected clients, their roles, and system architecture — giving attackers a map of the system.
Some tools execute without logging or appearing on monitoring dashboards. These blind spots let attackers probe the system without detection, testing boundaries before attempting a visible exploit.
Compound operations that bundle multiple actions behind a single permission check are particularly dangerous. A 'demo sequence' that requires lighting permission but internally moves motors bypasses the role model entirely.
MCP adoption is growing. These security patterns scale with it.
Today it's a model port. Tomorrow it's AI agents controlling CI/CD pipelines, cloud infrastructure, financial systems, and physical hardware at scale. The permission patterns being established now will define the security landscape for AI-tool integration.
There's a growing gap between 'AI safety' — which focuses on alignment and values — and 'AI security' — which focuses on infrastructure, permissions, and access control. MCP sits squarely in the security domain, and it needs the same rigorous attention that we give to authentication, authorization, and access control in traditional systems.
MCP is being adopted by major AI providers and tool ecosystems. The challenge you're about to try demonstrates these risks in a tangible, physical way — making abstract security concepts concrete and immediate.