Snyk Expert: AI Agent Toolchains Are the Weakest Security Link

AI agents are becoming a regular part of the software development workflow, but the security community is starting to notice an uncomfortable fact: the toolchains these agents invoke may be the most fragile security link today. In a recent interview, Snyk's Randall Degges offered a warning worth heeding for developers, covering reachability analysis, the cost of acquiring context, and the security of AI agent tools.

Reachability Analysis: What It Costs to Know a Vulnerability Is Actually Reachable

Traditional Software Composition Analysis (SCA) tools list every known vulnerability in a project's dependencies, but many alerts are noise—"theoretically present, practically unreachable." The core of reachability analysis, as Degges emphasizes, is determining whether a vulnerable function is actually called by business code—if the call chain can be proven unreachable, teams can safely ignore that alert.

This capability sounds great, but it comes at a steep price. To make reliable reachability judgments, tools need a deep understanding of the project's call graph, dynamic dispatch, reflective calls, and even runtime behavior. The engineering complexity and computational cost of building this context far exceed simple version matching. Degges's implicit message: the hidden cost security teams pay to "reduce false positives" is often underestimated. For enterprises, the key is not chasing zero vulnerabilities but directing limited remediation resources toward risks that are truly reachable.

Software Composition Analysis (SCA) is a foundational part of DevSecOps. It parses a project's dependency manifests (such as package.json or pom.xml) and cross-references them against vulnerability databases (such as NVD or GitHub Advisory) to identify third-party components with known vulnerabilities. SCA's strengths are its high degree of automation and broad coverage, but its fundamental limitation is that it "looks only at versions, not usage": any dependency whose version falls within an affected range is flagged as risky, even if the vulnerable function in that dependency is never called by business code. This is one of the main sources of alert fatigue. Reachability analysis can be seen as a refined extension of SCA—it layers call-chain analysis on top of version matching, narrowing "a vulnerability exists" to "a vulnerability can be triggered," significantly improving the signal-to-noise ratio of alerts. Industry efforts such as GitHub's dependency graph and Snyk's own reachability feature are evolving in this direction.

Call Graph is the technical cornerstone of reachability analysis. It models the calling relationships between functions in a program as a directed graph; by traversing edges from entry points, one can determine whether a vulnerable function lies on a reachable path. The difficulty is that building an accurate call graph statically is nearly impossible in real-world engineering: dynamic dispatch in object-oriented languages requires type inference, and mechanisms like reflection, dependency injection, and callback registration make call targets unknowable at compile time—dynamic languages like JavaScript amplify this uncertainty further. In practice, engineering teams typically adopt hybrid approaches combining static analysis with runtime instrumentation, accepting some false negatives and false positives. This also explains why reachability analysis is far more computationally expensive than version matching—it essentially embeds program analysis capabilities into the security scanning process.

The Cost of Context: Why "Knowing the Truth" Is So Expensive

The interview title's phrase "what it costs to know a vulnerability is real" points to a deeper issue: confirming a vulnerability's real exploitability requires substantial context—dependency versions, call paths, configuration, runtime environment—all of which are essential. The more complete the context, the more accurate the judgment, but the cost of collecting and maintaining that context rises accordingly.

This is also the dividing line in today's security tool competition. Vendors that can acquire high-quality context at low cost are the ones that can deliver credible reachability conclusions; tools limited to static version matching are destined to keep generating alert fatigue. Degges's point is in effect a reminder to buyers: when evaluating security products, don't just look at how many vulnerabilities they report—ask what basis they have for judging those vulnerabilities to be real.

AI Agent Toolchains: The Industry's Weakest Security Point Today

Degges's sharpest judgment concerns AI agents. An agent's capabilities depend on which tools it can invoke—reading and writing files, executing commands, accessing the network, operating code repositories. These tools are often integrated as plugins or MCP (Model Context Protocol) servers, and problems such as coarse permission configurations, missing input validation, and unknown supply-chain origins are quite common.

A single compromised third-party tool, or one over-privileged tool interface, could cause an agent to perform dangerous operations without the user's knowledge. Compared with traditional applications, agent toolchains have a larger exposure surface: they must trust both model output and tool implementations, and both can be influenced by attackers. Degges's warning is direct—before granting an agent permissions, audit its tools the same way you would audit production dependencies.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024 to standardize how AI applications connect to external tools and data sources. In the MCP architecture, the model side acts as a client, invoking tools exposed by various MCP servers (such as file read/write, database queries, and command execution) through a unified interface. This design greatly lowers the barrier for agents to access external capabilities, but it also introduces new attack surfaces: third-party MCP servers are hard to verify by origin, tool descriptions may be maliciously tampered with to induce model invocation (i.e., "tool poisoning"), and the servers themselves may obtain system permissions beyond expectations. Since the MCP ecosystem is still in its early stages and lacks mature signing, permission declaration, and audit standards, the "unknown supply-chain origin" problem Degges refers to is particularly prominent in MCP scenarios.

Practical Takeaways for Development Teams

Several actionable recommendations can be distilled from this interview. First, prioritize reachable vulnerabilities and establish traceable exemption records for unreachable alerts rather than simply ignoring them in bulk. Second, bring the tools used by agents into software supply-chain management, recording versions, origins, and permission scopes. Third, configure agent tools according to the principle of least privilege, avoiding situations where a single tool simultaneously has permission to read code, write files, and access the external network.

The security industry is shifting from "finding more vulnerabilities" to "judging risk more accurately," and the spread of AI agents makes this shift more urgent. Degges's observations deserve serious attention from every team introducing agents into their development workflow: the more powerful the tool, the more important it is to first understand who trusts it—and whom it can trust.

One-line Summary

Snyk expert warns: reachability analysis is costly, and AI agent toolchains are the weakest security point today.

Paragraph Summary

In an interview, Snyk's Randall Degges noted that the security industry is shifting from "finding more vulnerabilities" to "judging risk more accurately." Traditional SCA tools list all known vulnerabilities in dependencies, but many alerts are practically unreachable; reachability analysis effectively reduces noise by determining whether vulnerable functions are actually called by business code, but it requires building call graphs and understanding dynamic dispatch and runtime behavior—making context collection far costlier than version matching. Degges believes that the ability to acquire high-quality context at low cost is the dividing line in security tool competition. His sharpest judgment concerns AI agents: the plugins and MCP servers that agents invoke commonly suffer from coarse permissions, missing input validation, and unknown supply-chain origins, making them the industry's weakest security link today. He recommends that teams prioritize reachable vulnerabilities, bring agent tools into supply-chain audits, and follow the principle of least privilege.