Notifications
Clear all
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.
NHIMG editorial — based on content published by ARMO: Runtime Observability for MCP Servers: A Security Guide
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
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 tools complicate least-privilege governance?
A: MCP tools break access into small capabilities, which is helpful, but only if each tool has a clear owner, scope, and approval model.
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
- Implement cross-layer correlation for MCP telemetry Join protocol logs, kernel execution events, and agent traces into a single incident timeline so a tool invocation can be traced from request to file access to outbound connection.
- Instrument high-risk tools at the kernel layer Apply eBPF-based monitoring to tool processes that can read files, query data stores, or reach the network.
- Baseline tool-call graphs by agent and workflow Record normal tool sequencing, retry patterns, and capability use for each agent or MCP workflow, then alert on drift when sequences jump from benign tools to file-read or network-send actions.
What's in the full article
ARMO's full blog covers the operational detail this post intentionally leaves for the source:
- Kernel-level eBPF instrumentation patterns for Kubernetes-hosted MCP tools
- Example correlation logic that joins protocol events, execution telemetry, and agent traces
- Detection logic for prompt injection, capability drift, and abnormal tool chaining
- Operational retention guidance for execution-layer telemetry versus protocol logs
👉 Read ARMO's guide to runtime observability for MCP servers →
MCP runtime observability: are your controls catching real attacks?
Explore further
20/08/2026 6:25 pm
Runtime observability is now part of identity governance for MCP environments. MCP tools are not just application components. They are delegated actors that can touch files, credentials, and network destinations on behalf of an agent or user session. That makes runtime evidence relevant to IAM, PAM, and NHI governance because access decisions are only meaningful if defenders can see how the delegated tool actually behaved. Practitioners should treat observability as a control input, not just an operations function.
A question worth separating out:
Q: What should teams do when an MCP tool starts behaving outside its baseline?
A: Contain the tool process, review the last correlated protocol and execution events, and compare the current tool-call sequence to baseline behaviour before restoring access. The key is to investigate the runtime path, not just the request log, because the malicious action may already have occurred inside the session.
👉 Read our full editorial: Runtime observability for MCP servers exposes the security gap
