Lurking in your codebase in a dependency no human chose. An agent needed a JSON parser, picked one and installed it. There was no debate over slack or ticket or review, there was no person involved, and it's there anyway. There's a name for the process we now need to make sure these dependencies aren't malicious. It's called agentic development security.
What is agentic development security?
Agentic development security is the practice of securing the software development process when AI coding agents generate, select, and ship code on their own. It protects the whole flow: the tools agents use, the actions they take, and the code and dependencies they produce.
The idea is simple. When an agent writes and merges code faster than any person can read it, you have to trust the process, not just the final file.
Forrester Senior Analyst Janet Worthington coined this shift in April 2026 in Agentic Development Security: Why AppSec Needs A New Operating Model. She writes "Software development itself is becoming agentic, generating insecure code at scale… Securing agentic development requires controls that operate continuously, reason autonomously, and intervene in real time."
This guide covers how to build those controls without slowing developers down.
Agentic development security vs. agentic AI security
These two terms sound alike but solve different problems.
Agentic development security is about how software gets built when agents write it. It secures your build pipeline.
Agentic AI security is about protecting agentic AI applications after they are running in production. It secures a shipped product using agents. This guide is about the first one.
| Aspect | Agentic Development Security | Agentic AI Security |
|---|---|---|
| Focus | The development process when agents write code | Agentic AI apps running in production |
| Protects | Tools, actions, code, and dependencies during the build | The live agent, its runtime, and user data |
| Main users | Engineering and AppSec teams | Platform and product security teams |
| Example risk | An agent installs a hallucinated package | A deployed agent leaks data at runtime |
Why agentic development changes the security equation
AI-assisted development is now the default way teams build software. Stack Overflow's 2025 survey of more than 49,000 respondents found "84% of respondents are using or planning to use AI tools in their development process, an increase over last year (76%)."
The problem is scale. Code is generated and merged faster than a person can review it. After-the-fact human review cannot keep pace.
Faros AI's 2026 telemetry report, showing correlation not causation, found a 31.3% increase in pull requests merged without any review (human or agent).
The impact shows up in production. In a self-reported survey of 450 practitioners, Aikido's 2026 AI survey found "69% of organizations found vulnerabilities introduced by AI-generated code" and "1 in 5 experienced a serious security incident linked to it."
So the core question moves from securing one file to trusting the system producing all of them. The goal is to protect velocity, not gate it.
Where AI agents introduce risk
It helps to group the risks by three control points:
- What agents use
- What they do
- What they generate
Most agentic development risk fits into one of these buckets.
The sections below define each risk on first use. There is no need for alarm here, just a clear map of where to focus.
Insecure AI-generated code
Large language models (LLMs) learn from huge amounts of public code. They reproduce everything, even the weaknesses such as missing input validation, injection flaws, hard-coded secrets, and broken authentication.
You can see these patterns in a review of common AI code vulnerabilities. Traditional SAST (static application security testing), which scans source code for known bad patterns) catches many of them.
Some flaws are harder to catch. Agents also copy architectural design flaws, like reusing one secret across services or skipping an audit log. These do not map to a single rule, so rule-based SAST misses them.
The scale of the problem is measurable. In a controlled study of more than 100 LLMs, Veracode's 2025 GenAI study found 45% of code samples failed security tests and introduced OWASP Top 10 security vulnerabilities into the code. Java was the riskiest language, with a 72% security failure rate across tasks.
Hallucinated and malicious dependencies
A hallucinated package is a dependency an LLM invents. Slopsquatting is when an attacker registers the made-up package name, so the next agent that asks for it installs real malware.
Agents resolve and install packages on their own. This removes the human checkpoint where someone asks, "does that package name look right?"
Endor Labs research in the 2025 State of Dependency Management report found a clear gap. Only 1 in 5 AI-recommended dependency versions are safe, and 34% are hallucinated. Manifest-only tools miss this because they trust the name in the file, not the real package.
The pattern is widespread. Summarizing a USENIX Security 2025 study, package hallucination research from the Cloud Security Alliance found 440,445 samples (19.7%) contained at least one hallucinated package name. It also documented a hallucinated package spreading through 237 repositories via AI-generated agent skills.
There is a persistence problem too. The same research found 43% of hallucinated package names reappeared on every single run, which makes them easy targets to squat. Good detecting malicious packages practices help you catch these before install.
Untrusted tools and MCP servers
MCP (Model Context Protocol) is a standard way for an agent to connect to outside tools and data. Think of it as a plug that lets an agent read a database, call an API, or run a command.
Those tools inherit classic AppSec flaws. Endor Labs research on why MCP needs AppSec found that 82% of analyzed MCP implementations use file-system operations prone to path traversal. A majority also use sensitive APIs tied to code or command injection.
The ecosystem is also young and large. Endor Labs counted more than 10,000 MCP servers appearing in about a year, many built by individuals. Treat every MCP input and output as untrusted, and keep an inventory of which servers your agents can reach.
Prompt injection and excessive agency
Prompt injection is untrusted content that redirects an agent to do something it shouldn't. For example, text hidden in a web page or a file can tell the agent to leak data or run a command.
Excessive agency is when an agent has more access than the task needs. An agent that can run shell commands or reach production can turn a small prompt injection into a real problem.
The controls are standard. Give each agent the least privilege it needs, and require human approval for high-impact actions. The OWASP LLM Top 10 (2025) and OWASP Top 10 for Agentic Applications (2026) map these risks to specific controls you can adopt.
Best practices for securing agentic development
The goal is to keep developers fast while adding guardrails they barely notice. Controls that run at the moment of generation catch problems before they pile up as review debt.
The checklist below applies to any team, no matter which tools you use. Some teams also add automated AI security code review so every pull request gets a security-architecture check before merge.
- Establish trust at generation: Check code and dependencies as agents produce them, not only after commit.
- Treat AI output as untrusted: Validate generated code, packages, and tool responses the way you validate user input.
- Separate the prompter from the approver: Require a human approver for high-impact changes, and make sure it is not the person who prompted the agent.
- Verify packages before install: Confirm a package exists and is safe before an agent adds it to your project.
- Prioritize by reachability: Rank findings by whether they are exploitable in a deployed path, not by raw counts.
- Align to known frameworks: Map your controls to the OWASP LLM and Agentic Top 10, NIST SSDF, and NIST AI RMF.
How to prioritize what actually matters at AI scale
When agents merge far more code, finding counts explode. The real work is not finding issues. It is deciding which few actually matter, so developers are not buried in noise.
Reachability analysis checks whether a vulnerable function is actually called in a path your app runs, instead of just present in a file.
Here is how it works in plain language:
A tool builds a call graph from your source at build time. That graph maps which functions call which other functions.
Then it checks whether the vulnerable function sits on a path your deployed app can actually reach.
That first filter alone removes most of the list. Endor Labs found that less than about 9.5% of vulnerabilities are exploitable at the function level, so roughly 90.5% is noise.
The company also found about 95% of vulnerabilities come from transitive dependencies (packages your packages pull in), which you never chose directly. You can go deeper in this guide to function-level reachability analysis.
You then layer more filters to sharpen the list.
| Filter | Question it answers | Effect on the list |
|---|---|---|
| Reachability | Is the vulnerable function called in a deployed path? | Removes findings that are present but never run |
| EPSS | How likely is this flaw to be exploited in the wild? | Ranks the reachable findings by real-world risk |
| Environment | Is this in production or only in test code? | Drops findings that cannot affect production |
| Fix availability | Is there a safe upgrade or patch? | Sorts what you can act on today |
EPSS is the Exploit Prediction Scoring System, a public score that estimates how likely a flaw is to be exploited. Combining reachability with EPSS can cut noise by about 92% to 98%, according to Endor Labs.
A short example makes it concrete. Say a scanner flags a vulnerable OpenSSL function inside a container image. Reachability analysis checks the call graph and finds your app never calls that function.
The finding drops in priority. Your team spends its time on issues that are actually reachable.
How Endor Labs secures agentic development
The point of this section is developer time. The controls below aim to cut interruptions first, then reduce risk, using AURI, the security intelligence layer for agentic software development from Endor Labs.
Each capability maps to a risk from earlier in this guide. The numbers are outcomes teams have reported, not promises.
- AI SAST: Finds logic and design flaws using multi-file dataflow, with no rules to tune. It triages false positives so developers see fewer bad alerts.
- AI Security Code Review: Developer, architect, and security-engineer agents review every pull request for security-architecture changes.
- Reachability-based SCA: SCA (software composition analysis) inspects your open source dependencies, and reachability catches what manifest-only tools miss, including hallucinated and malicious packages.
- Evidence-based remediation: Upgrade impact analysis shows what changed between versions, and backported patches let you fix on your own timeline.
The results are specific. Endor Labs reports up to 95% noise reduction from full-stack reachability. Teams using its AI Code Security tools report 83% fewer blocked pull requests and 6x faster CVE remediation.
Detection quality matters too. In its context-aware AI SAST benchmark, Endor Labs found 2x more real vulnerabilities than any other tool tested. It works by indexing everything, triaging which functions need a closer look, then running deep dataflow only on those.
Frequently Asked Questions
What is agentic development security?
Agentic development security is the practice of securing the software development process when AI coding agents generate, select, and ship code. It covers the tools agents use, the actions they take, and the code they produce.
How is agentic development security different from DevSecOps or traditional AppSec?
Traditional AppSec assumes a human writes and reviews each change. Agentic development security adds controls that run continuously at machine speed, because agents generate and merge code faster than people can review it.
What are the main security risks of AI coding agents?
The main risks are insecure generated code, hallucinated or malicious dependencies, untrusted tools and MCP servers, and prompt injection paired with excessive agency.
What is slopsquatting or a hallucinated package?
A hallucinated package is a dependency an LLM invents that does not exist. Slopsquatting is when an attacker registers that fake name, so the next agent that requests it installs malware.
Does securing agentic development mean slowing down AI adoption?
No, the goal is the opposite. Catching issues at generation and prioritizing only reachable findings keeps developers fast by cutting interruptions and review debt.
Which frameworks apply to securing AI coding agents?
Use the OWASP LLM Top 10 and OWASP Top 10 for Agentic Applications for threats. Use the NIST SSDF and NIST AI RMF for secure development and AI risk management.
Conclusion: Getting Started With Agentic Development Security
The winning move is to secure code at the point of generation and prioritize what is actually exploitable. That keeps developers fast while cutting the noise that slows them down.
Start with three practical steps:
- Treat all AI-generated code, dependencies, and tool outputs as untrusted input.
- Add reachability-based prioritization so your team works only on findings that matter.
- Govern your tools, MCP servers, and dependencies with an inventory and clear approval rules.
Pick one repository, turn on reachability-based prioritization, and measure the drop in noise. When you want to see it across your stack, book a demo with Endor Labs.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: