To secure an MCP server before it touches business data, treat every tool it exposes as code that can act on your systems. Use a maintained server, require OAuth with tokens issued only for that server, grant the narrowest scopes, put human approval on writes, validate inputs and outputs, and log every tool call.

Picture a sales team that wants its AI assistant to look up deals, update contact records and log calls in the CRM. Someone finds an open source MCP server for that CRM, pastes an admin API key into a config file, and the demo works by lunchtime. The assistant can now read every customer record, and it can also change or delete them. Nobody has written down who approved that, which tools the agent may call, or where the record of those calls lives.

Two government documents published this spring explain why that setup is risky.

What is an MCP server, and why does it change your security model?

An MCP server is a small service that exposes tools and data to an AI model through the Model Context Protocol (MCP), an open standard for connecting AI applications to outside systems. Once an agent is connected, the model decides when to call those tools, so the server's permissions become the agent's permissions.

The specification is direct about the risk. Its security section says "tools represent arbitrary code execution and must be treated with appropriate caution", and that "hosts must obtain explicit user consent before invoking any tool". It also says that MCP "cannot enforce these security principles at the protocol level". Those controls are left to whoever builds and runs the server and the client.

Authentication is optional too. The MCP authorization specification states that "authorization is OPTIONAL for MCP implementations". A server can run with no login at all, and many do.

For a CRM, the question is no longer whether a person can see a record. It is what an automated caller, acting on instructions it may have read in an email, can do with your whole customer database.

What did the NSA and Five Eyes guidance say about MCP?

Both documents say the same thing at heart: agents and MCP are already in production, and security practice has not kept up.

The NSA information sheet (May 2026)

In May 2026, the NSA's Artificial Intelligence Security Center released a Cybersecurity Information Sheet, Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation. Its summary says "MCP's rapid proliferation has outpaced the development of its security model", and its section on access control notes that "many implementations omit authentication entirely".

The sheet's recommendations include:

• choose supported MCP projects, and apply your strictest code review to new ones

• design trust boundaries, and keep tools that touch sensitive data apart from tools that touch public data

• validate every tool's parameters against defined schemas

• constrain and sandbox tool execution, and run agent processes with least privilege

• sign MCP messages, and add expiry and replay protection

• treat every tool and model output as untrusted input to the next step

• log all tool and model calls, with parameters and identities

• track and patch MCP vulnerabilities, and keep an inventory of servers

• scan your own network for unauthenticated or unauthorized MCP servers

The Five Eyes guidance (May 2026)

On 1 May 2026, six agencies published Careful adoption of agentic AI services. The authors are Australia's ASD's ACSC, the US CISA and NSA, the Canadian Centre for Cyber Security, New Zealand's NCSC-NZ and the UK's NCSC. It covers AI agents in general rather than MCP alone. The agencies recommend "never granting it broad or unrestricted access, especially to sensitive data or critical systems", and advise organisations to "deploy agentic AI incrementally, beginning with clearly defined low‑risk tasks".

Which MCP server should you connect to your CRM?

Connect a server that is maintained, that you have reviewed, and that you can run under your own control.

Check where it comes from

The NSA sheet points out that many popular MCP servers are no longer maintained, and that the MCP project keeps a list of archived servers. Prefer the CRM vendor's own server or a maintained reference implementation. Have someone read the code, check how it stores credentials, and note the version you approved.

Decide where it runs

For private data, the NSA advises preferring a local instance of the MCP server over a shared or public one. "Local" here means inside your own environment, under your own access rules and network controls. The NSA also suggests a filtering outbound proxy, so the server can only reach the addresses it needs.

Keep an inventory

List every MCP server in use, who installed it, which systems it touches and which version is running. The NSA also recommends regular scans of your own network for MCP servers that are unauthenticated or were installed outside change control.

How should authentication and permissions work?

Every request should carry a token issued for that specific MCP server, allowing only what the current task needs.

Use the MCP authorization flow

For servers reached over HTTP, the authorization specification builds on OAuth 2.1, an industry standard for granting limited access without sharing passwords. MCP servers "MUST validate that access tokens were issued specifically for them". The security best practices page is plain about the shortcut it forbids: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." Passing a client's token straight through to the CRM breaks your audit trail.

Start with read-only scopes

