Secure MCP Servers Before AI Agents Touch Business Systems

Tools & Technical Tutorials

25 May 2026 | By Ashley Marshall

MCP makes AI agents useful by giving them tools. It also gives attackers a cleaner route into email, files, CRM, databases and production systems if permissions are treated as a convenience setting.

MCP turns tool access into a security boundary

The Model Context Protocol is useful because it gives AI agents a standard way to call tools, read resources and work across systems. That is also why it deserves the same security attention as identity, API gateways and privileged automation. Once an agent can call a Gmail tool, query a CRM, update a ticket, write to a file share or run a database command, the model is no longer just producing text. It is operating inside business systems.

The official MCP authorization specification now frames a protected MCP server as an OAuth 2.1 resource server and the MCP client as an OAuth 2.1 client. It also requires protected resource metadata, authorization server discovery, HTTPS communication, PKCE support and secure token storage. Those details matter because they move MCP away from local developer convenience and into enterprise identity territory. The question is not whether an agent is clever enough to use a tool. The question is whether that tool is safe to expose to a probabilistic system that can be influenced by prompts, retrieved documents, emails and web pages.

This is the point many business deployments miss. A connector list is not a permission model. Connecting an agent to Microsoft 365, HubSpot, Salesforce, Slack, SharePoint, GitHub or a Postgres database creates a chain of delegated authority. If that authority is broad, persistent and shared between multiple workflows, the organisation has created a new privileged automation account without the normal guardrails. That is why MCP reviews should sit alongside identity and access management, not inside a general AI experimentation backlog.

In practice, before any agent reaches a live SaaS account, build a register of MCP servers, the tools each server exposes, the data classes each tool can reach and the exact action types allowed. Pair that with a deployment route similar to structured agent testing environments: sandbox first, read-only first, limited users first, then production with release gates. MCP is not inherently unsafe. Unmapped authority is unsafe.

Source: MCP authorization specification.

The current MCP ecosystem has real auth weaknesses

This is not theoretical risk dressing. A May 2026 measurement study of real remote MCP servers identified 7,973 live remote MCP servers and found that 40.55 percent exposed tools without authentication. Among 119 OAuth-enabled MCP servers the researchers could test, every server had at least one flaw, with 325 flaws in total. Dynamic client registration flaws affected 96.6 percent of those tested servers. The paper also says responsible disclosure produced 9 CVE IDs. Those figures should change how leaders read a proof of concept. If the MCP server is remote, public or shared, auth quality is not a detail to tidy up later.

There are two lessons here. First, agent infrastructure is moving faster than its operational controls. OAuth appears familiar, but MCP creates different deployment conditions: open client environments, delegated authorization and dynamic clients that may have no prior relationship with the server. Second, the practical failure mode is not only account takeover. It is ordinary business data leaving through a tool call that looked legitimate to the system receiving it.

The supply chain side is just as important. In 2025, a malicious npm package impersonating a Postmark MCP server reportedly copied the legitimate project and later added a single line that BCC'd outgoing emails to the attacker. SC Media reported that 15 earlier versions had been uploaded without the malicious code before version 1.0.16 introduced the backdoor. That pattern matters because businesses often approve connectors by name. The name is not enough. The package source, publisher history, version pinning, signatures where available, dependency tree and outbound network behaviour need to be reviewed before the connector is trusted.

For UK firms, the business implication is blunt: if an AI agent can read invoices, customer complaints, HR records or commercial email, a tool permission failure can become a personal data breach, a confidentiality breach or a client trust issue. That makes MCP server selection a procurement and security decision, not just a developer choice. Start with remote servers that support proper OAuth 2.1 patterns, avoid unauthenticated servers, disable dynamic registration unless you have a strong reason for it, and pin approved versions through your normal software supply chain process.

Sources: arXiv MCP authentication study and SC Media report on the fake Postmark MCP package.

Least privilege has to be tool-level, not account-level

The most common permission mistake is to grant the agent the same broad access a human administrator uses during setup. That may feel efficient in a pilot, but it creates the wrong baseline. The agent then inherits permissions it does not need, the pilot becomes a production dependency, and no one can later explain why a customer support agent also had export access to every contact, marketing list and sales note.

