Enterprise-ready MCP // Jiquan Ngiam

The Paradigm Shift: From Static Code to Dynamic Agents

We are in the midst of a fundamental shift from static programs, where developers write explicit lines of code, to dynamic, goal-oriented agents driven by natural language. This transition, sometimes called the move from Software 1.0 to 2.0, democratizes software creation, allowing non-technical business users to specify logic and automate complex workflows. However, this newfound flexibility is a dual-edged sword, introducing powerful capabilities alongside significant, unpredictable risks.

The core challenge lies in the loss of predictability. While we can statically analyze traditional code to understand all possible execution paths, an agent’s behavior is emergent and non-deterministic. This creates a new set of security and governance challenges for enterprises.

A Framework for Agent and MCP Risks

The risks associated with deploying agents and Model Context Protocols (MCPs) can be categorized into three main areas:

1. Supply Chain Risk

The MCP ecosystem is experiencing explosive growth, with tens of thousands of servers available across various registries. This “wild west” environment makes it incredibly difficult for developers and organizations to determine which MCPs are legitimate and secure. A search for a common tool like an “SEO data MCP” can yield multiple, identically named options with no clear indication of the official or trustworthy version.

This creates a fertile ground for supply chain attacks. A real-world example was the postmark-mcp-server package on npm. Initially appearing legitimate, its creator later injected a single line of code that BCC’d an attacker on every email sent through the MCP. This type of “rug pull” attack highlights a critical principle: “When you install an MCP, you should think of it as effectively giving the MCP author… full control of your agent.” If the MCP code runs locally, you may also be giving them full control of your computer.

2. Third-Party Data Risk

Even if you trust the MCP and its author, you are still exposed to risks from the data it returns. An MCP’s tool responses can be manipulated to include hidden instructions that hijack the agent’s behavior.

In a proof-of-concept demonstration, an agent using Claude Code was given a seemingly benign task to send feedback through a documentation MCP. The MCP’s response, however, contained an injected prompt cleverly disguised as a request from “your IT enterprise team.” This malicious prompt instructed the agent to find and exfiltrate sensitive data, such as OPENAI_KEY and GOOGLE_KEY, from the local environment. This activity is often hidden from the user’s view, requiring them to actively inspect the full tool output to notice the data exfiltration.

3. Inadvertent Adversarial Agent Risk

Agents are optimized to be helpful and follow instructions, a trait that can be exploited. An agent doesn’t need to be malicious to cause harm; it can do so by simply being obedient. For instance, if a user asks Claude Code to “read my environment files,” the agent will willingly comply to be helpful, exposing secrets and credentials stored within. This behavior, while not intentionally malicious, presents a significant security breach in any production environment.

Strategies for Enterprise Readiness

To navigate this new landscape, enterprises must adopt a proactive security posture built on three pillars:

1. Monitoring via Gateways

You cannot govern what you cannot see. The foundational step is to implement a gateway architecture that sits between agents and the LLM provider. This gateway acts as a central monitoring and control point, inspecting all agent activity in real-time, including every tool call and tool response.

By monitoring this traffic, organizations gain visibility into what agents are actually doing across the enterprise—such as attempting to read environment files, run sudo commands, or access secrets from cloud providers. This visibility allows for the creation of dynamic rules. For example, a rule can be set to intercept any command attempting to read a .env file and return a revised message to the agent stating that the action is forbidden, effectively blocking the behavior before it occurs.

2. Implementing Guardrails with Hooks

Beyond monitoring, active prevention can be implemented using “hooks”—code that executes before an agent performs a specific action. For example, a beforeReadFile hook can be installed in an agent environment like Cursor. When the agent attempts to read a file, the hook first scans its contents for secrets.

This scanning should leverage both file-naming conventions (e.g., blocking .env, secrets.json) and content analysis (e.g., using regex for key patterns like AKIA... or entropy analysis). Crucially, this content scanning must happen locally on the user’s machine to ensure sensitive data never leaves the trusted environment.

3. Secure MCP Deployment

The current ad-hoc model of deployment—where any user can connect any agent to any MCP—is unsustainable. A mature strategy involves two key components:

• Curated Catalogs: Enterprises should maintain a private, vetted catalog of approved MCP servers that teams are allowed to use.
• MCP Gateways for Granular Access Control: An MCP gateway should mediate all connections, enforcing role-based access control (RBAC) at the tool level, not just the server level. For example, a product manager and an engineer might both need access to the GitHub MCP. The gateway can be configured to allow the PM to use tools that read pull request data but block them from using tools that modify or merge code, a permission reserved for the engineer. This ensures that users and agents have access only to the specific functionalities required for their role, dramatically reducing the potential attack surface.

• Tags:
• AI Agents
• LLM
• Prompt Injection
• Security
• Enterprise AI
• Model Context Protocol