Operationalizing AI: A CISO's Guide To Adopting MCP With Confidence

Forbes

4 hours ago

CTO at SGNL. Inventor of CAEP. Okta Identity 25 Listee. Standards guy at OpenID. Believes access control is critical to cybersecurity.
The technology world is abuzz with the development of the model context protocol (MCP) because it unlocks powerful interactions between large language models (LLMs) and existing enterprise services. The perils of unauthorized data access can dampen enterprises' enthusiasm for adopting MCP. The result is that the promised productivity benefits of AI are harder to achieve, while simultaneously, the unauthorized use of internal data by employees using personal AI accounts grows.
Here's what your organization can do to adopt AI and MCP with confidence and provide a secure alternative to unauthorized AI usage.
A Quick Recap
Large language models are a popular AI technology. A specialized class of LLMs is 'generative pre-trained transformers' (GPTs). Fundamentally, a GPT's behavior is like autocomplete in a word processor: By looking at the preceding text, it can predict the text that follows. The preceding text is called the context, in which the immediate prompt that you type is a part. The latest versions of GPTs are better at step-by-step reasoning, especially when prompted to 'think step by step,' allowing them to break down complex questions into logical steps before answering.
Some GPT-enabled services (like ChatGPT with browsing or plugins) integrate external tools that fetch web results and supply them as context for the model to reason over. For other data that users want to bring into the context, they retrieve it themselves and provide it to the GPT. This is called 'retrieval augmented generation' (RAG), which is often automated in enterprises by external systems integrated with the LLM. Instead of this custom way of retrieval, the model context protocol provides a standardized protocol for the LLM (i.e., the model) to discover tools and resources provided by MCP servers that are available to it and communicate with them to form the context. Hence, the model context protocol.
Pitfalls In Enterprise Use Of MCP
Everyone is predictably excited about MCP because it unleashes a powerful way to enrich the capabilities of GPTs. If a GPT determines the several steps required to answer a question, it can reach out to the relevant MCP servers that can provide the context for each one of those steps in order to generate the answer.
The trouble is, how can an enterprise ensure that the data being requested and fetched by the LLM is, in fact, permitted for the user to be retrieved? If the MCP server can modify data, then how can the enterprise ensure the user has the permissions to make those modifications?
While this seems like a simple authorization question, it gets a bit more involved:
• MCP servers cannot run with more access than the requesting user because each user's permissions may be different. So each MCP query must run with the requesting user's privilege.
• Since user privileges are dynamic (someone working on a specific customer's case today may not have a need to access that customer's data tomorrow), it follows that MCP servers need to understand what a user has access to at the time of the query.
• Enterprises often run in a permissive environment, providing users broad access based on their job function (or, often, their previous job functions too). Often, this includes sensitive customer or internal data. Human users are judicious in their use of such data in their output. Because MCP puts this same access in the hands of LLMs, the same level of judgment probably will not be exercised by the LLM in determining if some information should or should not be used.
• Thus, MCP defeats the de-facto 'security through obscurity' operating model. Users won't try multiple ways of obtaining information they are not supposed to, whereas LLMs will try solving the problem in many different ways before giving up. So, if the data is accessible to the MCP server, it will find its way into the answers, revealing information it should not.
Securing MCP usage
Implementing the following strategies can help secure MCP for organizational use:
In order for enterprises to effectively use MCP, they must adopt a 'zero standing privilege' access control strategy. Unlike in the conventional model, with 'zero standing privilege,' at any given time, the user will only have access to the data that they need to complete the specific task they are currently working on.
This lays the foundation for ensuring that MCP servers do not accidentally provide data that should not be available in producing an answer.
ZSP automatically implies a dynamic access control strategy because it is impossible for anyone to manually update users' permissions to what they need at any given moment.
And one more thing: ZSP is great for defending against cyber breaches, too, because attackers assuming employee identities are unable to access a lot of data and cause a lot of damage.
LLMs acting on behalf of a user should not be able to discover tools within MCP servers that the requesting user should not have access to at the time of execution. This can be done by ensuring that the 'list tools' call made by the MCP client is authorized using the user's identity so that the MCP server can appropriately hide tools that are not to be used by that user.
MCP Servers must execute with the requesting user's privileges because if they have their own elevated privileges, then it will be hard for the downstream services to figure out what data should or should not be provided. Having the entire chain execute as the user also makes it easier to audit data usage across all systems.
Conclusion
MCP is a promising technology, and harnessing it with the right security guardrails can unleash employee productivity while clamping down on unauthorized AI usage. Adopting a zero standing privilege strategy with appropriate controls over MCP servers can help organizations deploy MCP with confidence.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?