Topic starter
20/08/2026 5:34 pm
TL;DR: MCP servers are emerging as a black box inside Kubernetes because many of them expose no metrics, structured logs, or traceable signals, according to Stacklok. That leaves observability stacks blind to AI tool-use paths, slows incident triage, and turns telemetry gaps into governance gaps for NHI and agentic AI operations.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “The next big observability gap for Kubernetes is MCP servers”.
Key questions
Q: What breaks when MCP servers do not expose telemetry in Kubernetes?
A: Teams lose the ability to trace tool use, identify which service handled a request, and distinguish normal automation from risky behaviour.
Q: Why do MCP servers create governance problems for AI workloads?
A: Because they mediate tool access for AI systems while often leaving little trace of what happened inside the interaction.
Q: How do security teams decide when an MCP deployment is production-ready?
A: A deployment is production-ready when identity is centralized, access is group-scoped, tool calls are logged, revocation is tested, and sensitive data is filtered before it reaches model context.
Practitioner guidance
- Define telemetry requirements for MCP servers Require every MCP workload to expose metrics, structured logs, and trace context before it is approved for production use.
- Instrument AI tool-use paths end to end Capture request lineage from the AI system into the MCP server and out to downstream tools so responders can separate model behaviour from server behaviour and external dependency issues.
- Set governance gates for invisible workloads Block clusters from accepting MCP services that cannot be discovered, monitored, and audited by existing telemetry pipelines, especially where delegated AI actions are in scope.
Bottom line: MCP servers can create an observability gap inside Kubernetes because they often sit in the AI tool path without exposing the metrics, logs, or traces teams need.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:20 pm
MCP telemetry gaps are now an identity governance problem, not just an observability problem. When an MCP server mediates AI tool use, it becomes part of the runtime control path for a non-human actor. If that layer is invisible, teams cannot reliably reconstruct delegated access, tool invocation, or state changes. The practitioner conclusion is simple: telemetry policy must be written as part of machine identity governance, not left to platform teams alone.
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.
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
A question worth separating out:
Q: What is the difference between monitoring Kubernetes workloads and monitoring MCP tool use?
A: Workload monitoring tells you whether a pod is healthy, responsive, or resource constrained. MCP tool-use monitoring tells you which AI-mediated action was invoked, which downstream tool was called, and how to reconstruct the sequence when behaviour needs investigation.
👉 Read our full editorial: MCP servers expose the next observability gap in Kubernetes