OWASP's MCP guidance calls out privilege escalation through scope creep. Its examples include repositories, cloud APIs, ticketing and CI/CD systems, where small permission increases can combine into a much larger attack surface. The recommended controls are direct: define minimal permissions per agent before deployment, map intended actions to explicit scopes, prefer fine-grained scopes, and enforce policies as code so over-broad configurations fail review. That is exactly how business leaders should think about tool access. A finance reconciliation agent might need to read invoices and draft a variance note. It does not need to send emails, create suppliers, update bank details or delete records.

The practical pattern is to split permissions by job, action and environment. Use separate agent identities for sales research, service desk triage, finance analysis, content drafting and operations reporting. Give each identity the narrowest OAuth scopes possible. Prefer read-only tools until the workflow has been tested with real failure cases. Where write access is needed, split draft, submit and execute. An agent may draft a CRM update, but a human approves it. An agent may prepare an email, but sending to external recipients needs a policy gate. An agent may query a database view, but not the raw production database.

There is a counterargument: too many permissions and approval gates slow the agent down, undermining the point of automation. That is true if the design is clumsy. It is not true if the workflow is scoped properly. The answer is not to give every agent admin access. The answer is to design smaller workflows with fewer tool choices, clear escalation paths and measured approval thresholds. If the business case only works when the agent has unrestricted access, the use case is not mature enough for production.

Source: OWASP MCP scope creep guidance.

UK governance means data protection, not just cyber hygiene

UK businesses should treat MCP security as a data protection issue as well as a cyber issue. When agents access SaaS systems, CRM records, email, shared drives or databases, they may process personal data. That means the organisation still needs a lawful basis, purpose limitation, data minimisation, security controls, processor clarity and accountability. The agent does not make those duties disappear. It can make them harder to evidence because decisions and tool calls happen across several systems at speed.

The ICO's AI guidance says accountability makes organisations responsible for complying with data protection law and demonstrating that compliance in AI systems. It also says data protection by design and default becomes more important, even while AI's technical complexity can make that harder to show. For many AI uses, the ICO expects a DPIA where processing is likely to create high risk to rights and freedoms. Its DPIA guidance asks organisations to describe how data is collected, stored and used, the volume and sensitivity of data, the relationship with individuals, the intended outcomes and the level of human involvement.

That maps neatly onto MCP. A meaningful DPIA or internal risk assessment should not simply say the agent uses a CRM connector. It should state which fields are accessible, whether special category or sensitive data can be reached, whether customer files are included, whether the agent can export data, whether prompts or retrieved content leave the UK or the organisation's chosen processor chain, and how individuals would reasonably expect that processing to occur. It should also identify the controller, processor and any joint controllership questions if a third-party AI platform operates the MCP server.

Data minimisation is particularly relevant. The ICO reminds organisations that UK GDPR requires personal data to be adequate, relevant and limited to what is necessary. In MCP terms, this means using narrow database views, field-level access, filtered file scopes, redaction where practical and separate tools for sensitive records. Do not give an agent full mailbox access if it only needs a labelled support queue. Do not expose the whole file system if it only needs a project folder. Do not allow raw data export where a summarized result is enough.

Sources: ICO AI accountability guidance and ICO AI security and data minimisation guidance.

Approval gates and audit logs are part of the product

Security reviews often focus on authentication and forget operational evidence. That is a mistake. If an AI agent updates a deal stage, sends an email, changes a permission, edits a file, triggers a workflow or queries sensitive records, the organisation needs to know who authorised the action, which agent identity acted, what tool was called, which data was accessed, what prompt or task caused it, what output was returned and whether a human approved the final step.

The May 2026 Five Eyes guidance on agentic AI, co-authored by UK NCSC and other national cyber agencies, is useful because it frames agents as systems with external tools, external data sources, memory and action privileges. It highlights privilege risks, increased attack surface, indirect prompt injection through external data sources and the need for layered defence, strict access controls, human control and oversight. It also recommends threat modelling because an agent can significantly change the threat picture when added to an existing system.

That means auditability cannot be added after the launch. The MCP layer should emit structured logs for authentication events, token issuance, tool calls, parameters, data classes touched, outputs, approvals, denials, errors and revocations. Logs should be retained long enough for incident investigation and compliance evidence. They should be searchable by agent identity, user, customer, system, tool and time window. Crucially, logs must not become a new leak. Avoid storing full prompts or tool outputs containing personal data unless you have a clear retention basis and access controls around the logs themselves.

