Topic starter
20/08/2026 5:30 pm
TL;DR: MCP observability improves runtime visibility, according to Stacklok, but it does not by itself establish who is authorised to use a tool or session. Kubernetes proxy layers need identity, scope and revocation controls to govern access before execution.
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: 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.
Q: What breaks when MCP observability is missing?
A: Root cause analysis breaks first, followed by cost attribution, policy enforcement, and safe incident response.
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.
Glossary terms: Mcp session, Package Proxy, Delegated Access, Workload Identity
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
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