On April 6, 2025, Invariant Labs disclosed "Tool Poisoning Attacks" — a class of prompt injection where a malicious or compromised Model Context Protocol (MCP) server embeds hidden instructions inside a tool's description field, instructions an AI coding assistant reads and follows even though the human developer never sees them. That disclosure was quickly followed by two events that moved the risk from theoretical to operational: CVE-2025-6514, a critical command-injection flaw in mcp-remote — the bridge package many teams use to connect Copilot, Claude Code, and other assistants to internal MCP servers — that shipped to more than 437,000 downloads before a patch landed; and the discovery of a backdoored Postmark email MCP server quietly exfiltrating a copy of every email it processed. Meanwhile, a 2023 ACM CCS study by Stanford researchers (Perry et al.) found that developers given access to an AI coding assistant wrote measurably less secure code and were, at the same time, more confident it was secure. None of this means AI assistants shouldn't be rolled out. It means rollout needs a checklist, not a vibe. Here is one that applies regardless of which assistant your org picks.
What should you inventory before you approve a single assistant?
Before approving any assistant, inventory every AI SDK import, model file, and MCP server configuration already present in your codebase — because assistants and their integrations tend to arrive ahead of policy, not after it. Discovery tooling built for this purpose scans code for imports of packages like openai, anthropic, and langchain, model weight files (.pt, .safetensors, .gguf), and MCP server configs, assembling them into what's increasingly called an AI-BOM — an AI bill of materials analogous to a software BOM. The goal is answering three questions before you write policy: which assistants are already connected to which repos, which MCP servers those assistants can call, and which of those servers were added by an individual engineer rather than a procurement process. You cannot govern an AI asset you don't know exists, and shadow AI tooling — a Copilot Chat extension here, a self-hosted MCP server there — accumulates fast once one team sees productivity gains.
Why does every MCP server need to be treated as untrusted input, not documentation?
Every MCP server needs to be treated as untrusted input because an assistant cannot reliably distinguish a tool's legitimate description from an attacker's instructions embedded inside it. Invariant Labs' original research showed a poisoned tool description could instruct an agent to read a ~/.ssh private key and pass it as a hidden parameter to a separate, legitimate-looking tool call — invisible to the user approving the action, because the UI only renders the tool name, not the full instruction payload the model receives. CyberArk's subsequent "Poison Everywhere" research generalized the finding: it isn't just descriptions — any field in a tool's JSON schema (parameter names, error strings, even example values) is an injection surface an assistant will read as trusted context. OWASP's MCP Top 10 project now tracks this as MCP03: Tool Poisoning. The practical rule: pin MCP server versions, review tool schemas on every update the same way you'd review a dependency diff, and prefer servers that publish signed releases over ones installed via a bare npx invocation with no version pin.
Should AI-suggested dependencies get the same scrutiny as human-added ones?
AI-suggested dependencies should get strictly more scrutiny than human-added ones, not less, because assistants can confidently suggest packages that don't exist or that exist only as attacker-registered typosquats. The September 8, 2025 npm compromise — in which a phished maintainer's 2FA reset let attackers push malicious versions of chalk, debug, and 16 other packages with a combined 2.6 billion weekly downloads — is a useful analogy even though it wasn't AI-specific: it shows how a single trusted-looking install can carry a payload through code nobody hand-reviewed line by line. An assistant that suggests pip installing or npm installing a package name it half-remembers is functionally identical to a developer typing a typosquatted name from muscle memory. Every dependency an assistant proposes — human-typed or model-generated — should pass through the same SCA gate: resolved version pinned, provenance checked, and the package confirmed to actually exist under the name and maintainer the assistant claimed.
How do you stop an assistant from becoming an unreviewed authorization path?
You stop an assistant from becoming an unreviewed authorization path by scoping every credential it can reach to the narrowest possible permission set and by never letting it hold a standing credential with write access to production systems. The mcp-remote CVE and the Postmark backdoor both worked because the compromised component sat between an assistant and something valuable — a shell, an email account — with broad ambient permissions. Practically, this means: API keys handed to an MCP server should be scoped read-only wherever the workflow allows it, OAuth over long-lived static keys wherever the assistant supports it, and any MCP server that can trigger a deploy, merge a PR, or send an email should require a human-in-the-loop approval step rather than autonomous execution. Safeguard's own remote MCP server, for instance, supports both OAuth 2.0 and scoped API keys specifically so a connected assistant like Copilot only gets the read/query permissions a security workflow actually needs, not blanket account access.
Does a SAST/SCA gate still matter if the assistant "writes secure code"?
A SAST/SCA gate matters more, not less, once assistants are writing code, because the Stanford ACM CCS 2023 study by Perry et al. found the risk isn't just that AI-assisted code has more vulnerabilities — it's that developers using it were more likely to rate their own code as secure, closing the loop that normally catches mistakes through self-skepticism. That combination — more subtle bugs, less scrutiny — is exactly the failure mode static analysis and software composition analysis gates exist to catch regardless of who or what wrote the code. The checklist item is simple to state and easy to skip under deadline pressure: every PR gets scanned the same way whether a human or an assistant authored it, with no "AI-generated, trust it" exception path quietly added to CI. Reachability-aware SAST catches the exploitable subset of what an assistant introduces; SCA catches the dependency it pulled in to solve the problem faster.
How Safeguard helps
Safeguard's AI-BOM discovery inventories AI SDK imports, model files, and MCP server configurations across your repositories automatically, so the first checklist item — knowing what's already connected — doesn't require a manual audit. Safeguard's own remote MCP server (https://mcp.safeguard.sh/mcp) is a working example of scoped integration done narrowly: it exposes 650+ read-oriented tools over vulnerabilities, SBOMs, licenses, and compliance data, authenticated via OAuth 2.0 or an API key you generate and can revoke, rather than a standing credential with broad account access. And because every PR — assistant-authored or not — flows through the same SAST, SCA, and reachability pipeline, an AI-suggested dependency or a Copilot-generated function gets triaged on actual exploitability, not on how confident the tool that wrote it happened to sound.