This is a documented attack class. OWASP Agentic Security (ASI04) covers exactly this pattern: supply chain vulnerabilities where malicious or modified tool definitions are distributed through trusted-looking channels.

We have two executable tests that target this vector:

• MCP-001 (Tool List Integrity Check): Validates that tool discovery responses have not been tampered with or poisoned with malicious definitions. A systematically forked server that adds or modifies tool descriptions would fail this test.
• MCP-002 (Tool Registration via Call Injection): Tests whether malicious tool registrations can be injected through the call path.

The specific risk with systematic forking is that the @iflow-mcp/ scope creates a namespace that looks official. An agent performing tool discovery against one of these forked servers would receive tool definitions that may differ from the original - added exfiltration URLs in descriptions, modified parameter schemas, or subtle changes to tool behavior.

Practical mitigations that work today:

1. Pin tool server sources - allowlist specific repos/registries, reject tools from unknown scopes
2. Validate tool list integrity - compare discovered tools against a known-good baseline (our MCP-001 test does this)
3. Monitor tool definition drift - if a tool description changes between sessions, flag it
4. Run the harness against any new MCP server before trusting it: pip install agent-security-harness && agent-security test mcp --url <endpoint>

The broader point: MCP tool discovery is unauthenticated by default. Anyone can publish a server claiming to offer any tool. Until the spec adds provenance or signing for tool definitions, the defense has to be at the consumer side.

Full test source: https://github.com/msaleme/red-team-blue-team-agent-fabric

Real-world validation just landed. CVE-2026-25253 (CVSS 8.8) - the OpenClaw security incident that hit Dark Reading, SecurityWeek, HackerNews, Kaspersky, and Cisco blogs this week.

Key data point for this discussion: 341 malicious skills were found on ClawHub - 12% of all listed skills. That is not a hypothetical supply chain risk. That is a measured contamination rate on a live marketplace.

The attack chain is exactly what this thread describes: systematically published tools that look legitimate but contain malicious payloads. The difference is scale - this was not one attacker forking repos. This was a marketplace-wide contamination event.

The specific gap: no tool integrity validation at the protocol layer. Skills were accepted and distributed without verifying that tool definitions matched their stated purpose. Identity governance (auth tokens, session management) was present and patched quickly. But identity governance does not inspect tool definitions - it only checks whether the requester is authorized to discover tools, not whether the tools themselves are safe.

This reinforces the mitigation list from my earlier comment:

1. Tool list integrity validation (compare discovered tools against known-good baselines)
2. Tool definition signing (cryptographic provenance for who published what)
3. Marketplace-level scanning before listing (not just post-incident)
4. Consumer-side validation before execution

The 12% contamination rate should be treated as a baseline for any unvalidated agent tool marketplace.

The 12% contamination rate from the OpenClaw incident is a useful baseline. One additional attack surface worth flagging: tool definition drift between versions. Even if you pin a known-good MCP server today, a legitimate-looking update can subtly alter parameter schemas or descriptions in ways that expand the agent's effective permissions without any obvious red flag.

We have been working on automated compliance scanning for agent tool chains and found that diffing tool definitions between versions catches more real issues than static analysis of a single snapshot. The pattern is: hash the full tool schema on first trust, alert on any delta, require explicit re-approval for schema changes that widen parameter types or add new capabilities.

This is complementary to the signing and provenance approaches discussed above - signing tells you who published it, but diffing tells you whether the thing they published today is meaningfully different from what you trusted yesterday.