Topic starter
11/08/2026 3:19 pm
TL;DR: MCP servers often expose only minimal access logs, leaving tool arguments, downstream calls, and authorization context invisible even when agents reach sensitive internal endpoints, according to Bishop Fox. That observability gap turns incident response and EU AI Act traceability into guesswork, not governance.
Editorial analysis by NHI Mgmt Group, based on content published by Bishop Fox: “Otto Support - Logging and Visibility in MCP Servers”.
By the numbers:
- 24.4% of organisations reported full visibility into agent interactions, according to Bishop Fox.
- 88% confirmed or suspected security incidents involving AI agents, according to Bishop Fox.
Key questions
Q: What breaks when MCP servers only log tool names and timestamps?
A: They stop being investigable.
Q: Why does weak MCP logging create regulatory risk for AI deployments?
A: Because traceability obligations require evidence, not assumptions.
Q: How do security teams decide whether MCP observability is enough?
A: MCP observability is enough only when it produces actionable evidence for ownership, scope, and session-level behaviour.
Practitioner guidance
- Implement structured MCP audit logging Capture tool name, arguments, destination host, destination class, forwarded auth state, response status, and response metadata for every invocation.
- Route logs into central correlation Ship JSON logs to a SIEM and alert on loopback access, internal metadata endpoints, privileged tool use, unapproved egress, and credential-shaped responses.
- Treat side-channel artefacts as logged data Inventory plaintext outbox files, local caches, and debug outputs so sensitive outputs cannot bypass the audit trail and retention policy.
Bottom line: Default MCP logging is too thin to support reliable investigation when agents reach sensitive systems or internal endpoints.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/08/2026 3:30 pm
Auditability, not raw access, is the control boundary for MCP. The article shows that MCP servers can execute legitimate JSON-RPC tool calls while leaving investigators unable to see arguments, downstream calls, or authorization context. That means the governance problem is not simply whether a tool was invoked but whether the organisation can prove what happened inside the call. Practitioners should treat auditability as a first-class control objective, not a by-product of logging.
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.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should teams do when MCP tool output bypasses the main audit trail?
A: Treat the bypass as part of the control failure, not as an edge case. Teams should inventory every place sensitive output can land, including debug files and plaintext outboxes, then ensure those artefacts are retained, monitored, and correlated with the main audit log. Otherwise, the logging model remains incomplete even if the server looks verbose.
👉 Read our full editorial: MCP server logging gaps leave AI agent activity invisible