If you have heard "MCP" in a meeting and nodded, this is for you. It is less mysterious than it sounds, and the risks are mostly ones you already know from other integrations.
What it is#
The Model Context Protocol is an open standard for connecting AI applications to external systems. The project's own introduction compares it to a USB-C port: one common way to plug an AI application into data sources such as files and databases, tools such as search engines, and prepared workflows.
There are two sides. An MCP server exposes things: tools the AI can call, such as "create a ticket" or "search the wiki", plus data it can read. An MCP client is the application that talks to servers on behalf of a model. Your workflow tool is the client. The server may be run by a vendor, by your own IT team or by a stranger on the internet.
The practical benefit is reuse. Instead of every AI tool building its own connector for every product, a product publishes one MCP server and any client that speaks the protocol can use it.
How it fits in a workflow#
In Cadrix you can connect an MCP server and use its tools like built-in ones. The tools show up in the library, you give them to an agent in a workflow, and every call appears in the run trace. A typical setup:
- Get the server address and the credentials from whoever runs the server.
- Save the credentials as an encrypted connection, not in a prompt.
- Add the server in the tool library and look at the list of tools it exposes.
- In the workflow, give the agent only the tools it needs for this job.
- Test with harmless inputs and read the run trace to see what was sent.
- Put a Human Input step before any tool that changes something.
Step 4 matters most. A server may expose twenty tools. Your workflow probably needs two.
Five things that can go wrong#
The MCP project publishes security best-practice guidance. Most of it is aimed at people building servers and clients, but several points are useful to anyone choosing what to connect.
1. Over-broad permissions. The guidance on scope minimisation describes the failure where a token is granted every possible scope up front, so a stolen token can reach much more than any one task needed. Ask for the smallest access that works, and widen only when a real need appears.
2. Passing tokens through. The specification says servers must not accept tokens that were not issued for them and then forward them downstream. Among the reasons it gives: it breaks audit trails, because logs show requests coming from the wrong identity. If you operate a server, this is the rule to check. If you only connect to one, ask your provider.
3. Servers that run on your own machine. A local server runs with the same privileges as the application that starts it, and the guidance warns about malicious start-up commands in configuration. The advice is to show the exact command and require explicit approval, and to sandbox with minimal privileges. In a hosted workflow tool, the practical rule is: do not connect a server you cannot account for.
4. A server your client is tricked into calling. The guidance covers server-side request forgery, where a malicious server points a client at internal addresses such as cloud metadata endpoints. Recommended mitigations include HTTPS only, blocking private address ranges and using an egress proxy. This is mainly a concern for whoever hosts the client.
5. Instructions hidden in tool results. This is not in the list above, but it is the one we worry about most. When a tool returns text, such as an email body or a web page, that text may contain instructions aimed at the model. A read-only search tool is low risk. A tool that reads untrusted content and sits next to a tool that sends messages is where trouble starts. The defence is structural: keep untrusted-input tools and consequential tools apart, and put a person between them.
The spec keeps moving#
The specification revision dated 2026-07-28 removes protocol-level sessions and the initialise handshake, deprecates Dynamic Client Registration in favour of Client ID Metadata Documents, and deprecates the Roots, Sampling and Logging features, with a stated minimum twelve-month deprecation window. The changelog is the place to check. For an operations team, the takeaway is simple: ask whoever runs a server which version it supports, and expect to update it.
A short review you can run before connecting a server#
- Who runs it? A named company or team you can contact, or an anonymous package?
- What does it expose? Read the tool list. Is there anything that deletes, sends or pays?
- What credential does it need? Is it scoped, and can you revoke it?
- Where does the data go? Does the server call other services on your behalf?
- Can you see the calls? Check the run trace after a test.
- Who owns it internally? Write down one name.
Where the human goes. Before the first connection, a person from IT or security signs off on the server, not the workflow builder alone. And at run time, any MCP tool that sends, changes or deletes gets an approval step in front of it, at least until you have weeks of clean history.
What MCP does not solve#
MCP standardises how a model asks for something. It does not decide whether it should be allowed. Access control, approval and logging are still your job, and a connected server is a new way in, not a safer one. Treat it as you would a new vendor integration, because that is what it is.
Sources#
- Model Context Protocol, "What is the Model Context Protocol?": https://modelcontextprotocol.io/docs/getting-started/intro
- Model Context Protocol, "Security Best Practices" (specification 2025-11-25): https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices
- Model Context Protocol, changelog for specification revision 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/changelog
