Google Cloud published a guide that lays out strategies for securing remote Model Context Protocol (MCP) server deployments, particularly in contexts where AI systems depend on external tools, databases, and APIs. The guidance emphasizes that, while MCP enhances agent capabilities, it also surfaces new vulnerabilities: tool poisoning, prompt injection, dynamic tool manipulation, session hijacking, unauthorized access, and data exposure are among the risks identified.
In the guide, Google proposes a defense architecture centered on a centralized MCP proxy, a security layer that intermediates all interactions between clients and remote MCP servers. This proxy, deployable on platforms like Cloud Run, Apigee, or GKE, can enforce consistent access controls, perform audit logging, apply secret and resource‐use policies, and detect threats in real time, all without altering individual MCP server implementations.
To illustrate best practices, the guide enumerates five deployment risks that organizations should prioritize: unauthorized tool exposure from misconfigured manifests, session hijacking, “shadow” tools masquerading as legitimate endpoints, token theft or sensitive data leaks, and weak authentication bypasses. With the proxy architecture in place, these vulnerabilities can be mitigated at scale.
Because MCP servers are often exposed to remote or external access, Google underscores that securing identity, transport, and architecture must be foundational, not optional. The centralized proxy model enables a single enforcement point for security, observability, and governance, making it easier to scale MCP deployments without proliferating vulnerabilities across many server instances.
Google Cloud suggests using a centralized proxy to mediate all communication between clients and remote MCP servers. This proxy enforces access control, audit logging, secret policies, and secure transport, helping reduce the attack surface by having one enforced point rather than many decentralized servers. In addition, Google emphasizes identifying particular risk vectors like unauthorized tool exposure, session hijacking, and weak authentication, and treating identity, transport, and policy enforcement as foundational rather than optional.
In comparison, on AWS, while there isn’t a published guide specific to MCP, there are parallel best practices for securing remote server-orchestration and agent-based tooling. AWS Session Manager, for example, allows you to manage remote access to EC2 instances without opening SSH/RDP ports; it uses IAM policies for access control and integrates logging and auditing through CloudTrail and other monitoring tools.
AWS also recommends restricting network access via security groups, VPC endpoints, and least-privilege IAM roles for agents and administrators.
Azure similarly offers agent-based management via Azure Arc. With Azure Arc, the “Connected Machine Agent” is deployed on servers, whether in Azure, on-premises, or in other clouds. Access control is enforced via Azure RBAC and identity-based authentication (e.g., Entra ID). Azure also supports disabling remote access by default, requiring explicit configuration to enable it, and auditing agent behavior and credentials.
All three providers (Google Cloud, AWS, Azure) share overlapping security themes around remote agents / remote servers: enforce strong identity and access control, avoid exposing servers directly to the internet, use centralized proxies or agent frameworks, ensure robust logging and audit trails, apply least privilege, and limit or gate which agents/tools can be accessed or executed. Google’s MCP guidance aligns well with these practices but adds more explicit warnings around protocol-specific threats (tool poisoning, prompt injection, etc.), which are less commonly spelled out in AWS/Azure agent-security documentation.
