MCP can connect an AI assistant to business tools. It doesn't decide who should be allowed to use those tools or approve the changes they make. Your application still needs to enforce those rules.
“It connects to your CRM” sounds like a feature. Before approving the integration, ask a second question: what exactly does that connection allow?
Can the assistant search one customer's records, or everyone's? Can it draft a reply, send it or change the account? Model Context Protocol, usually shortened to MCP, gives AI applications a standard way to connect with tools and context. For a business buyer, the permissions behind those tools deserve as much attention as the demonstration.
Ask for a tool list you can understand
A tool called “search customers” leaves a lot unanswered. Which fields can it return? Does it use the current employee's permissions? Can it cross between separate customer accounts?
Ask the supplier to list each tool, what it reads, what it changes and what gets recorded. Searching a CRM and updating it should be separate decisions. If the first release is meant to be read-only, there should be no unexpected route to making changes.
The model must not decide who has access
The server needs to verify the caller and check access to the requested records. A customer identifier supplied by the assistant is an input to validate, not evidence that the request is authorised.
That matters particularly in software serving several businesses. Try a test account from one company and request a record belonging to another. The server should reject it even if the model confidently asks for it.
The MCP security guidance covers risks such as token passthrough, confused-deputy attacks and server-side request forgery. These need implementation-level checks. Using a standard protocol doesn't make an integration secure on its own.
A document can contain instructions without having authority
Imagine a support note containing a line that asks the assistant to export account data to an outside address. That line is part of the record being read. It isn't a new request from the user, and it shouldn't become permission to send anything.
Include examples like this in testing, using synthetic records. The assistant should carry on with the legitimate task without following instructions planted in documents or tool results. Test what the server permits too; the model's refusal should not be your only defence.
| Tool | Limit the pilot to | Try to break this boundary |
|---|---|---|
| Search knowledge | Approved public procedures | Retrieve a private document |
| Read a case | The user's assigned cases | Request another company's case |
| Draft a reply | Creating a draft only | Send it without approval |
Keep secrets out of prompts and logs
Credentials belong in approved server-side configuration, not browser code or tool descriptions. Give the connection only the permissions it needs and make sure access can be revoked.
Logging needs some restraint as well. Record enough to explain an action without turning the audit trail into a copy of every confidential record the assistant encountered. Never include passwords or access tokens in ordinary diagnostic messages.
If a tool can fetch a URL, check where it is allowed to connect. An arbitrary address should not become a way to reach private infrastructure. Define and test those network boundaries before the tool reaches live users.
Make approval specific to the action
For a write operation, show what will happen: the recipient, the account, the proposed change. A broad approval at the beginning of a conversation may not cover a consequential action discovered several steps later.
Record approval and execution separately. If the request times out, find out whether the change happened before trying again. The operator should be able to stop a task and see what remains unfinished.
A small pilot is easier to learn from
Begin with a useful read-only task and non-sensitive test records. Check different users, different customer accounts, revoked credentials and unavailable connections. Then consider whether write actions are justified.
For a Gligx AI integration discussion, a tool list and a description of the intended users are a practical starting point. If you're still deciding how much autonomy to allow, read our guide to agents and workflows first.
Sources and further reading
References checked on 23 October 2026.
Frequently Asked Questions
What is MCP, in plain English?
Model Context Protocol gives AI applications a standard way to connect with tools and context. Your business system still has to enforce its own access rules.
Does connecting a tool let the assistant do everything in that system?
It shouldn't. Limit access to the authorised user, records and actions. Treat read access and permission to make changes as separate decisions.
Can we control access just by writing a careful prompt?
No. The server needs to verify the user, check permissions and validate the request even if the model asks confidently for something it shouldn't access.
What is a sensible first MCP pilot?
Choose one useful read-only task with non-sensitive test records. Check user boundaries, logging and revoked access before allowing changes to live records.