MCP server gRPC transport security: mTLS, interceptors, protobuf validation, and streaming auth

gRPC transport vs. HTTP transport: the security differences

HTTP-transport MCP servers are protected by the same tooling developers use for web APIs: TLS termination at a load balancer, JSON schema validation, HTTP middleware for auth. gRPC transports use HTTP/2 framing, binary protobuf encoding, and persistent connections — which changes the security picture in several ways:

• Connection persistence: A gRPC connection stays open across multiple RPCs. Authentication must be re-validated on each RPC call, not just at connection establishment — otherwise a token that expires mid-connection continues to work for the lifetime of the connection.
• Bidirectional streaming: Streaming RPCs create a long-lived channel where the server can push data to the client without the client making a new request. Access control must apply to the stream lifecycle, not just the stream initiation.
• Binary encoding: Protobuf messages are harder to inspect with generic WAFs or DLP tools. An attacker can craft a valid protobuf message that carries a malicious payload in a string field without it being detected by byte-pattern scanners tuned for JSON.
• Reflection API: gRPC reflection lets any client enumerate all services and their method signatures. In production, this is equivalent to exposing your API schema publicly — attackers use it to discover methods and construct exploits.

Mutual TLS for MCP gRPC servers

Standard TLS authenticates the server to the client. Mutual TLS (mTLS) also authenticates the client to the server — the client presents a certificate, and the server validates it against a trusted CA. For MCP servers in service mesh environments, mTLS provides workload identity: the certificate's Subject Alternative Name (SAN) identifies which service is calling, removing the need for a separate application-layer auth token for service-to-service calls.

In a service mesh like Istio or Linkerd, mTLS is enforced at the sidecar proxy level without changes to the MCP server code. For self-managed gRPC servers, configure TLS credentials with a client certificate requirement in your gRPC server options. Certificate rotation is critical: don't issue server certificates with lifetimes longer than 90 days. For workload certificates in a mesh, use short-lived certificates (24 hours or less) issued by SPIFFE/SPIRE.

Auth interceptors: validate on every RPC, not just connection

gRPC interceptors (the equivalent of HTTP middleware) run before or after each RPC method. A server-side unary interceptor validates the auth token on every unary RPC call. A streaming interceptor validates on stream establishment. The common mistake: auth is validated only at connection establishment, so a token that's revoked mid-connection continues to work until the connection is closed.

Correct pattern: validate the token on every RPC call in the unary interceptor. For streaming RPCs, validate at stream open and periodically re-check on each received message. For performance-sensitive servers, cache validation results keyed by token hash with a TTL equal to the token's remaining validity — this avoids a round-trip to the auth server on every call while still catching revocations on the next cache miss.

Protobuf deserialization security

Protobuf is generally safer than JSON deserialization — there's no dynamic type coercion, and the schema defines which fields exist. But protobuf has its own attack surface:

• Unknown field injection: Protobuf parsers by default preserve unknown fields (fields not in the current schema). An attacker who knows an older schema version can inject fields that were removed but might still be handled by old code paths. Use the DiscardUnknown option in your protobuf parser to drop unknown fields rather than preserving them.
• Deeply nested messages: Protobuf allows arbitrarily nested message types. A maliciously crafted message with thousands of levels of nesting can cause stack overflow in recursive parsers. Set a max recursion limit in your protobuf parser configuration.
• Large string fields: Protobuf does not enforce maximum string length at the schema level. A string-typed args field can carry a multi-gigabyte payload. Add server-side max message size (gRPC's MaxRecvMsgSize option) and per-field length validation after parsing.

Disable gRPC reflection in production

gRPC reflection (grpc.reflection.v1alpha.ServerReflection) is invaluable during development — tools like grpcurl use it to enumerate your service schema without a proto file. In production, it's an intelligence-gathering tool for attackers: they can list every method, every field name, and every service without any prior knowledge of your API.

Register the reflection service only when an environment variable or build tag indicates development mode. Never register it in production images. Verify with: grpcurl -plaintext localhost:50051 list — if that returns your service list without auth, reflection is enabled.

TLS certificate validation in gRPC clients

When an MCP server acts as a gRPC client (proxying to an upstream gRPC service), TLS certificate validation must be enabled. The common mistake is using grpc.credentials.createInsecure() for internal services because "they're on the same network." For internal services using a private CA, pass the CA certificate to grpc.credentials.createSsl(caCert) — never disable certificate validation with checkServerIdentity: () => undefined.

Disabling certificate validation defeats the entire purpose of TLS. It means any network-path attacker between your MCP server and the upstream gRPC service can perform a MITM without detection — intercepting tool results and injecting prompt injection payloads into the response stream.

What SkillAudit flags for gRPC MCP servers

When SkillAudit analyzes a gRPC-transport MCP server, it checks for:

• Reflection service registered unconditionally (not gated on env/build flag)
• Auth interceptor that runs only at connection establishment, not per-RPC
• Missing MaxRecvMsgSize configuration (defaults allow large-message resource exhaustion)
• Protobuf parser without DiscardUnknown option
• Server TLS certificate with lifetime >365 days
• Client-side gRPC using createInsecure() for non-localhost connections
• Client-side TLS with checkServerIdentity overridden to disable validation

These findings appear under the Security axis in the SkillAudit report. A gRPC MCP server that passes all these checks is significantly harder to exploit than one that relies on connection-level auth alone.