Topic starter
20/08/2026 5:30 pm
TL;DR: MCP servers can be turned from black boxes into observable Kubernetes services by pairing OpenTelemetry, Prometheus, Grafana, and Jaeger, according to Stacklok, but the operational win is only half the story because telemetry does not replace governance over tool access and session behaviour. The wider implication is that as MCP deployments scale, identity teams need to treat observability, privilege, and auditability as linked controls rather than separate projects.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “From black box to observable: Deploy ToolHive with OTel + Prometheus”.
Key questions
Q: What breaks when MCP observability is missing?
A: Root cause analysis breaks first, followed by cost attribution, policy enforcement, and safe incident response.
Q: Why do MCP servers need identity controls if telemetry already shows every request?
A: Because telemetry records behaviour after access has happened, while identity controls decide whether the caller should be trusted in the first place.
Q: How can organisations tell whether MCP access is actually being governed?
A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token.
Practitioner guidance
- Define MCP session-level access policy Require a clear identity bound to every MCP client session and authorize tool use before the request reaches the server process.
- Treat the MCP proxy as a policy enforcement point Place enforcement logic at the proxy boundary so tool invocation, revocation and audit all share the same control plane.
- Track session behaviour as an identity signal Use traces and metrics to flag unusual tool sequences, repeated invocations and unexpected client patterns, then map those signals back to the session identity that created them.
Bottom line: MCP observability improves runtime visibility, but it does not by itself establish who is authorised to use a tool or session.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:18 pm
Observability without identity is only partial control: the article is correct that MCP servers become operationally understandable once ToolHive, OTel and standard dashboards are in place, but understandability is not governance. Telemetry can show tool calls, latency and trace paths, yet it cannot decide whether a caller should exist, whether a session should continue, or whether a delegated action is inside policy. For practitioners, the implication is that visibility programs must be designed alongside access governance from the start.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should teams do when Kubernetes-hosted MCP workloads become harder to audit?
A: Tighten the boundary around the proxy, make the caller identity explicit, and treat each tool path as a governed access route rather than a generic service endpoint. That combination reduces the chance that a well-instrumented cluster still hides overbroad delegated access.
👉 Read our full editorial: MCP observability in Kubernetes still needs identity controls