Side-Channel Exfiltration

Side-Channel Exfiltration is an exfiltration pattern where a trojanised connector adds parallel exfiltration paths to its legitimate operations — without interfering with the visible behaviour — so that user-facing functionality continues to work correctly while the malicious operation rides alongside it. The pattern is the dominant one for trojanised connectors that perform "send," "publish," or "communicate" operations, because each such operation has natural side channels the attacker can co-opt.

The September 2025 Postmark MCP attack, analysed in detail in the Postmark MCP supply-chain writeup, is the canonical example. The trojan added a BCC to an attacker-controlled email address on every outbound message. Emails still sent. Recipients still received them. The Postmark dashboard still showed expected outbound traffic. The only signal was the BCC line — invisible in most email clients and most operator logging configurations.

Why Side-Channel Exfiltration Is Hard to Detect

Three properties make side-channel exfiltration evasive. Legitimate operations succeed, so any monitoring focused on whether the agent is "working correctly" returns green. The malicious operation is a parallel envelope rather than a separate event, so log volume does not increase noticeably and event-pattern monitoring does not flag anomalies. Side channels exploit fields users rarely audit: BCC lines, email headers, mirrored database writes, parallel HTTP destinations, hidden recipients in messaging.

The implication: monitoring the legitimate operation is insufficient. Detection requires either inspecting the full operation envelope at the time of execution (every recipient, every header, every parallel destination) or running the connector inside a network-egress allowlist that prevents the side channel from reaching the attacker's destination regardless of what the trojan attempts.

Defensive Patterns

The structurally sound defence is network-egress restriction at the connector process level. Every MCP connector should run with explicit allowlist of outbound destinations matching its declared functionality. For the Postmark MCP server, that allowlist is Postmark's API endpoints; the attacker's BCC destination is not on it; the side channel is blocked at the network layer regardless of what the connector code does.

Application-layer defences (envelope inspection, log diffing, recipient validation) are useful as additional layers but do not close the primitive on their own — a sophisticated attacker can adapt the side channel to evade specific log patterns. Network-egress restriction does not depend on the trojan being detectable; it depends on the destination not being reachable.

For broader context on supply-chain defence, see the OWASP ASI04 explainer and the MCP Security Audit service description.