If an attacker knows a system does hash comparison, can they find a way around this detection?
Hash comparison itself is cryptographically hard to bypass directly — as long as even a single character in a tool description's text differs, the computed hash comes out completely different. That's a basic property of hash functions, and an attacker can't adjust the wording of a malicious instruction to make the modified content produce the same hash as the original. The real attack surface isn't the hashing algorithm itself — it's whether the hash-comparison mechanism is actually being run correctly and continuously. For example, does the system only record a hash once at initial installation and never compare again afterward? Or is active proxy mode never enabled, relying only on a one-time passive scan — in which case an attacker just needs to strike during the window after that passive scan, and the change still won't be caught in real time.
This is also the real reason passive scanning (one-time check) and active proxy (continuous monitoring) need to be used together: if an organization only records a hash before initial go-live but never establishes ongoing re-comparison, they technically have the detection tool but aren't actually running it. That gap — "having the tool but not continuously using it" — is the real space an attacker can exploit, not any weakness in the hashing algorithm itself.
Invariant Labs was acquired by Snyk and rebranded — what does this actually mean for teams already using MCP-Scan?
From a technical continuity standpoint, being acquired by a security firm with greater resources usually signals more assured long-term maintenance — a common risk with open-source tools built by small independent research teams is that the project stalls once core developers shift focus elsewhere. Snyk integrating MCP-Scan into its enterprise Agent Scan product line instead signals a clearer path to commercialization and an incentive for sustained investment, which is a positive signal for teams relying on it for long-term protection.
One practical detail worth watching is that the product's positioning may become tiered after an acquisition — the open-source version continuing to maintain basic functionality (free, Apache 2.0 licensed, as noted in the documentation), while enterprise features (more complete continuous background monitoring, cross-team dashboards) might get carved into the paid Snyk Agent Scan product line. If your team is currently on the open-source version, it's worth periodically confirming that the core detection capabilities (tool pinning, prompt injection detection) still remain within the open-source license's scope, rather than assuming nothing changed before and after the acquisition.
Tool pinning depends on the premise that "the first recorded version is clean" — what if the version recorded from the start was already poisoned?
This is a genuine limitation. Tool pinning is fundamentally about "freezing the state at a certain point in time, then tracking changes from there" — it has no ability to answer whether that frozen initial state itself was clean. If an attacker's first-ever published version of a tool already carries a malicious instruction (tool description poisoning itself, rather than a rug-pull that turns malicious later), the hash-comparison mechanism will faithfully record that malicious version as the "baseline," and as long as it's never changed again afterward, no alert ever fires.
This is also why tool pinning and semantic-layer detection (like the malicious-instruction analysis MCP-Scan performs by calling the Invariant Guardrails API) need to coexist rather than replace each other: semantic detection handles judging whether the initial version itself is clean before it ever gets recorded; tool pinning handles confirming whether, after being verified clean, it later secretly turns malicious. The two address different stages of the attack lifecycle, and doing only one leaves another stretch of the attack chain unprotected.
If my team decides to adopt tool pinning, who should practically be responsible for watching alerts, and how often should checks happen?
A practical starting point is tiering tools by criticality rather than applying the same cadence to every tool. High-risk tools with direct access to private data or external communication ability (assessable against the lethal trifecta framework) should have alerts handled near-instantly, with a rotating security or platform team member responsible. Lower-risk tools used only for reading public information can be batch-reviewed daily or weekly, without needing to interrupt normal workflow for every single change.
On accountability, alerts generated by tool pinning shouldn't just get dumped on a security team to unilaterally judge whether "this change looks reasonable" — security teams typically aren't familiar with each tool's business context and can't independently determine whether a given feature update makes sense. A more practical approach is having the alert also notify the team actually using that tool (say, the product or engineering team that integrated a given MCP server), so the owner of the business context and the security team can jointly confirm whether the change falls within expected bounds. This is also why, before adopting this mechanism, clarifying who should respond within what timeframe once an alert fires, and how responsibility is divided, matters more than simply installing the tool itself — an alerting system with no clear process usually ends up degrading into a notification inbox nobody actually watches.
The hardest part of dealing with a rug-pull attack isn't how sophisticated the technique is — it's that the attack exploits a structural blind spot in observation: you don't keep watching something you've already confirmed is safe. Once a tool passes initial review, gets written into a commonly-used list, and gets depended on by multiple processes, it shifts from "an object requiring scrutiny" to "infrastructure that's just taken for granted in the background" — and that's exactly the moment an attacker chooses to strike. Defending against this can't rely on human vigilance alone; it needs a tool that turns "has the content changed" into an automated, observable signal.
The most direct technical approach the industry currently uses is called Tool Pinning: the moment a tool first passes review and earns trust, its complete description text gets hashed and that value is recorded. Every subsequent time the system is about to interact with that tool, it recomputes the current hash and compares it against the recorded original — if even a single character in the tool's description has been altered, the hash comes out completely different. This mechanism doesn't need to understand whether new content is malicious; it only needs to detect the fact that content has changed, leaving the judgment of whether it's malicious to subsequent human review. The advantage of this approach is that it doesn't depend on semantic understanding, so it can't be fooled by social-engineering tricks like "this new instruction sounds professional and reasonable" — no matter how well the new content is disguised, if the hash doesn't match, the alert fires.
MCP-Scan, an open-source scanning tool developed by Invariant Labs (an ETH Zurich spinout co-founded by professors Martin Vechev and Florian Tramèr along with a group of researchers), already has tool pinning built in. The tool offers two operating modes: passive scan for one-time vulnerability checks, scanning every MCP server listed in your configuration files, retrieving tool descriptions, and performing both local checks and semantic-layer malicious-instruction detection by calling the Invariant Guardrails API; and active proxy mode, which injects a temporary local gateway to continuously monitor and intercept MCP traffic, enforcing protection rules in real time, including detecting cross-origin privilege escalation (tool shadowing) and blocking tool calls that violate policy. MCP-Scan has accumulated over 2,000 stars on GitHub, making it the most widely adopted MCP security scanner, and was acquired by security firm Snyk in June 2025, now integrated into Snyk's enterprise Agent Scan product line and continuously maintained, with its latest release shipped in April 2026.
What tool pinning reliably detects is any change to the tool description text itself — regardless of whether that change was caused by an attacker planting malicious instructions or simply a legitimate feature update, the hash mismatch triggers an alert either way. This means the mechanism itself can't distinguish "malicious change" from "normal update" — it can only tell you "a change occurred," and subsequent judgment still requires human involvement: reviewing the before-and-after diff, checking whether there's a corresponding public changelog, and assessing whether the added or modified content makes sense. This limitation isn't a flaw — it's a deliberate design tradeoff. Rather than having an automated system attempt to judge semantic maliciousness (easily bypassed by a cleverly disguised attack), leaving that judgment to humans and confining the system's role to "ensure any change never slips through unnoticed" is the more robust division of labor. This is also why passive scanning (one-time check) and active proxy (continuous monitoring) need to be used together: passive scanning answers "is this tool clean right now," while active proxy answers "has this tool been secretly changed since then" — doing only the former still leaves you fully exposed to rug-pull attacks.
If your agent system depends on any third-party MCP server, adopting a tool-pinning mechanism moves the actual benefit of "when a rug-pull attack gets discovered" earlier — from "damage has already occurred, investigated after the fact" to "the moment content changes, you know immediately." That time gap directly determines how long the attack window stays open and how high your forensic costs run. Without this mechanism, the only thing you can rely on is the tool eventually breaking or causing obvious anomalies — by which point the attacker has already achieved their goal. With this mechanism, even if you can't immediately determine whether a change is malicious, you can at least trigger a review process the moment the change happens, clearly separating "we don't know what happened" from "we know a change happened and we're investigating" — and the risk level and response resources needed for the latter are far lower than for the former.