Use a boundary control such as a proxy or sidecar to collect request counts, latency, errors, and tool usage before the traffic reaches the MCP server. That approach preserves visibility even when the application cannot be modified. The goal is to make telemetry a property of the platform, not a feature that every server must implement on its own.
Why This Matters for Security Teams
mcp server that do not emit telemetry create a blind spot at the exact point where tool calls, prompts, and downstream side effects converge. That matters because monitoring is not only about uptime; it is also how teams detect misuse, abnormal agent behaviour, failed tool invocations, and policy drift. In agentic environments, the absence of server-side logs can turn a routine integration issue into an undetected security event.
Security teams should treat this as an observability and governance problem, not a feature gap to be deferred. The practical control objective is to preserve evidence of what was requested, when it was requested, and how the server responded, even if the application itself is opaque. Guidance from the OWASP Agentic AI Top 10 is useful here because it highlights the need to secure tool use, constrain agent behaviour, and detect abuse paths around autonomous workflows.
In practice, many security teams discover the monitoring gap only after an agent has already made an unauthorised tool call or caused a noisy production failure, rather than through intentional control design.
How It Works in Practice
The most reliable pattern is to place a boundary control in front of the MCP server and make that control the source of truth for operational telemetry. This can be a proxy, sidecar, API gateway, service mesh layer, or egress control that observes requests before they reach the server. The goal is to capture enough metadata to support detection, incident response, and performance analysis without depending on the server codebase.
At minimum, teams should collect request counts, latency, error rates, request size, response status, and tool invocation frequency. Where privacy and policy allow, they should also log caller identity, session or conversation identifiers, tool name, and coarse-grained outcome labels. For higher-risk environments, the boundary layer can enforce allowlists, rate limits, and schema validation so that telemetry and control are linked, not separate.
- Use a proxy or sidecar to observe every request before it reaches the MCP server.
- Normalize event fields so they can be sent to SIEM, SOAR, or other detection pipelines.
- Correlate tool usage with agent identity, user session, and change windows.
- Alert on spikes in retries, denied calls, unusual tool sequences, and unexpected destinations.
- Store only the telemetry needed for security and operations, then apply retention controls.
This approach aligns well with the operational emphasis in the Anthropic report on the first AI-orchestrated cyber espionage campaign, which underscores how autonomous workflows can be abused when execution paths are not closely observed. It also fits the direction of the OWASP Top 10 for Agentic Applications 2026, where tool misuse and weak runtime visibility are recurring risks.
These controls tend to break down when MCP traffic is highly distributed across ephemeral containers and direct service-to-service paths, because requests can bypass the single observation point.
Common Variations and Edge Cases
Tighter boundary monitoring often increases latency, engineering effort, and operational overhead, so organisations need to balance visibility against deployment complexity. That tradeoff becomes sharper when teams are integrating many MCP servers across multiple teams or business units.
Best practice is evolving for how much content should be logged. There is no universal standard for this yet, especially where prompts, tool parameters, or responses may contain sensitive data. Current guidance suggests logging structured metadata first, then adding content capture only where security value clearly outweighs privacy, legal, or confidentiality risk. In regulated environments, teams should also define whether telemetry is treated as security log data, application log data, or both.
Edge cases appear when the server is managed by a third party, runs in a locked-down appliance, or supports offline execution. In those situations, boundary controls may be the only practical option, but they should be paired with contract terms, attestations, or platform-level logging requirements. The control becomes stronger when telemetry is correlated with identity and authorisation boundaries, because agent identity and tool access often expose misuse faster than raw request counts alone.
For teams building mature programmes, the objective is not perfect observability from every MCP server. It is to ensure that a missing internal telemetry feature does not become a missing security control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | LLM/Tool Abuse | MCP monitoring helps detect unsafe tool use and agent abuse paths. |
| NIST AI RMF | GOVERN | Telemetry supports accountability and oversight for AI-enabled operations. |
| NIST CSF 2.0 | DE.CM-01 | Continuous monitoring is required when servers cannot emit their own logs. |
| MITRE ATLAS | ATLAS helps model misuse patterns that monitoring should surface. | |
| CSA MAESTRO | Agentic control planes need runtime oversight when application telemetry is absent. |
Place enforcement and observability at the orchestration boundary, not only in the server.
