Notifications
Clear all
Topic starter
19/08/2026 3:32 pm
TL;DR: MCP agents can fail silently across tool chains, leak data through parameters, and create escalating token and evaluation costs, according to Fiddler’s analysis of production observability patterns. The governance gap is no longer whether teams can monitor outputs, but whether they can trace, explain, and control agent-tool decisions end to end.
NHIMG editorial — based on content published by Fiddler: Your MCP Agent Is Failing Silently
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
Questions worth separating out
Q: How should security teams govern MCP agents that can switch between tool calls and generated code?
A: Security teams should treat tool calls and generated code as separate execution modes with different control requirements.
Q: Why do MCP agents create new audit and compliance requirements?
A: Because the final answer does not reveal the full decision path.
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
- Implement end-to-end trace propagation Propagate correlation IDs across every agent, model, and tool boundary so you can reconstruct the full execution chain when a decision goes wrong.
- Log decision lineage before redaction Record agent identity, user context, tool parameters, policy checks, and response summaries before applying PII redaction to stored telemetry.
- Measure tool selection quality Use semantic evaluation to detect whether the agent chose the right tool for the task, not just whether the tool returned quickly.
What's in the full article
Fiddler's full blog covers the operational detail this post intentionally leaves for the source:
- OpenTelemetry span design for LLM calls, tool invocations, and response processing
- Per-tool cost attribution methods for token spend, API usage, and evaluation overhead
- Latency and error metrics that separate model drift from tool degradation
- Policy points for agent input, tool invocation, and final output evaluation
👉 Read Fiddler's analysis of MCP agent observability, cost, and compliance →
MCP agent observability: why visibility now defines control?
Explore further
19/08/2026 4:14 pm
MCP observability is the missing control plane for AI agents. When agents can select tools, pass parameters, and chain actions across services, classic application logging stops being enough. The governance issue is not just visibility, but the ability to prove which action was taken, on whose behalf, and with which data. That makes agent telemetry a control surface for IAM, PAM, and NHI teams as much as for engineering teams. Practitioners should treat agent traces as part of identity governance, not as optional debug output.
A question worth separating out:
Q: When should organisations treat agent telemetry as a security control?
A: They should treat it as a security control whenever the agent can query systems, move data, or trigger business actions. At that point, telemetry is not just diagnostic. It is the evidence layer for least privilege, accountability, and containment when behaviour deviates from policy.
👉 Read our full editorial: MCP agent observability is now a governance requirement
