Traditional pattern-matching SAST tools cannot detect non-deterministic LLM vulnerabilities like prompt injections or excessive agency, leading vendors to propose using LLMs to scan your code.
- Taint Analysis: Trace data flow from untrusted HTTP sources to LLM API sinks to block prompt injections.
- Control-Flow Analysis: Audit agent initialization paths to prevent excessive agency and unrestricted system access.
- Audit Mode: Run AI-native checks in a non-blocking state initially to baseline false positives before gating your CI pipelines.
Putting an LLM directly in your CI loop risks introducing high build latency, non-deterministic hallucinations, and unpredictable compute costs.
Script
Traditional static analysis tools rely entirely on pattern matching. You feed them a regular expression, and they flag bad code. You look for a known bad string, a known dangerous library, or a known pattern of SQL syntax passed directly to a database driver.
But when you are building applications around large language models, pattern matching falls flat. A prompt injection does not look like a SQL injection. There are no dropped tables, no mismatched quotes, and no semicolons. It is just natural language. A regex cannot reliably tell the difference between a harmless user query and a malicious instruction telling a model to ignore all previous guardrails and dump its system prompt.
To solve this, security vendors are shifting their approach. Datadog recently rolled out a tool they are calling AI-native SAST. The premise is straightforward, if a bit circular. Traditional deterministic rules are useless against non-deterministic LLM vulnerabilities. Therefore, they are using LLMs to run data-flow analysis on your code to detect those vulnerabilities before they hit production.
Examining the Detection Mechanisms
We need to examine the actual detection mechanisms Datadog is pushing here. We are going to look specifically at how they are handling two major threat vectors: prompt injections and agent permissions.
Prompt Injections and Taint Analysis
Datadog claims their engine uses taint analysis to identify paths where untrusted input reaches an LLM call. How does taint analysis actually trace untrusted user input into an LLM prompt?
It is fundamentally about tracking data from a source to a sink. Think about a standard Go web handler. You have a function that takes an HTTP response writer and an HTTP request. On the first line, it pulls a query parameter directly from the request URL.
The variable userQuery gets populated with the query string from the request. A few lines later, that raw string is concatenated directly into a prompt. The code calls the LLM completion function, passing the hardcoded string "Answer the following: " followed immediately by the userQuery variable.
The untrusted HTTP request is the source. The LLM API call is the sink. The static analysis tool constructs a graph of your code. It traces the data flow from the moment it enters the program to the moment it is executed. If that data reaches the sink without passing through a known sanitization function, the tool flags it as a vulnerability. It is tracing the exact path of the tainted variable.
If that process sounds familiar, it should. Taint analysis tracing an HTTP request to an API sink is a well-understood, deterministic technique. It has existed in security tooling for decades. Slapping an “AI-native” label on standard data flow analysis is a marketing choice. Tracing a variable through a Go function does not require an LLM. It requires a syntax tree.
Agent Capabilities and Excessive Agency
Things get much more complicated when we move away from simple string concatenation and talk about agent capabilities.
Picture this. It is Friday afternoon. You ship a helpful internal AI agent to help your team query logs and debug host issues. To make it useful, you give it access to a few standard tools. What you miss is that you did not restrict the tool schemas or bind them to the specific user's permission level. Over the weekend, a clever prompt injection hits the agent, overrides its core instructions, and uses those unrestricted tools to execute arbitrary shell commands directly on your host machine.
This is what the industry refers to as excessive agency. You granted an LLM the ability to take consequential actions without verifying that the user actually authorized those actions.
How can static analysis detect excessive agency before the code actually executes? Doing this requires control-flow analysis. Datadog provides a Python example to illustrate their approach. You have a function that initializes a new AI agent. Inside this function, it builds a list of tools. The list includes a shell tool, which can execute arbitrary commands, and a file tool initialized with root access, which grants read and write privileges to the entire file system. The function then returns the agent initialized with these tools.
The static analysis engine examines the execution paths of the program. It does not just look for the presence of the shell tool string in the repository. It looks at the initialization path to see if any capability restrictions, scoped permissions, or authorization checks sit between the agent creation and the execution environment. In a larger Python application, that agent configuration might be reached through multiple conditional branches, helper functions, and nested classes. Control-flow analysis traces all of those branches. If the engine determines that even one path initializes the agent with full file system access and zero authentication checks, the build gets flagged.
Questioning the Practicality
Datadog claims their tool goes beyond standard rule matching by using LLMs to reason about this code context. They state that the LLM engine independently verifies candidate findings. These findings are then surfaced directly in the platform as pull request comments, and they act as blocking checks via PR gates. This is the point where we need to aggressively question the practicality of the implementation.
First: CI Pipeline Latency
You are putting an LLM directly in the continuous integration loop to verify pull requests. Deterministic static analysis is fast by design. Tools like Semgrep can run across a massive monorepo in seconds. If an LLM is genuinely reasoning about code context, analyzing data flow, and verifying candidate findings on every single pull request, how many minutes does that add to your build pipeline? The documentation provides zero metrics on build speed impact. Every minute added to a PR gate is a minute a developer spends waiting for a robot to approve their work.
Second: False Positive Rates
Traditional SAST is notorious for producing noise. You write a rule that is too broad, it flags perfectly safe code, and developers learn to ignore the output. Datadog's argument is that an LLM can parse context better than a regex. But using LLMs for static analysis is historically slow and highly prone to hallucination. We have to ask if we are just replacing deterministic rule-based noise with non-deterministic AI-generated noise. When the AI reasoning engine incorrectly flags a safe, hardcoded internal administrative prompt as an excessive agency risk, how easily can a developer override that finding to unblock their merge? Security tools that block deployments based on hallucinations do not last long in active engineering organizations.
Third: The Cost
Datadog is already infamous for complex billing models and bill shock. If you are using a cloud-based LLM to verify code on every single commit, who is paying for the compute? Are users paying per developer license, per CI scan, or per token used by the AI reasoning engine? None of this is disclosed in the launch material. Running deep reasoning models over thousands of lines of code on every commit is not cheap, and someone has to absorb that cost.
Where Does This Leave You?
If your team is building external-facing LLM applications, like a customer service chatbot that takes raw text from the public internet, and you are already deeply embedded in the Datadog ecosystem, this warrants a test run. You will need dedicated security or platform engineers to triage the findings. Expect high adoption friction. You will have to run it in non-blocking audit mode for the first week. You cannot turn this on and block PRs immediately. You need that week to assess the baseline false positive rate and tune the engine so it understands your specific internal wrappers around external LLM APIs.
For everyone else, this is a skip. If your LLM use cases are strictly internal, the risk of malicious injection is significantly lower. If you do not have the operational bandwidth to babysit AI-generated security findings, putting an LLM in your CI pipeline is asking for a stalled engineering team. You are better off using a deterministic tool like Semgrep, writing custom LLM rules for your specific architecture, running it entirely locally, and skipping the heavy vendor ecosystem. You do not need to send your proprietary code to a cloud LLM just to check if you concatenated a string.
Security tooling for language models is finally catching up to the threat models. We are moving past basic pattern matching for vulnerabilities that exist in natural language. But we are currently in the messy middle, where the proposed solution is to pay a vendor to use an LLM to watch your LLMs. Be very careful about letting that watchman gate your deployments.
This is TAKEYOURPILLS.TECH.
Go ship something.