Part 2: Understanding and Assessing MCP servers from an AppSec Perspective

This part is the continuation and finalization of our MCP security review series. It also includes several important updates to Part 1 that emerged during further research. Before diving into the corporate landscape, let's revisit local MCP usage - because since Part 1 was published, new tools have emerged that significantly enhance local MCP deployment security.

MCP Gateways: An Update to Part 1

Shortly after Part 1 was published, the Docker MCP Gateway and Microsoft MCP Gateway became available. While primarily aimed at local deployments, their security and operational benefits are worth noting in any environment.

The Docker MCP Gateway is particularly useful for those planning to run MCP servers from the Docker MCP Hub.

It securely stores credentials inside Docker Desktop rather than in plaintext config files, reducing the risk of accidental leaks. It also provides access to Docker's logging capabilities, giving security teams deeper visibility into request flows. In newer versions of Docker Desktop, which now include the MCP Gateway by default, there is also convenient integration with IDEs such as Cursor and others - making setup smoother and more secure.

Microsoft's MCP Gateway offers similar intermediary benefits and can be an excellent option for Kubernetes or other container-orchestrated environments, adding centralized control, observability, and security.

From Local to Corporate Deployments

Transitioning from a local MCP setup to a corporate or multi-user deployment is not just a matter of scaling resources - it's a fundamental change in the threat model, governance, and required safeguards.

OAuth is the recommended standard for MCP authentication (specification), and the official MCP Security Best Practices provide detailed guidance. They identify major risks and mitigations:

• Confused Deputy Problem: Prevent misuse of static OAuth client IDs by requiring user consent for each dynamically registered client.
• Token Passthrough: Forbid passing client tokens directly to downstream APIs without validation.
• Session Hijacking: Use secure, random, user-bound session IDs and avoid session-based authentication.

Mitigations include binding session data to authenticated identities, validating tokens for correct audience, and monitoring for abnormal OAuth flow patterns.

At the moment, GitHub's MCP server offers strong OAuth support, which can be easily configured - even through Docker Desktop with the integrated MCP Toolkit.

This is a good sign for the ecosystem, and hopefully other MCP developers will follow suit by implementing OAuth in their servers.

However, not all MCP servers ship with OAuth support by default like GitHub. This gap often requires introducing OAuth-enforcing proxies or gateways to maintain security. These proxies can:

• Enforce OAuth consent flows aligned with corporate security policies.
• Centralize token management, rotation, and expiration.
• Control access on a per-MCP basis with fine-grained permissions.

Without OAuth, multi-user MCP deployments risk uncontrolled access to connected systems. Proxies like Lunar MCPX or self-hosted reverse proxies with OAuth middleware can mitigate this risk, while also enabling central logging, policy enforcement, and audit trails.

For OAuth implementations, solution such as WSO2 Open MCP Auth Proxy may also be useful.

Building a Secure Corporate MCP

A secure internal MCP deployment is built on layered defenses and a clear operational model:

• Strong Authentication & Authorization: Enforce OAuth for all multi-user MCPs. Require explicit user consent for high-impact actions. Integrate with your corporate IdP (e.g., Okta, Azure AD) where possible. Okta's Enterprise AI security approach provides a useful perspective on implementing OAuth in AI-integrated enterprise environments.
• Service Accounts and Least Privilege: Run MCP servers with dedicated service accounts. Use tokens scoped only to the specific resources and actions they need. Avoid administrative privileges unless explicitly justified.
• Credential Hygiene: Automate token rotation. Implement immediate revocation for compromised or unused credentials.
• Network Segmentation: Place MCP servers in controlled network segments, limiting exposure and defining clear ingress/egress points.
• Secure Communication: Encrypt all MCP traffic with TLS. Where possible, use mutual TLS or signed requests to verify trusted clients. For local MCP Server <-> MCP Client communication, using stdio transport is a good option.
• Monitoring and Anomaly Detection: Feed logs into SIEM systems, track user identity and action details, and alert on unusual behavior patterns.
• Regular Vulnerability Management: Monitor for new MCP-related CVEs. For example: CVE-2025-6514 (Critical RCE in the mcp-remote project - a popular tool used by Model Context Protocol clients), CVE-2025-49596 (RCE in MCP Inspector, a tool for testing and debugging MCP servers), CVE-2025-5277 (CMD injection in aws-mcp-server).

These are reminders that MCP, like any internal application, requires active patch management and incident readiness.

Full AppSec Review Checklist

Here’s the complete MCP AppSec review checklist, combining both parts:

• Review documentation and access control logic, including vendor security notes.
• Determine usage context (local, departmental, corporate, external).
• Perform manual and SAST-based source review.
• Inspect prompt handling for injections and tool poisoning.
• Deploy and test the MCP server, observing requests.
• Use MCP Guardian or similar tools to restrict agent actions.
• Apply least privilege to all tokens.
• Pin and version-control reviewed 3rd-party MCP builds.
• Use an artifact management tool or internal MCP hub to allow only approved MCP server and tool versions.
• Enforce OAuth and logging for all multi-user deployments.
• For multi-user deployments, implement a centralized solution such as a proxy.
• Track CVEs and patch promptly.
• Log all usage and monitor anomalies.
• Verify trust boundaries of downstream APIs.
• Centralize token management and rotation.
• Periodically review and adjust permissions.
• For local MCPs, use Docker Desktop with built-in Gateway - ideal for MCP servers from Docker MCP Hub, providing centralized credentials, logging, and IDE integration.
• For Kubernetes or distributed deployments, use Microsoft MCP Gateway for centralized control and security.

Conclusion

With this article, we close the MCP review cycle. Across both parts, we have examined local MCP testing and review, the role of gateways, corporate deployment considerations, and a unified AppSec checklist.

MCP is not the security nightmare some headlines suggest. With the right approach, careful risk reduction, and proper governance, MCP can be used safely and effectively. The most pressing challenge today is the lack of mature best practices, hardened configurations, and formalized standards. But as the technology evolves, we will see more security guidance - alongside new attacks and vulnerabilities that will require continuous vigilance.

• Share: