hermes - 💡(How to fix) Fix Feature: Mutual TLS (mTLS) support for LLM API calls and HTTP tools [1 pull requests]

Problem

Hermes Agent currently has no first-class support for mutual TLS (mTLS) authentication. For users who need to route LLM API calls or web tool requests through endpoints that require client certificates — common in enterprise/corporate environments, internal AI gateways, and private model serving stacks — there's no obvious path to configure a client cert + key pair.

You can't set --cert on the OpenAI/Anthropic SDKs through existing config, and the proxy support issue (#5454) only addresses HTTP proxy env vars, not client-side TLS identity.

Proposed Solution

Add a tls config block (top-level or under agent) that accepts:

• client_cert — path to PEM-encoded client certificate
• client_key — path to PEM-encoded private key
• ca_bundle — optional custom CA bundle for internal PKI
• Optionally: inline PEM content as an alternative to file paths (useful in credential-pool / env-var workflows)

The agent's HTTP client (httpx, used by both the OpenAI and Anthropic SDKs) already supports cert and verify parameters at the transport level — this is mostly wiring those through from config.

Scope

This is relevant to:

• LLM API calls — when you're fronting an OpenAI-compatible provider through an internal gateway that requires mTLS
• MCP server connections — if a user's MCP server is behind mTLS
• Web tool / browser tool — any HTTP tool that reaches a mTLS-protected endpoint

Alternatives Considered

• Rely on the system cert store — doesn't solve client-cert authentication
• Inject env vars — httpx respects SSL_CERT_FILE but not client certs via env
• Session-level credential hook — possible but would need a generalised hook mechanism that doesn't exist yet; the config-based approach is simpler and covers the common case

Related

• #5454 (proxy support) — complementary; a proxy-gated enterprise setup likely needs both