The short answer
Secure an MCP integration at the same boundaries as any business application: identity, authorisation, data access and actions. Connecting an AI assistant to a tool does not give that assistant permission to do everything the tool supports. Define a narrow job, enforce access on the server and test how the integration behaves when access is missing or revoked.
What the protocol does and does not decide
Model Context Protocol provides a common interface between AI applications and tools. It does not replace your product’s permission model. A sales assistant that can look up a customer should not automatically be able to export every customer or change account ownership. Those are separate business decisions.
The MCP security guidance identifies risks including token passthrough, confused-deputy attacks and server-side request forgery. Its draft documentation is evolving; check the version your implementation targets. Read the MCP security guidance.
Define a useful permission boundary
Our recommended starting point is a written tool inventory. For each operation, record the user identity, allowed data, permitted changes and approval requirement. Start a knowledge assistant with read access to a specific collection. Add write access only when a clear use case needs it and the relevant owner accepts the workflow.
- Keep tenant and record checks inside the tool’s server implementation.
- Use separate operations for reading, preparing and committing changes.
- Make approval refer to the exact action and parameters being submitted.
- Decide who can revoke access and how quickly revocation takes effect.
Validate credentials at the boundary
The MCP documentation explicitly rejects passing through tokens that were not issued for the MCP server. Validate the intended audience and applicable permissions before accepting a request; use the appropriate authorised flow for downstream services. The same document explains why unclear token boundaries weaken accountability. See token passthrough guidance.
For your implementation review, trace one request end to end. Identify where credentials are stored, which service receives each token, and what reaches logs. A developer should be able to explain this path without needing to expose the secret itself.
Test more than a successful connection
Use a staging environment with synthetic data. Try a user from another tenant, an expired session, a revoked permission and a request that changes parameters after approval. Each denied request should leave a useful diagnostic trail without leaking another customer’s information.
Also test untrusted instructions inside retrieved documents. OWASP describes indirect prompt injection as a route to unauthorised actions through connected tools. Tool permissions and approval checks must remain effective even when the model follows an unexpected instruction. Read the prompt injection guidance.
Make ownership explicit
Before release, name the owner of the integration, its permission settings and its incident response. Record how to disable the connection while preserving records needed to investigate an issue. Review access whenever the tool’s capabilities expand.
Is a read-only connection enough?
It reduces the ability to change systems, but sensitive information still needs access controls. Scope reads to the records the user is allowed to see.
New to the protocol? Read our MCP introduction. For an existing product, discuss the integration and its constraints with us.
