A SAST scanner reads text. An agentic system reads intentions—then writes its own code, chooses its own tools, and executes actions no human ever reviewed. When a LangChain agent generates a Python snippet mid-session to parse a CSV, or a CrewAI pipeline dynamically assembles a SQL query from an LLM's output, the vulnerability doesn't live in the repository your scanner checked out. It lives in a call graph that only exists at runtime, built from strings the model composed on the fly. Traditional SAST tools—Semgrep, Checkmarx, Fortify, CodeQL—were built for a world where source code is the whole story: fixed control flow, fixed data flow, a finite set of functions to trace. Agentic codebases break every one of those assumptions, and they're doing it in production right now. In 2025, frameworks like LangChain, CrewAI, AutoGen, and native tool-use in Claude and GPT models are shipping faster than security tooling can adapt to them.
Why Can't SAST Tools Trace a Call Graph That's Built at Runtime?
Because agent frameworks decide which function to call, and with what arguments, only after an LLM inference completes—so the edges in the call graph don't exist in source form for a static analyzer to walk. A tool like CodeQL builds its model of "what calls what" by parsing syntax trees and resolving symbols at compile or scan time. That works when a developer writes parse_invoice(file_path) directly. It breaks when an AgentExecutor receives a JSON blob like {"tool": "run_query", "args": {"sql": "..."}} generated by the model itself, and a generic dispatcher routes it to one of a dozen registered functions based on a string match resolved at runtime. CVE-2023-36258, a sandbox-escape vulnerability in LangChain's PALChain component, is a good illustration: the exploitable path only materialized when the LLM was induced to emit a particular Python expression that got passed to exec(). Nothing in the static source looked unusual—the dangerous data flow existed only in the shape of text the model chose to produce that day.
Why Does Taint Analysis Fail When the Untrusted Input Is a Prompt, Not a Parameter?
Because classic taint tracking follows explicit data flow from a marked source (an HTTP request parameter, a form field) to a sink (a SQL query, a shell command), but in agentic pipelines the "source" is unstructured natural language embedded inside a prompt template, and the "propagation" happens inside a black-box model inference call that no static analyzer can see through. The compiler-level guarantee that taint tools rely on—"this variable's provenance can be tracked through assignments and function calls"—disappears the moment untrusted text enters an LLM and re-emerges transformed, summarized, or recombined with trusted context. CVE-2024-5565, disclosed in June 2024 against the Vanna.ai text-to-SQL library, showed exactly this gap: a crafted natural-language prompt caused the agent to generate Python plotting code that was then executed, escalating a prompt injection into remote code execution. A SAST scanner looking at Vanna's source would see a call to a charting library, not an attacker-controlled path—because the taint didn't travel through variables, it traveled through the model's interpretation of language.
Can Static Analysis Catch Vulnerabilities Hidden in Tool Schemas Instead of Code?
Not reliably, because the attack surface in agentic systems has moved from source code to the JSON-defined tool schemas and system prompts that describe what an LLM is permitted to invoke, and most SAST engines have no concept of a "tool definition" as a security boundary at all. A function-calling schema that grants an agent a run_shell_command or write_file capability with no scoping is functionally equivalent to running a web app as root—but it's expressed as a config object or a docstring, not as code matching a known CWE pattern like CWE-78 (OS command injection). OWASP's Top 10 for LLM Applications (2025 revision) codifies this as LLM06: Excessive Agency, alongside LLM01: Prompt Injection—two categories that describe risk in terms of what an agent is allowed to do, not what a line of code does. Rule-based scanners tuned for injection, XSS, and path traversal simply don't have a rule shape for "this tool grants more capability than the agent's task requires."
Why Do Non-Deterministic Code Paths Break Traditional Vulnerability Triage?
Because SAST's core promise—find it once, fix it forever—assumes the same code executes the same way every time, but an LLM-driven agent can take a materially different path through its available tools on every single run. A ReAct-style loop might call a database tool first on one execution and a web-search tool first on the next, depending on sampling temperature, prior conversation state, or even model version drift after a provider's silent update. Multi-agent orchestration frameworks like AutoGen compound this: agent-to-agent messages are themselves LLM-generated, so the "source code" a scanner analyzes is really a scaffold around a decision tree with an effectively unbounded number of runtime branches. A single static scan captures one hypothetical execution; it says nothing about the branch where the planning agent decides to hand a file path straight to a code-execution tool instead of a read-only summarizer.
Do Standard SAST Rulesets Even Have Signatures for Agentic-Specific Risks?
Mostly no—rulesets like Semgrep's public registry and CodeQL's standard query packs were written against well-established CWE patterns (SQL injection, XSS, path traversal, insecure deserialization) years before prompt injection existed as a named category, and there is still no widely adopted CWE mapping that most engines ship with out of the box for indirect prompt injection, tool-poisoning, or agent memory-poisoning attacks. MITRE's ATLAS framework, launched to catalog adversarial machine-learning techniques, tracks these behaviors under its own taxonomy (e.g., AML.T0051 for LLM prompt injection) that lives entirely separate from the CVE/CWE ecosystem most SAST tools query against. The result is two parallel universes of vulnerability knowledge that don't talk to each other: a mature, decades-old static-analysis rule corpus for traditional code, and a nascent, fast-moving threat taxonomy for agentic behavior that almost no commercial SAST product has integrated as of mid-2026.
How Safeguard Helps
Safeguard treats an agentic application as more than its source repository—it treats it as a supply chain that includes prompt templates, tool schemas, model configurations, and the third-party agent frameworks that orchestrate them, and it analyzes all of it as first-class artifacts rather than incidental config. That starts with extending traditional SBOM practices into an AI-aware bill of materials that inventories which models, tool definitions, and agent frameworks a codebase depends on, so a change to a run_shell_command tool's permission scope or a new indirect dependency in a LangChain plugin shows up as a tracked, reviewable change rather than an invisible one.
Because static analysis alone can't see a call graph that only exists at runtime, Safeguard correlates source-level findings with the behaviors an agent actually exhibits—mapping tool invocations, data flows through prompts, and cross-agent messages against a threat model informed by both CWE and MITRE ATLAS categories, instead of relying on a single taxonomy that predates agentic architectures. This closes the gap that let CVE-2023-36258-style sandbox escapes and CVE-2024-5565-style prompt-injection-to-RCE chains slip past scanners that only understood one half of the picture.
Safeguard also brings policy-as-code guardrails to the orchestration layer itself: least-privilege enforcement on tool schemas, allowlisting of what an agent can call and with what argument shapes, and continuous verification that runs alongside CI/CD rather than as a one-time gate—so drift introduced by a new agent, a new tool, or a provider's model update gets caught on the next build instead of the next incident review. For teams operating under SOC 2 or similar compliance obligations, this gives auditors evidence that agentic risk is being managed with the same rigor as traditional application risk, not bolted on as an afterthought. As agentic systems keep composing themselves at runtime, that combination—supply-chain visibility, behavior-aware correlation, and enforced guardrails—is what closes the gap traditional SAST was never built to cover.