Topic starter
20/08/2026 5:40 pm
TL;DR: APM, OpenTelemetry, and log aggregation are not enough to secure Model Context Protocol deployments because they miss file access, network egress, and agent tool-call changes, according to ARMO. Runtime observability has to correlate protocol events, execution telemetry, and agent behaviour, because the attack story emerges only when those layers are joined together.
Editorial analysis by NHI Mgmt Group, based on content published by ARMO: “Runtime Observability for MCP Servers: A Security Guide”.
Key questions
Q: What breaks when MCP security relies only on protocol logs?
A: Protocol logs prove that an MCP request occurred, but they do not show which files were read, which endpoints were contacted, or whether the tool process did anything harmful after invocation.
Q: Why does runtime observability matter more when MCP tools may be compromised?
A: When the tool itself is part of the threat model, application-level telemetry can be stripped, falsified, or selectively suppressed.
Q: How do security teams know if MCP runtime monitoring is actually working?
A: They should test whether one investigation can reconstruct the full chain from protocol request to host behaviour to agent decision.
Practitioner guidance
- Instrument MCP servers with runtime evidence Capture protocol events, process lineage, file access, and network egress for every tool invocation so each request can be traced through the full runtime path.
- Correlate agent traces with execution telemetry Join tool-call sequences to syscall and network data so prompt injection, capability drift, and suspicious chaining are visible in one incident timeline.
- Define sensitive-path baselines for tools Classify expected file paths, databases, and endpoints for each tool and alert when runtime behaviour reaches credential stores, secret paths, or unknown destinations.
Bottom line: Traditional observability is insufficient for MCP environments because it does not reveal the file access, egress, or tool chaining that determine whether a request was harmless or malicious.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:25 pm
Runtime observability is becoming a control plane, not a troubleshooting layer. MCP security depends on runtime evidence because the threat model includes compromised tools, manipulated instrumentation, and behaviour that only appears after a request crosses from protocol to execution. Security teams that still treat observability as performance management are looking at the wrong layer. The practitioner conclusion is simple: security assurance for MCP starts where application telemetry ends.
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 after they detect anomalous MCP tool chaining?
A: They should contain the affected tool, preserve protocol and execution evidence, and compare the observed sequence against the tool’s normal invocation pattern before assuming user error. The priority is to stop further runtime access, because chained tool calls can move from benign actions to sensitive file reads and outbound transfer in a single session.
👉 Read our full editorial: Runtime observability for MCP servers exposes the security gap