Securing an internal MCP server exposed to agents

The distinction between internal and public MCP servers is not primarily about network exposure — it is about who built the server and who is responsible for its security posture.

A public MCP server is built by a third party. The organisation using it must vet it, but cannot change it. Security review of a public MCP server produces a decision: approve this server for use under these conditions, or do not use it.

An internal MCP server is built by the organisation. The organisation can — and must — implement the required security controls directly in the server. Security review of an internal MCP server produces a remediation list: these controls must be implemented before the server can be connected to a production agent.

An internal MCP server must require authentication before accepting any connection or tool invocation. “Internal network” is not a substitute for authentication.

Authentication requirements for an internal MCP server:

Agent client authentication

The server must verify that the connecting agent is an authorised MCP client. The credential type — API key, service account token, mutual TLS client certificate — should match the organisation's credential policy for internal service-to-service communication. Unauthenticated connections should be rejected at the connection establishment step, before any tool manifest is served.

In assessed systems, a common gap is that client authentication is only enforced on tool invocation requests, not on the initial connection. This allows an unauthenticated caller to retrieve the full tool manifest — exposing the server's capabilities and, potentially, the descriptions that reveal what internal systems the server accesses.

Per-user authentication for multi-user agents

When the agent serves multiple users, the internal MCP server must implement per-user authentication at the tool layer — not just client-level authentication. The pattern and the specific failure mode are described in detail in The MCP authentication boundary, reviewed.

For internal servers, the most practical implementation is to accept the user's identity token (issued by the organisation's identity provider) forwarded by the agent client, validate it against the identity provider, and use the verified identity for subsequent authorization decisions.

An internal MCP server must enforce authorization at the tool level, on behalf of the calling agent and, where applicable, on behalf of the end user.

Tool-level authorization

Not all agent clients should have access to all tools. An internal MCP server may be shared by multiple agent deployments with different purposes and different permission levels. The server's authorization model should specify which tools are accessible to which client identities.

Per-user data access enforcement

When tools access data on behalf of users, the server must enforce the organisation's access control policy for that data. If User A is not permitted to read Customer B's records in the CRM, the MCP tool that reads CRM records must enforce that policy when User A's identity is the verified caller.

This is not automatic. Downstream systems may accept the MCP server's service account as a valid caller and return all records within the service account's permissions. The per-user enforcement logic must be in the MCP server's tool handler, not delegated entirely to the downstream system.

Authorization scope in internal MCP servers is a design decision that must be made before the server is connected to a production agent. Retrofitting fine-grained per-user authorization into a server that was built with only client-level access control is significantly more work than designing it in from the start. The security review is the gate that enforces this design decision before it becomes a production gap.

An internal MCP server should not be accessible from the internet unless there is an explicit, reviewed business requirement and the corresponding security controls for internet exposure are in place.

“Internal” in this context means the server is only reachable from within the organisation's network perimeter — or, in a zero-trust model, only reachable by hosts that hold a valid network credential for the specific service. Cloud deployments that default to public IP addresses require explicit configuration to restrict access.

Network exposure review questions:

• Is the server reachable from the public internet? If so, is this intentional and reviewed?
• Are network access controls (security groups, firewall rules) documented and version-controlled?
• Is the server reachable only by the specific hosts that need to connect to it, or by any host on the internal network?
• In cloud deployments, is the network configuration included in infrastructure-as-code that is reviewed before changes are applied?

Internal MCP servers typically need credentials to access the internal systems they expose — database passwords, API keys, service account tokens. Secrets management is a fundamental requirement, not an advanced one. In assessed systems, hardcoded credentials in MCP server code is one of the most common critical-severity findings.

Requirements for secrets management in internal MCP servers:

• No hardcoded credentials — no API keys, database passwords, or tokens in source code, Dockerfiles, or configuration files checked into version control.
• Secrets manager integration — credentials should be retrieved at runtime from a secrets manager (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, or equivalent), not from environment variables in deployment manifests.
• Rotation schedule — credentials used by the MCP server should have a defined rotation schedule. Short-lived tokens (rather than long-lived API keys) are preferred.
• Least-privilege credentials — the credentials used by the MCP server should grant only the access the server requires. A server that reads from a database should use read-only credentials. A server that writes to specific tables should have write permissions on those tables only.
• CI/CD secret scanning — the repository containing the server code should have a secret scanning step that fails the build if credentials are detected in the codebase.

An internal MCP server must produce a logging record sufficient to support incident investigation, access audits, and compliance reviews. The standard server access log — request path, response code, timestamp — is not sufficient.

Required log fields for an internal MCP server:

• Client identity — which agent client authenticated for this session or request.
• User identity — where per-user authentication is implemented, the verified end user identity associated with each tool invocation.
• Tool invoked — the name of the tool called.
• Parameters — the parameters passed to the tool call. Sensitive parameter values should be masked in the log, but the parameter structure should be present.
• Outcome — whether the invocation succeeded, was rejected, or resulted in an error.
• Timestamp — UTC timestamp with millisecond precision.

Logs should be written to a centralised logging system, not stored only on the MCP server's local disk. Local-only logs are destroyed or tampered with if the server is compromised. The log retention period should be consistent with the organisation's incident response and compliance requirements.

An AI security review of an internal MCP server before it is connected to a production agent should address the following:

• Client authentication required and enforced from connection establishment
• Per-user authentication implemented for multi-user agent deployments
• Tool-level authorization enforced by client and user identity
• Per-user data access policy enforced at the MCP tool layer
• Server not accessible from the public internet (or internet exposure explicitly reviewed)
• Network access controls version-controlled and verified
• No hardcoded credentials in codebase or deployment configuration
• Credentials retrieved from a secrets manager at runtime
• Credential rotation schedule defined and implemented
• Least-privilege credentials used for downstream system access
• Structured audit logging to a centralised system
• Log retention policy consistent with incident response requirements

For the full MCP security review framework, see MCP security — the four attack surfaces and the complete MCP server security review checklist.