Scanning Your Agent Stack for the Vulnerabilities That Matter

Keep your usual dependency and container scanning running against everything your agent stack is built on, the MCP server hosts, the libraries the tools depend on, the model client SDKs. Federal guidance sets an expectation of remediating critical, internet-accessible vulnerabilities within about 15 days of detection¹, and that's a reasonable bar to hold your own agent infrastructure to, since these servers are often newer and less battle-tested than the rest of your stack.

A tool that constructs a database query or a file path from a value the model provided, without strict validation, can potentially be steered into unintended behavior by a cleverly crafted input, whether that input comes from a user or from content the agent read during a tool call. This is closer to an injection vulnerability than a traditional CVE, and it needs its own review process, reading the tool's implementation with an adversarial eye, not just scanning its dependencies.

Any value a tool receives from the model should be validated and sanitized before it's used to build a query, a file path, or a command, exactly as you would for input coming directly from an end user, because in practice it can be influenced by content the model read from anywhere in its context, not only by what the person typing to it intended.

For example, if a tool accepts a file name from the model, resolve it against an allowed directory and reject anything that points outside it, instead of trusting the string. If a tool accepts an identifier, check that it belongs to the acting user before running the lookup. Validation rules like these belong in the tool, not in the prompt, because a prompt instruction can be overridden by content the model reads, while a check in code cannot.

New MCP tools get added over time, and each one needs the same adversarial review the first batch got. Fold this review into your regular tool-shipping process rather than treating it as a separate audit that happens occasionally, since a tool that skips it is the one most likely to be the actual gap when something eventually goes wrong.

A short, written checklist for this review, does this tool build a query, path, or command from a model-provided value, and if so, is that value validated, is enough to catch most of the risk without requiring a dedicated security engineer to personally review every tool before it ships.

Ask these questions in every MCP tool review:

• Does the tool build a query, file path or command from a value the model provided?
• If so, is that value validated and sanitized before it is used, exactly as you would treat input from an end user?
• Is the query built through a parameterized call instead of simple string concatenation?
• Could content the agent read elsewhere, not just the person typing, influence that value?
• Was this review done before the tool shipped, as part of the regular tool-shipping process?

Say a tool built to search internal documentation constructs its search query by directly inserting whatever text the model decides is relevant, pulled from the user's conversation. A standard vulnerability scan of the server this tool runs on comes back completely clean, no outdated dependencies, no known CVEs anywhere in the stack.

An adversarial review of the tool's actual code finds the real issue: because the query is built through simple string concatenation rather than a parameterized search call, a user, or content the agent read elsewhere and treated as an instruction, could potentially craft input that broadens the search far beyond what the tool's stated purpose intended. Nothing about this shows up in dependency scanning, because the vulnerability isn't in a library, it's in how the tool itself was written, which is exactly the category of risk that a code-level review catches and an automated scanner does not. The fix, switching to a parameterized query builder, took less than an hour once the review had actually named the problem, which is typical: the review is the expensive part, and the fix, once found, is usually straightforward. Budget time for the review accordingly rather than assuming it can be squeezed in alongside a tool's normal functional testing, since the two require a genuinely different way of reading the same code.