AI SDK dependency vulnerability advisor
AI SDKs are unusually dangerous to integrate because they wire together capabilities that classic web libraries keep apart: arbitrary tool execution, code interpreters, document retrieval over the network, and untrusted text generated by a model. A bug that would be harmless in a plain HTTP client can become remote code execution once the same data can reach a tool. This advisor gives you a per-SDK reference of the vulnerability classes that recur in each ecosystem, with mitigations you can adopt immediately.
How it works
Pick your SDK and the tool loads a curated list of vulnerability classes for that
ecosystem. Each entry names the class, explains the mechanism in one or two
sentences, states the realistic impact, and gives a concrete mitigation. The
content is static and curated from public advisories and well-known framework
footguns — it is a checklist to read with your architecture in front of you, not
a code scanner. Run it together with a real dependency auditor (pip-audit,
npm audit, Snyk) so you cover both the design-level classes here and the
specific CVEs in your lockfile.
The vulnerability classes that recur across AI SDKs
Prompt injection to tool execution
The highest-impact class. If your agent can call tools (web search, code execution, file system access, API calls), an attacker who controls any text the model reads — a user message, a retrieved document, a web page the agent fetches — can craft that text to instruct the model to call a tool in an unintended way. The defence is treating model output as untrusted before routing it to any tool, and designing tools with minimal surface area.
Dependency confusion
AI ecosystems move fast and publish many sub-packages. Attackers register public packages with the same names as internal packages, betting that a developer’s installer will pull the public (malicious) version over the internal one. Lockfiles, integrity hashes, and internal package mirrors defend against this.
SSRF in retrieval pipelines
Retrieval-augmented generation pipelines often give the model or a tool the
ability to fetch a URL. If the URL is not strictly validated, an attacker can
cause the system to fetch internal services, cloud metadata endpoints (such as
169.254.169.254), or internal admin interfaces. Allowlist the domains and
schemes the fetch tool is permitted to contact.
Unsafe deserialization
Some AI frameworks serialize and deserialize Python objects (agent state,
memory stores, retrieved documents) using pickle or similar formats. A
malicious payload in a retrieved document or shared memory store can trigger
arbitrary code execution on deserialization. Prefer JSON for persistence;
avoid deserializing objects from external sources.
Excessive agency in agentic workflows
The class that is easy to build in and hard to detect: giving an agent too many capabilities, too broad permissions, or no human-in-the-loop gate for irreversible actions. The mitigation is the principle of least privilege applied to tools: give the agent only the tools it needs for the specific task, scope each tool as narrowly as possible, and require a confirmation step before any action that cannot be undone.
How to use it well
- Pin and verify dependencies. Use lockfiles, hashes, and an internal index to defeat dependency confusion before anything else.
- Treat model output as untrusted input. Any text the model produces — and any document it retrieves — can carry an injection payload. Validate before it reaches a tool, shell, query, or deserializer.
- Constrain tools tightly. Allowlist URLs for fetch tools (SSRF), parameterize
every database tool, and never expose a raw
eval/exectool to the model. - Re-check on upgrade. AI SDKs move fast; a minor version can add a new tool or change a default. Re-read the relevant classes after each bump.