MCP 1.0 defines a rich protocol for tool registration, capability negotiation, and message framing, but it is deliberately silent on authentication. The spec leaves server identity verification, client authentication, and per-tool permission scoping entirely to implementers. In practice, this means most MCP server deployments today have no authentication at all: any process that can connect to the server socket can register tools and receive tool results. For production enterprise deployments, this is a critical gap.
What Is the Authentication Gap in MCP 1.0?
The absence of authentication in the spec is not an oversight, it reflects the protocol's origin as a tool-calling framework for local development environments where the agent and the MCP server run on the same machine. But enterprise deployments increasingly run MCP servers as network services, and a network-accessible MCP server with no authentication is an open API that can be called by any process on the network. The tool registry is especially dangerous: an attacker who can register a malicious tool will have it offered to the model on every subsequent request.
How Does Mutual TLS Provide Server Identity?
Mutual TLS (mTLS) is the most reliable mechanism for establishing bidirectional identity between an MCP client and server. With mTLS, both the gateway and the MCP server present certificates from a shared certificate authority, the gateway verifies the server is who it claims to be, and the server verifies the gateway is an authorized client. This prevents man-in-the-middle attacks, rogue MCP server registration, and lateral movement attacks where a compromised service attempts to present itself as a trusted MCP tool provider.
What Is Per-Tool Permission Scoping?
Beyond server identity, enterprise deployments need per-tool permission scoping: the ability to restrict which agents can invoke which tools, with what arguments, under what conditions. This is analogous to OAuth scopes but applied at the tool call level. QuilrAI implements per-tool permissions as a policy layer in the MCP gateway, each tool registration includes a permission policy specifying which agent identities can invoke it, what argument patterns are allowed, and whether invocation requires an additional approval step for sensitive operations.
- MCP 1.0 has no authentication standard, server identity and client auth are unspecified
- Network-accessible MCP servers without auth are open APIs callable by any network process
- mTLS provides bidirectional identity verification between gateway and MCP servers
- Per-tool permission scoping restricts tool invocation by agent identity and argument pattern
- Sensitive tool operations can require an approval step before the call proceeds
QuilrAI
How QuilrAI addresses this: The QuilrAI MCP Gateway implements mTLS for all server connections, maintains a certificate registry for authorized MCP servers, and enforces per-tool permission policies defined in the Guardian setup wizard, including approval workflows for tools flagged as sensitive.