MCP server security: what to test before connecting company systems
Trace local and remote MCP integrations through credentials, tool permissions and downstream effects, with proposed acceptance tests for a company deployment.
Connecting an MCP server can give an assistant a route into company files, databases or operational APIs. The meaningful security question is which requests it can execute, under whose identity, against which resources—and what happens when an input asks for something outside that authority.
The Model Context Protocol standardises interaction. It does not make every server, tool description or integration trustworthy. Assess the actual client, server, transport, credentials and downstream service as one connected path.
Distinguish a local process from a remote service
A local stdio server runs as a process in its execution environment. Review its launch command, package source and version, filesystem access, inherited environment and network reach. Installing a connector can therefore introduce executable code with access to local resources; a benign display name is not evidence about that code.
A remote HTTP server introduces a different set of questions: its operator, endpoint, authentication, token handling and downstream access. The dated MCP authorisation specification cited below covers HTTP transports; it says stdio implementations should obtain credentials from their environment instead. Record the protocol revision your deployment actually uses.
Trace authority all the way to the resource
Ask whether the server uses the end user’s delegated authority or a shared service identity. With a shared identity, the application may need to enforce distinctions that the downstream API cannot see. A successful login to the MCP server does not establish permission to read every record behind it.
For HTTP authorisation, validate that the token is intended for the receiving resource. MCP guidance prohibits accepting a token issued for another service and simply forwarding it downstream. Where separate downstream credentials are needed, document their acquisition, storage, scope and revocation rather than using token passthrough as a shortcut.
Use an authorised test environment to exercise a valid identity, an expired credential, an incorrect token audience and an identity outside the permitted tenant or resource scope. Confirm the valid path works. For denied cases, check the downstream service as well as the error shown by the client.
Review tools by effect, not by description
Make a tool inventory with the input schema, execution identity, accessible objects and possible side effects. A tool called “search” might query a broad dataset; a reporting tool might also write files or send messages. Compare the advertised purpose with the implementation and the credentials it can use.
Treat retrieved text and tool descriptions as untrusted input to the model. In a controlled fixture, place an instruction in returned content that asks for an out-of-scope action. Observe the proposal and the tool-gateway decision separately. Do not execute that experiment against real recipients or records.
| Boundary | Test | Evidence to retain |
|---|---|---|
| Resource authorisation | Request a synthetic record outside the caller’s assigned scope. | Server decision and confirmation that no record reached the caller. |
| Tool permissions | Ask a read-only workflow to invoke a write-capable action. | Gateway rejection and absence of downstream mutation. |
| Approval | Change a significant argument after a test approval. | A new decision is required; the changed action is not dispatched. |
| Credentials and isolation | Remove authority, then repeat a previously permitted request. | Revocation timing, request identity and downstream result. |
| Supply chain | Review a proposed server/package update before promotion. | Version, provenance, permission changes and regression results. |
Limit the consequences of a compromised integration
For a local server, use a dedicated execution environment with only the files, environment variables and network destinations required for its job. For remote services, separate environments and restrict credential scope. Keep unrelated production secrets out of the server’s process environment.
Review outbound requests, including redirects and any user-controlled URL inputs. MCP’s evolving security guidance discusses SSRF and local-server compromise; whether those risks apply depends on the implementation. Do not treat an endpoint allowlist or container alone as proof that the entire path is safe.
Before rollout, practise disabling the integration and revoking its credentials. Record which pending actions can still complete and how uncertain results will be reconciled. Logging should connect client, tool call and downstream request without copying secrets or sensitive payloads into ordinary telemetry.
Keep a deployment record
Store the server owner, source/package version, transport, protocol revision, credentials, data scope, enabled tools and acceptance results. Re-review when the server, tool schema, execution identity or model-facing instructions change. A one-time approval should not silently cover a broader integration later.
Download the MCP review worksheet (CSV). These are proposed tests; no live MCP product was assessed for this article.
Sources and version boundaries
- MCP authorisation specification, revision 2025-11-25 — dated reference for transport and token boundaries, not a claim that every deployment uses this revision.
- MCP security best practices, draft documentation — evolving guidance read 4 November 2026. Draft guidance is not presented as a final compliance requirement.
The acceptance matrix and deployment record are MicroApz recommendations. Adapt them to your implementation and rules of engagement.