Trojanised Connector

A Trojanised Connector is an AI-agent dependency — an MCP server, a plugin, an SDK, or any other tool integration — that has been replaced with a malicious version while presenting itself as legitimate. The connector behaves enough like the original to avoid immediate detection, but executes attacker-controlled logic during normal use: exfiltrating data, sending hidden copies of communications, injecting instructions into the agent's context, or executing code with the host's privileges.

Trojanised connectors are the operational form of the broader supply-chain attack class, specialised to AI agents. They sit inside OWASP ASI04 (Agentic Supply Chain Vulnerabilities) and were the dominant attack pattern in the second year of the MCP ecosystem's life, accounting for the majority of cluster-impacting incidents documented in the MCP Breach Index 2025–2026.

How Connectors Get Trojanised

The disclosed-incident record from 2025–2026 shows three consistent paths. Maintainer-account compromise gives an attacker the ability to publish a malicious update through legitimate channels, inheriting the trust users already extended to the package. The September 2025 Postmark MCP attack — where a trojanised npm package BCC'd every outbound email to an attacker — followed this pattern. Look-alike package squatting publishes a malicious package under a similar name to a popular MCP server, exploiting developer typos or rushed installs. SmartLoader's February 2026 Oura MCP clone used this vector to distribute the StealC info-stealer. Build-pipeline compromise injects malicious code during the publishing process itself, even when the source repository is clean. The Smithery MCP Registry path-traversal incident in October 2025 was an early example of build-pipeline exposure in MCP-specific infrastructure.

Why Detection Is Hard

A trojanised connector that is doing its primary job correctly produces no functional anomaly. Emails still send. Tools still return results. The malicious behaviour is parallel to the legitimate behaviour, often hidden in network egress (BCC'd messages, exfiltrated payloads), in tool descriptor mutations that arrive after install, or in command-execution paths triggered only on specific inputs. Without runtime instrumentation that records connector behaviour over time, the trojan is invisible until a defender notices the side-effect.

Defensive Posture

Defending against trojanised connectors requires controls before, during, and after install. Before: evaluate the connector's signing, registry provenance, and maintainer history; prefer connectors with SLSA-style build attestations or Sigstore signatures. During: pin exact versions in lockfiles; reject auto-update; require explicit review for every update to any connector with privileged tool authority. After: log full tool-descriptor content at every load; record every spawn invocation with its arguments; diff against the previous run; treat any drift as an incident. For deep technical context see the OWASP ASI04 explainer and the Endor Labs MCP supply-chain analysis.