Approval gates should be risk-based, not theatrical. Low-risk read-only retrieval may only need monitoring. External email, customer record changes, payment-related actions, user permission changes, production deployment, bulk exports and deletion should require human review, policy approval or a separate workflow. This is where businesses should connect MCP governance with agent handoff protocols. If the agent cannot complete a task within its authority, it should hand off with context, evidence and a proposed action, not improvise around the control.

Source: Careful adoption of agentic AI services.

A practical pre-launch checklist for MCP servers

A good MCP security review is not a long theoretical document. It is a decision gate before the agent touches real systems. Start with inventory. List every MCP server, transport, hosting location, maintainer, package source, version, dependency set, outbound domain, authentication mechanism and connected business system. Mark whether it is local, remote, vendor-managed, self-hosted or community-maintained. Community servers are not automatically bad, but they require supply chain scrutiny before they are allowed near business data.

Second, define identities and scopes. Every production agent should have a unique identity. Avoid shared service accounts, reused personal OAuth grants and long-lived static API keys. If OAuth is used, require HTTPS, PKCE, exact redirect validation, short-lived access tokens, refresh token rotation for public clients and revocation. Request only the scopes needed for the workflow. Where the provider only offers coarse scopes, compensate with middleware controls, restricted data views or a decision not to connect that system yet.

Third, threat model the workflow. Ask how a malicious email, poisoned document, hostile website, compromised MCP package, stolen token or confused user instruction could cause harm. Then decide what fails closed. Can the agent send to an external domain without review? Can it export a customer list? Can it change a database record? Can it call another tool after reading untrusted content? Can it retain sensitive context in memory? A secure design has explicit answers rather than relying on the model to behave sensibly.

Fourth, test with realistic cases. Include prompt injection hidden in documents, misleading customer emails, ambiguous instructions, revoked credentials, expired tokens, missing data, rate limits and attempts to cross from read-only to write actions. Record failures and fix permissions before production. Fifth, prepare incident response. Know how to disable an MCP server, revoke tokens, rotate secrets, identify affected records, preserve logs and notify the right people. The first serious incident should not be the first time the business learns where agent credentials are stored.

Finally, review regularly. MCP servers change, SaaS permissions change, agents gain new tools and teams widen use cases. Treat agent permissions like cloud IAM: reviewed on a schedule, monitored continuously and retired when no longer needed. That is how MCP becomes a controlled integration layer instead of an unmanaged side door into the business.

Related research: formal MCP security framework.

Frequently Asked Questions

Is MCP secure enough for business use?

MCP can be secure enough when it is deployed with proper identity, OAuth controls, scoped permissions, logging and approval gates. The risk comes from unauthenticated servers, broad scopes, unvetted community packages and agents connected to live business systems before controls are ready.

Should we allow AI agents to use CRM tools?

Yes, but start with read-only access to a limited data view. Move to write access only after testing, approval routing, field-level restrictions, audit logs and rollback processes are in place.

Are OAuth scopes enough to control agent permissions?

No. OAuth scopes are necessary, but they are not the whole control model. You also need tool-level policy, data minimisation, approval gates, monitoring, token lifecycle controls and a review process for changing scopes.

What is the biggest MCP security mistake?

The biggest mistake is treating an MCP connector like a harmless plugin. Once the connector can read or change business systems, it should be reviewed like privileged automation.

Do UK businesses need a DPIA for AI agents?

Often, yes. If the agent processes personal data in a way likely to create high risk, a DPIA is legally required. Even where it is not required, a DPIA-style assessment is useful evidence of purpose, data flows, risks, controls and human involvement.

Can prompt injection bypass MCP permissions?

Prompt injection cannot grant permissions the agent does not have, but it can misuse permissions the agent already has. That is why least privilege and approval gates matter more than prompt wording alone.

Should we use community MCP servers?

Only after supply chain review. Check the maintainer, package source, version history, dependencies, signatures where available, outbound network behaviour and whether the server supports the authentication controls your business requires.

What should be logged for MCP tool use?

Log agent identity, user context, tool name, parameters, data classes accessed, output summary, approval status, errors, token events and revocations. Avoid storing unnecessary personal data in logs.