An organization deploys a Model Context Protocol (MCP) server that provides agents with access to internal APIs and databases. The MCP server is accessible over HTTPS. The security team wants to ensure that only the organization's self-hosted GitHub Actions runners can call the MCP server. Which network-level control best enforces this restriction?
Select an answer to reveal the explanation.
Short Explanation
Transport Layer Security proves the server is who it says it is, but it doesn't control who can call it. You need an IP allowlist at the network layer, like a bouncer checking your address before you knock; if you're not on the list, the firewall drops the connection before authentication starts.
Full Explanation
Defense in depth for a sensitive internal MCP server should include controls at multiple layers, but the network layer is the most fundamental. An IP allowlist configured on the server's firewall or cloud security group, such as an AWS Security Group, Azure NSG, or GCP Firewall Rule, drops inbound connections from unauthorized source IPs at the network level, before any application-layer authentication can take place. For self-hosted GitHub Actions runners, the runners' outbound IP addresses are known and static because the organization controls the runner infrastructure. Configuring the MCP server to accept inbound HTTPS only from those specific IP addresses means that even if an attacker obtains an API key or credentials for the MCP server, they cannot connect from outside the allowed IP range. This implements network-layer access control as a first line of defense, complementing application-layer authentication such as mutual Transport Layer Security, API keys, or OIDC as a second layer. Requiring HTTPS with a valid Transport Layer Security certificate is incorrect because it controls the server's identity, letting the client know it is talking to the right server, but it does not restrict which clients can call the server; any client that can reach the server over HTTPS can initiate a connection. Protecting the MCP server behind HTTP basic authentication with a shared username and password is incorrect because that is application-layer, not network-layer; the connection is established and the authentication exchange happens before the server rejects unauthorized clients, and basic authentication transmits credentials in base64, which is not encrypted by itself and is weaker than certificate-based or token-based approaches. Deploying the MCP server in a public subnet but requiring API key authentication on every request is incorrect because any attacker who can reach the server from any IP address in the world can attempt authentication and potentially brute-force or steal the API key; network exposure should be minimized before authentication is even attempted.