A scope is a named permission inside a token, such as read contacts or update deals. The specification recommends a minimal starting set of low-risk read operations, with more access requested only when a specific action needs it. It lists wildcard scopes and "bundling unrelated privileges" as common mistakes. For a CRM, start the agent on read access to the objects it actually uses. Add write access one object at a time, and never grant delete or export rights to the agent.

Give the agent its own identity

Create a dedicated user or service account for the agent, separate from any person's login. The Five Eyes guidance recommends replacing "static, long-lived secrets with ephemeral credentials that expire when the job is complete". It also means the CRM's own history shows the agent as the actor.

Where should humans approve what the agent does?

A person should approve any action that is hard to undo or that reaches outside the company. Scoped reads can run on their own; changing, deleting or sending data needs a checkpoint.

Put approval in the design, not in the prompt

The Five Eyes guidance says decisions about when human approval is required should be "determined by system designers or operators, not delegated to the agentic AI system". In practice that means the approval step sits in your application or workflow tool, outside the model's control. The agent proposes a change, a person sees exactly which record and which fields will change, and nothing is written until they confirm. The same guidance names the deletion of critical records as a case for human review, and says requests to delete logs or audit records should wait until a person approves them.

Treat what comes back as untrusted

The NSA sheet says "outputs from tools and models should never be treated as implicitly trusted". A CRM is full of text written by outsiders: email bodies, form submissions, notes from calls. Any of it can contain instructions aimed at the agent, which is called prompt injection. The MCP specification adds that tool descriptions should be treated as untrusted unless they come from a trusted server.

Review changes to a trusted server

The NSA sheet warns that a server you approved can later gain new capabilities or data access without a new approval. Pin the version you reviewed, and repeat the review when it changes.

What should you log and check before go-live?

Log every tool call with its parameters, the identity behind it and the result, and send those logs to the same place your security team already watches. Then check the list below before the agent touches real customer data.

The NSA sheet recommends logging "the exact parameters, identities involved, and (where feasible) cryptographic hashes of results or output", and feeding that telemetry into existing monitoring such as a Security Information and Event Management (SIEM) system.

MCP security checklist for a CRM connection

1. The server is maintained, reviewed and pinned to a known version.

2. It runs in your own environment, with outbound traffic limited to the addresses it needs.

3. OAuth is on, and the server accepts only tokens issued for it.

4. The agent has its own identity and short-lived credentials.

5. Scopes start read-only, with no delete or bulk export.

6. Writes, deletions and outbound messages wait for human approval in the workflow.

7. Tool inputs are checked against a defined schema, and outputs are treated as untrusted.

8. Every tool call is logged with parameters, identity and result.

9. The server is on your inventory, and someone is responsible for patching it.

10. You can turn the connection off in one step.

How we approach it at Vizio AI

We start by mapping what the agent needs to do in the CRM, object by object and action by action, and we write down which actions read, which change and which can't be undone. That list becomes the scope and approval design.

We prefer the CRM vendor's own MCP server or a small server we write and review ourselves, run in the client's environment. The agent gets its own identity, read-only scopes first, and a human checkpoint on every write until the logs show it behaves as expected. Logging goes into the client's existing monitoring from the first day, and we agree up front who owns the server, its patches and its inventory after handover.

This is part of the work in our DX Studio. If the agent is part of an app built with AI tools, Your AI-Built App Works in the Demo. Here's What Breaks With Real Users covers the other launch risks, and Why Projects Built With Claude or Codex Stall Before Launch explains where those projects usually get stuck.

Sources

• NSA, Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (Cybersecurity Information Sheet, May 2026): https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf

• NSA, press release on the MCP information sheet (May 2026): https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4496698/

• ASD's ACSC, CISA, NSA, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK, Careful adoption of agentic AI services (1 May 2026): https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/careful-adoption-of-agentic-ai-services

• Careful adoption of agentic AI services (PDF): https://www.cyber.gov.au/sites/default/files/2026-05/careful_adoption_of_agentic_ai_services.pdf

• CISA, Careful Adoption of Agentic AI Services: https://www.cisa.gov/resources-tools/resources/careful-adoption-agentic-ai-services

• Model Context Protocol, Specification (version 2026-07-28): https://modelcontextprotocol.io/specification/2026-07-28

• Model Context Protocol, Authorization: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization

• Model Context Protocol, Security Best Practices: https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices