MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

A new connector can move an AI pilot from useful answers to useful actions. It can also connect an untrusted document, a broad credential and a consequential tool in ways the team has not reviewed. Before adding an MCP server, examine the trust boundaries as carefully as the feature list.

The review below is a practical starting point for business and engineering teams. It is not a certification scheme or a substitute for a security assessment. Its purpose is to produce a clear decision about one server, one deployment configuration and one set of business tasks.

1. Establish what you are installing

Record the server’s publisher, source or distribution location, version and operator. If the server launches locally, identify the package and the command used to start it. If it is remote, identify the service endpoint and the organization responsible for operating it. Do not treat a familiar name as proof of provenance.

For a hypothetical procurement assistant, the proposed server might read supplier files and create purchase-request drafts. Write that scope down before testing. If the server also exposes payment changes or unrestricted file access, decide whether those capabilities can be removed or disabled. The review should concern the deployed configuration, not just the intended use.

The official MCP architecture overview explains the host-client-server relationship. Use it to draw which component receives the user request, which runs the server and which holds the connection to the business system. Label every place where data or authority crosses a boundary.

2. Separate the credential path from the data path

List the credentials used by the server and the services for which they are intended. Identify where they are stored, who can retrieve them and how they are rotated or revoked. Avoid placing secrets into prompts or tool results simply because that seems convenient during development.

The MCP security best-practices guidance addresses token passthrough and confused-deputy risks. In practical terms, a connector should not accept or forward credentials without the checks appropriate to the intended service and authority. Have the implementation owner explain these checks using the actual deployment.

Then map the data path. A supplier document may pass from a file store through the connector into an AI application and its logs. Identify which fields are necessary for the task and which destinations are permitted. A credential may be tightly scoped while the returned data is still copied too broadly.

3. Review outbound network behavior

Ask whether the server can fetch arbitrary URLs, follow redirects or contact internal addresses. These capabilities may be legitimate, but they need a reason and controls. A document-search connector should not acquire unrestricted network reach merely because its implementation includes a general-purpose HTTP library.

The official guidance includes server-side request forgery among the threats to consider. Security specialists should test URL handling, redirects and destination restrictions against the organization’s network model. Business owners can help by defining the destinations actually required for the task, rather than approving an undefined category such as “internet access.”

Treat local execution with equal care. A process running beside an employee’s files may inherit more access than a narrow remote service. Inspect filesystem permissions, environment variables and subprocess behavior. Local installation changes the location of the boundary; it does not eliminate the boundary.

4. Test permissions with two users

Create an authorized test account and a second account that should not see the same records. Use synthetic or approved test data. Confirm that a known restricted supplier file is unavailable to the second account, including through search summaries, cached results and follow-up questions.

Test read and write scopes separately. An assistant permitted to prepare a request should not be able to submit it simply by choosing a different exposed tool. If the server relies on an upstream identity, verify that the identity is checked at execution time rather than inferred from a model-generated field.

OWASP’s prompt-injection guidance recommends least privilege and high-risk approval controls. Apply that advice to the connector’s real authority. A malicious instruction in a supplier document should not become permission to email private files or change a payment record.

5. Rehearse revocation and failure

• Revoke the test credential during a task and confirm that subsequent access fails safely.
• Disable the server and inspect how the assistant describes the unavailable capability.
• Return an error or partial result and check that it is not reported as complete evidence.
• Attempt an unauthorized action through an otherwise legitimate conversation.
• Inspect logs for secrets, unnecessary document contents and identifiable test data.
• Confirm who receives the alert and who can disable the integration.

A connector that works only on the happy path is not ready for unattended business use. Failure messages should help the operator distinguish missing permission, unavailable service and uncertain completion. If a write may have succeeded before an error, the recovery plan should verify the destination before repeating the action.

6. Make the approval conditional

End the review with a short decision record. State the approved tasks, permitted data, disabled capabilities, deployment version and known limitations. Name the engineering owner and business owner. Include the conditions that require another review, such as a new server operator, expanded scopes or additional write tools.

Avoid a blanket statement that a server is “secure.” The useful conclusion is narrower: this configuration has been reviewed for these tasks under these controls. A future update can change the risk even when the connector’s name stays the same.

MCP makes integrations easier to describe and connect. A disciplined review makes their authority understandable. Keeping those two ideas separate helps a team gain the benefit of connectivity without quietly granting a new service more access than the work requires.

Sources and further reading

MCP: Architecture overview. Participants and integration boundaries; versioned guidance checked October 2026.

MCP: Security best practices. Token, confused-deputy, SSRF and scope risks; checked October 2026.

OWASP: LLM01 Prompt Injection. 2025 guidance on least privilege and privileged-action review; checked October 2026.