AI agents only become useful when they work with real systems: creating tickets, reading customer data, filing documents, scheduling meetings. The Model Context Protocol has standardised this connection. That makes it easy, which is exactly why it needs deliberate architecture. An agent with too much access is a security risk that grows with every new connection.
What MCP changes
Previously every AI application had to build every integration itself. With MCP a server provides tools and data in a uniform format, and any MCP-capable application can use them. That speeds up integration considerably. At the same time it shifts the security question: risk is decided less by the model and more by which tools it may call and with which rights.
Typical risks
- Overly broad permissions: a server accessing the CRM with an admin account gives every agent admin rights.
- Prompt injection via tool results: a document, email or web page contains instructions the model treats as a task (prompt injection).
- Manipulated tool descriptions: a server from an untrusted source describes its tools so the model passes data to third parties.
- Missing traceability: without logs it is impossible to say which agent triggered which action and when.
Architecture principles
First, least privilege: each server and tool gets only the rights the specific use case needs, with dedicated credentials instead of shared accounts. Read and write tools are separated. Second, human confirmation: consequential actions such as payments, deletions or customer messages require approval. Third, isolation: content from untrusted sources is treated as data, not instructions, and agents processing such content get no dangerous tools. Fourth, logging of all tool calls with user, agent, parameters and result.
The role of the permission concept
An agent should never be allowed more than the person on whose behalf it acts. Where possible, the server uses the signed-in user’s permissions rather than a technical account with broad rights. This links agent architecture with the existing permission concept and stops an agent becoming a shortcut around approvals.
Governance
Which MCP servers may be used, who approves them and how are they updated? These questions belong in AI governance, together with a register of agents in use in the AI inventory. If agents are used for decisions about people, data protection and possibly the AI Act must also be checked.
Getting started
A good start is a single, narrowly defined use case with read-only tools, logging and an evaluation with test cases. Write tools follow only once quality and control are proven. The steps are in our checklist for securing MCP servers; development and operating costs are covered on the page on the cost of an AI agent.