AI agents connected to ERP and CRM via MCP: security risks and the controls to put in place

An AI agent that reads orders from your ERP and updates customer records in the CRM on its own saves hours of copy and paste every week. The same agent, if poorly configured, can read data it has no business seeing and write where it shouldn't, perhaps following instructions it found in the text of an email. The connection between the model and business systems increasingly runs through the Model Context Protocol, and so do the risks.

In April 2026 CERT-AgID published a security analysis of open source MCP implementations, later covered by Agenda Digitale. The study is a good starting point if you are evaluating a project of this kind, although it covers only part of the problem: other significant risks emerge from real cases documented elsewhere.

What the Model Context Protocol is, with an ERP to CRM example

MCP is an open standard that defines how an AI assistant connects to the systems where data lives: document repositories, business tools, development environments. It was introduced by Anthropic in November 2024, together with a specification, SDKs and a collection of open source servers. Since 9 December 2025 it has been managed by the Agentic AI Foundation, set up within the organization that oversees Linux development alongside Block's goose and OpenAI's AGENTS.md.

The way it works is fairly simple: the language model reasons and decides; the MCP client, meaning the application hosting the agent, presents it with the available tools.

Each MCP server exposes one or more tools, functions with a name, a description and parameters, which in turn call the APIs of the actual system.

Consider an illustrative scenario. An MCP server attached to the ERP provides the tool get_daily_orders, while a second one, connected to the CRM, offers update_customer_record. Every evening the agent reads the orders, identifies customers who have crossed a revenue threshold, adds a note for the sales rep and changes the status of the opportunity. Nobody writes a dedicated integration between the two systems: the agent chooses which tools to call and which parameters to pass.

That flexibility is also the problem. The parameters are generated by the model on the fly, based on what it has read, not by a developer at build time.

The CERT-AgID paper describes this as a shift of the security perimeter onto the prompt → tool → action chain.

What CERT-AgID found in open source MCP servers

The 17-page paper focuses on SSRF (Server-Side Request Forgery), the ability to trigger network requests from an internal machine toward destinations chosen by the attacker. The scenario is concrete. An MCP server designed to fetch documentation from remote sources receives the URL as a parameter and uses it without any checks. If the model passes it an internal host, that component becomes an unauthorized proxy inside the corporate network.

Prompt injection appears as the attack vector: a model manipulated by a malicious instruction generates the dangerous URL. Hence the study's conclusion, which calls for treating every input produced by the AI as inherently hostile.

Alongside SSRF, the analysis points to recurring weaknesses in many MCP projects:

• tools that can be called without authentication;
• allowlists written in a way that lets through requests they should block;
• external connections without TLS checks, leaving data open to interception;
• no limit on the number of requests, and therefore exposure to DoS attacks.

The recommendations follow from this. Every parameter should be checked before execution with blocking filters, with no fallback mechanisms that bypass them, and allowlists should be restricted to predefined domains, protocols and formats. The study also calls for assigning a single operation to each tool, making authentication mandatory, applying rate limiting and logging calls so that anomalies can be spotted in real time.

The other risks: external data, third-party servers, exfiltration

The study looks mainly at the individual server. When an agent works on ERP and CRM, many problems come from outside.

The first is indirect prompt injection. The agent reads content that nobody checks upstream: an order note, an email, an attached PDF. Invariant Labs demonstrated this with the official GitHub MCP server: a carefully crafted issue led an agent to disclose private information. The server had no bugs; the content it read was enough. In our scenario, the equivalent would be an order note asking the agent to send the customer list to an external address.

Then there are third-party servers installed without any checks. In September 2025 postmark-mcp came to light, an npm package posing as the integration for a well-known email delivery service: from version 1.0.16, published on 17 September, it secretly copied the messages passing through the tool. According to The Hacker News it had been downloaded 1,643 times, and the company stated that it had no connection with the package.

Exfiltration often results from these two factors combined with overly broad permissions. Admin credentials on the CRM, a tool that can contact any domain and a malicious piece of text read at the wrong moment: the data leaves without anyone having cracked a password. The OWASP Top 10 for Agentic Applications 2026 gives these scenarios names, including agent goal hijack (ASI01), tool misuse (ASI02), identity and privilege abuse (ASI03), supply chain (ASI04) and memory and context poisoning (ASI06).

The controls to plan for in a project

Least privilege for every tool

Each tool does one thing only, with strictly the credentials it needs. In the example, get_daily_orders uses a read-only ERP user restricted to orders; update_customer_record writes notes and changes the opportunity status, without being able to delete contacts or export lists. If a new operation is needed, you create a new tool with its own scope instead of widening the existing one. Parameters are validated server-side: a customer ID must have the format of a customer ID, and a domain must be on the allowlist.

Human approval for irreversible actions

The agency's analysis doesn't cover this, but for us it is a design rule. Deleting a record, issuing a credit note, writing to a customer, changing a price: the agent prepares the action, shows it with the data it will use, and a person approves it. Reversible, low-impact operations, such as adding a note, can run autonomously.

Separate environments

Development and testing take place on copies of the ERP and CRM with anonymized or synthetic data and credentials different from production ones. In prototypes it is common to connect straight to the live system because it is quicker, and that is exactly where a configuration error turns into an incident.

Logging, monitoring and alerts

Every call the agent makes should be logged: the tool used, the parameters, the user or process it acts on behalf of, and the outcome. These logs help you reconstruct an incident and notice it while it is happening. In production, monitoring AI agents relies on simple signals, such as spikes in calls, tools used outside business hours, requests to unexpected domains and repeated authorization errors. Rate limiting acts as a brake when something goes wrong.

A 10-point checklist before connecting an agent to ERP and CRM

1. There is an inventory of the MCP servers in use, with origin, version and owner.
2. Third-party servers are reviewed (code, publisher, pinned version) before installation and at every update.
3. Each tool performs a single operation with dedicated credentials and least privilege.
4. All tools require authentication, including internal ones.
5. Parameters generated by the model are validated server-side with blocking filters.
6. Outbound requests go through allowlists of domains, protocols and formats, with verified TLS.
7. Emails, notes and external documents are treated as untrusted data and cannot trigger sensitive actions on their own.
8. Irreversible actions require approval from a person.
9. Development, testing and production have separate environments and credentials.
10. Every call is logged, with rate limiting and alerts on anomalies in place.

How we handle security from prototype to production

In our agent-based automation projects, security becomes part of the plan at the same time as the choice of process. If you are still deciding where to start, the checklist on which process to automate first with AI also helps you assess the risk: a workflow that reads and suggests is easier to protect than one that writes and sends.

The prototype, ready in 2 to 4 weeks, works on the client's real data but in a separate environment, with read-only credentials wherever possible. At that stage we define the list of tools, the permissions of each one and the actions that require approval. Moving to production adds authentication on the servers, centralized logging and alerts. During ongoing support we review the logs, update the MCP servers in a controlled way and re-examine permissions whenever the agent is given new tasks.

For the security of code written with AI, a different topic from agents in production, you can read our in-depth article on how to integrate AI into development workflows without compromising quality and security. If instead you already have an agent in mind to connect to your ERP or CRM, our free AI assessment lets us work out together which data it touches, which tools it needs and where to place the controls before writing any code.