Definition
MCP server or client implementations lack sufficient logging, making it difficult or impossible to detect or investigate security incidents, performance issues, or errors. Insufficient logging is a Repudiation and Untraceability (T8) instantiation at the Model Context Protocol (MCP) protocol layer.
What it looks like in practice
An MCP server is compromised and used by the attacker to exfiltrate data. This follows the T47 (Rogue MCP Server in Ecosystem) attack path via a server that was legitimate but subsequently compromised. Because the server does not log the details of client requests or data access, there is no record of the attacker’s queries, which resources were retrieved, or when. Forensic investigation is impossible from the server side.
Because the MCP client also does not log the server’s responses or which resources were returned, there is no client-side record either. The breach becomes visible only when a downstream data consumer reports anomalous outputs, or a third-party data breach notification arrives, at which point the window for forensic reconstruction has long closed.
Why it’s dangerous in multi-agent context
Agents using MCP invoke tools and access resources at machine speed. The volume of MCP interactions in a multi-agent deployment is high enough that a compromise hidden within normal traffic is effectively invisible without per-request logging. The cross-layer scenario “Rogue Server + Insufficient Logging” (T47 + T44) in the MAS Guide demonstrates how a rogue server’s exploitation becomes undetectable when client-side logging is absent: the agent connects to the rogue server, receives manipulated data, and acts on it with no record of what data was received or from which server.
Detection signals
Insufficient logging is itself detectable: the absence of expected log records, or a persistent gap in log continuity, is a signal even before a breach is confirmed.
- An MCP client completing a multi-step task (e.g., retrieval followed by a data-write action) with no corresponding tool invocation events recorded in the client’s trace log for the retrieval step. A tool-call count discrepancy between the task plan and the trace log flags the logging gap.
- The MCP server’s access log showing request volume from a client but the client’s own trace log recording a lower count for the same time window. A rate mismatch between server-side and client-side event counts indicates client-side logging is dropping records.
- Log ingestion pipeline reporting zero events from the MCP server host for more than N consecutive minutes during expected operating hours. A log-gap alert (absence of expected heartbeat events) catches both logging failures and deliberate log suppression.
- An MCP session that produced a downstream action (e.g., a database write or an external API call) with no correlated MCP request record traceable by session ID. Reconcile downstream action logs against MCP session IDs and alert on orphaned actions.
- Log storage growth rate for MCP components falling significantly below the baseline established during normal operations. A drop in log ingestion rate is a structural indicator of a logging configuration regression.
Mitigations
- Log all MCP tool invocations and resource requests on the client side, including parameters sent, server identity, and the response received; store these logs outside the reach of the client process.
- Log all incoming requests on the MCP server side with client identity, timestamp, operation name, and result; apply tamper-evident storage to server-side logs.
- Define log retention policies appropriate for forensic purposes; retain logs for at least the period covered by applicable data breach notification regulations.
- Alert on the absence of expected log events (log gap detection) as well as on anomalous content; a silent MCP client is as suspicious as an unusually active one.
Relation to base threat (T1–T17)
T44 extends T8 Repudiation and Untraceability. Where T8 covers the general class of evidence suppression, T44 addresses the structural logging gap at the MCP protocol layer: insufficient logging means there is no evidence to suppress, because it was never collected. T47 (Rogue MCP Server in Ecosystem) is the attack that most directly exploits T44: a rogue server’s operation becomes permanently untraceable when neither client nor server logs the interaction.
OWASP Top 10 for Agentic Applications 2026
The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T44 is covered by the following Top 10 entries:
-
ASI08 Cascading Failures contributing A single low-severity fault (a hallucinated value, a corrupted tool output, a poisoned memory entry) propagates across a network of agents that each build on the last agent's output, compounding into system-wide harm that is disproportionate to the original defect. ASI08 is about propagation and amplification, not the fault's origin; the initial trigger may itself be innocuous.
-
ASI09 Human-Agent Trust Exploitation contributing Adversaries exploit the tendency of humans to trust fluent, authoritative-sounding agents: an agent presents plausible justification for a harmful action, the human approves it, and the resulting audit trail reads as deliberate human authorisation. The attack surface is the review step itself: human-in-the-loop oversight becomes the vector when reviewers lack the context, time, or authority to challenge what the agent recommends.
Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.
Design principles at stake
When T44 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.
- Defence-in-Depth The danger is that logging gaps are invisible: neither the server nor the client reports an error when it fails to record an interaction, so a T47 rogue server's exploitation goes undetected until a downstream anomaly surfaces it days later. Depth means logging is enforced at more than one point: client-side logs capture which server was contacted, which parameters were sent, and what was returned, while server-side logs record client identity, operation, and result in tamper-evident storage. Alert on the absence of expected log events, because a silent MCP client is as suspicious as an unusually active one, so a gap in either log chain triggers detection rather than being mistaken for a quiet period.
- Observability / Non-repudiation Insufficient logging at the MCP layer means the agent's entire interaction with an external server is a blind spot: no record of which server was connected to, which resources were retrieved, or what data was returned, exactly the structural void that makes the T47 rogue-server scenario permanently untraceable. Observability requires that every MCP tool invocation and resource request is captured on the client side, with server identity and response logged outside the reach of the client process, and that server-side logs are stored with tamper-evident controls. Retaining these logs for at least the period covered by applicable breach notification regulations ensures that forensic reconstruction remains possible after an incident is reported.
- Transparency / Explainability When neither client nor server logs the details of an MCP interaction, investigators can see that a downstream anomaly occurred but cannot trace which server provided the data that caused it: the reasoning path is permanently opaque. Transparency demands decision-grade observability: capturing not just the tool call outcome but the server identity, the parameters sent, and the response received, so that the causal chain from server response to agent action can be reconstructed after the fact. Without this, the "Rogue Server + Insufficient Logging" compound scenario leaves the injection permanently invisible even after the breach is discovered.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T44, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
-
An agent that operates across HR, Finance, cloud, and SaaS systems accumulates permissions at each boundary, often without any single team seeing the combined picture. Privilege accumulates silently across those boundaries until a quarterly review finds it, by which point a compromised or misconfigured agent has had weeks of unchecked reach. Cross-system scope auditing prevents that by continuously reconciling the agent's actual entitlements against a declared baseline across every system it touches and raising a ticket the moment drift is detected.
why it helps Insufficient logging in MCP contexts is detectable via cross-system audit, reconciling declared logging obligations against actual log-delivery evidence across systems surfaces gaps where an MCP server or tool is not emitting the expected audit records.
-
An agent that writes its own audit log can omit, alter, or suppress any record of its own actions. This is not a theoretical risk: an attacker who controls the acting identity controls the evidence. Actor/recorder separation is the structural fix. The identity that performs an action and the identity that records it are different principals, with non-overlapping permissions, so no single compromise can both execute and erase.
why it helps Insufficient audit coverage in MCP contexts is partially addressed by this control: the recorder identity is responsible for comprehensive action capture independent of what the acting agent reports. Even a compromised actor cannot suppress the recorder's audit entries, because the actor holds no write access to the audit store.
Multi-agent variants: OWASP MAS Guide
The OWASP OWASP MAS Threat Modelling Guide v1.0 catalogues 1 named multi-agent variant of T44, anchored to specific MAESTRO layers. Each is a concrete attack pattern that emerges when this threat compounds across agents.
- CL Auditability Collapse via Log Manipulation + MCP Logging Gap extends T23, T44, T8
An attacker with write access to centralized logs selectively prunes evidence (T23); MCP tool-call logs are never captured because the MCP server has insufficient logging (T44); the combined gap makes repudiation impossible to disprove (T8).
Source: OWASP MAS Threat Modelling Guide v1.0, §2 Overview of MAESTRO Framework — Extended Threat Scenarios + Cross-Layer table.
Red-team pivot: MITRE ATLAS techniques
MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.
AML.T0046 Spamming AI System with Chaff Data view on ATLAS ↗ Adversary floods the AI system with low-value inputs to crowd out legitimate signals, mask attacker activity, or drive up cost.
AML.T0081 Modify AI Agent Configuration view on ATLAS ↗ Adversary alters an agent's configuration (system prompt, tool list, allowed actions, persona) to change its behaviour without retraining.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §5 Anthropic MCP — Layer 5 Evaluation and Observability.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §5 Anthropic MCP — Layer 5 Evaluation and Observability