If you walked the expo floor at RSAC this year, you already know how crowded the word "agentic" has become. DTEX counted roughly 650 exhibiting vendors at RSAC 2026 and joked that just about every one of them was emphasizing agentic AI. Forrester's recap of the conference made a similar observation with a sharper edge, noting that agentic AI showed up everywhere but often felt pasted onto security messages that could have been written years earlier.
Application security has not escaped the trend. There is agentic SAST, agentic DAST, autonomous pentesting, AI remediation and agentic code review, and many of these products are genuinely impressive in a demo. The trouble is that the label has spread much faster than the engineering required to back it up. This post explains what agentic AppSec actually means, why so much of what carries the name falls short in production and what security leaders should look for before trusting an agent with real security decisions.
Key takeaways
- Agentic AppSec uses AI agents that can plan, investigate, use tools and make bounded decisions to perform security work, inside a system that supplies context, evaluates results and escalates to people when needed.
- Gartner estimates that only about 130 of the thousands of vendors claiming agentic AI capabilities offer the real thing, and it predicts that more than 40 percent of agentic AI projects will be canceled by the end of 2027.
- Most agentic security products today are a capable model wrapped in a thin harness, which means their accuracy rises and falls with whatever the underlying model happens to do on a given day.
- The hardest parts of agentic AppSec are orchestration, measurement and evaluation, and they are also the parts that rarely appear in a demo.
- Buyers should ask where control lives in the system, how results are measured over time and what happens when the model, the code or the cost budget changes.
What is agentic AppSec?
Agentic AppSec is the use of AI agents to perform application security work such as code review, vulnerability verification, policy enforcement and remediation, where the agents can plan an investigation, gather the context they need, use tools and reach conclusions within defined boundaries. What separates it from earlier uses of AI in security is that the agent is doing part of the investigative work a human AppSec engineer would do, rather than summarizing output from another tool or answering questions in a chat window.
That definition comes with an important qualifier. An agent on its own is not an AppSec program. For agentic security to be dependable, the agents need to operate inside a larger system that establishes facts about the codebase, decides which questions deserve probabilistic reasoning, checks the agents' work, preserves what was learned and knows when to hand a decision to a person. Most of the confusion in the market comes from treating the agent as the product when the surrounding system is what actually determines whether the results can be trusted.
Where the buzzword is showing up, and why that is a problem
The agentic label is not limited to security, but security has embraced it with particular enthusiasm. Analysts at Constellation Research observed at RSAC that vendors are using the same terms to describe very different architectures and operating models, which makes it hard for buyers to compare what they are actually being offered. Forrester made a related point about the agentic SOC, noting that most vendors using the term mean having AI agents in general rather than agents that coordinate with one another in any meaningful way.
Gartner has a name for the worst version of this. In a 2025 prediction, the firm described "agent washing" as the rebranding of existing assistants, chatbots and automation tools as agentic without adding substantial agentic capability, and estimated that only about 130 of the thousands of agentic AI vendors are real. The same report predicted that more than 40 percent of agentic AI projects will be canceled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls.
For AppSec, the consequence is more than wasted budget. In AppSec: The Next Generation, DryRun Security co-founder and CTO Ken Johnson argues that much of the industry is using AI to rebuild the same tools we already had, replacing pieces of the old machinery with agents instead of rethinking how security work should be done. A scanner with an agent attached may produce nicer explanations, but if it still hands the same pile of findings to the same overloaded people, the security outcome has not changed.
Why the execution isn't there yet
The gap between agentic marketing and agentic reality is not a mystery. It comes from a handful of engineering problems that are easy to underestimate when a prototype is working well.
It's just not reliable
The first problem is illustrated in Your Agent Harness Is Not an Orchestration Layer where Ken describes a pattern that shows up in a lot of agentic products. A team takes an agent framework, gives a strong model some tools, skills and a good system prompt, and then credits the sophistication of the harness when the model does something impressive. In practice, the model is still deciding what matters, which tools to use, what evidence to trust and whether its own answer is good enough. The harness makes the model more capable, but it does not make the system reliable.
The risk is that accuracy becomes whatever the model happens to deliver that day. When a probabilistic step misidentifies the framework an application uses, and later steps reason about authentication and authorization based on that mistake, the result is not one error but a chain of plausible conclusions built on a false premise. DryRun's approach is to establish facts that can be known deterministically, such as repository structure, application boundaries and framework composition, before asking a model to interpret their security significance. Ken also points out that giving an agent access to deterministic tools is not the same as orchestrating it, and that pairing a traditional scanner with an LLM validator still lets the scanner define what the system is able to find.
He shares a story that illustrates why so many teams get stuck. One company put an engineer on building its own AI security reviewer, got impressive early results, then watched developer complaints about noise pile up. A better model helped briefly, a second engineer joined to fight false positives and inference costs kept climbing, yet the tool never crossed from promising to dependable. The first 80 percent of an agentic security system can come together remarkably quickly, which is exactly why the remaining 20 percent, the part that actually makes it a product, is so often underestimated.
Nobody can prove it works
The second problem is measurement. In The AI Security Industry Has a Measurement Problem, Ken describes what he calls the three-week trap. An engineer builds an internal harness, it finds a few real vulnerabilities and leadership starts asking why the company is still paying for security products, consultants and specialists. That reaction is understandable, but it skips the questions that determine whether a security program can depend on the tool, such as whether it finds the same issue tomorrow, whether it finds it a hundred times in a row and whether anyone would notice if it quietly got worse.
Agentic systems make those questions harder to answer because their behavior varies from run to run. The same code can lead an agent down a different investigation path, and the same underlying flaw might be labeled an authorization bypass in one run, an insecure direct object reference in the next and broken access control after that. The code and the vulnerability did not change, but the severity, evidence and recommended fix might. That variability is acceptable in an experiment and a serious problem in a security program, which is why measurement has to be treated as part of the product rather than an afterthought.
Evaluation is treated as a feature instead of the control plane
Measuring an agentic system once is not enough, because models, prompts, codebases and usage patterns all keep changing. DryRun Security Senior Engineer Peter Karman laid out how we handle this in Constructing a Trustworthy Evaluation Methodology for Contextual Security Analysis. Each pull request moves through a multi-pass pipeline that looks at the change as a whole, reasons about individual code hunks and pulls in additional context only when it is needed. Every day, a separate, version-segregated model audits a random sample of production findings for instruction compliance, hallucinations and vulnerability correctness, and anything that fails goes to human review and feeds the next round of improvements.
The detail about version segregation matters more than it might seem. Ken makes the point that simply adding a judge agent does not fix a system if the judge receives the same flawed evidence as the agent it is checking, because two models confidently agreeing with each other is not the same as independent confirmation. Real evaluation looks at the conditions that produced an answer, including what context was assembled, which tools returned what and where an earlier decision may have poisoned a later one. Without that visibility, a team has no reliable way to know whether a change made the system better or worse.
Agents are bolted onto the old operating model
The last problem is strategic rather than technical. Gartner's guidance on agentic AI is to rethink workflows instead of bolting agents onto legacy systems, and AppSec is a textbook case. In AppSec: The Next Generation, Ken argues that categories like SAST, DAST and SCA are better understood as ways of collecting evidence than as separate workflows with separate sources of truth. An agentic system should start from the question it needs to answer and then choose the evidence and technique that fit, rather than reproducing each acronym as its own autonomous product.
The same applies to oversight. If every agent decision requires a human click, approvals become a bottleneck or a ritual. Ken describes a model where people stay on the loop instead, defining what an agent is allowed to do, what evidence it must collect, what error rate is acceptable and what conditions trigger escalation. Autonomy in that model is a permission that is earned through demonstrated performance and can be narrowed or revoked when the evidence says it should be.
What real agentic AppSec looks like in practice
It helps to see how long the road from idea to dependable agent actually is. In How We Turned Natural Language Into a Scalable Agentic AppSec Engine, Ken walks through the history of what became DryRun's Custom Policy Agent. It started as a YAML file that let a team ask a plain-English question about a pull request, such as whether a change modified authentication logic. Early versions struggled with repeatability, accuracy and limited context because we could only see code inside the diff.
Each stage after that was about building the system around the model. We rebuilt the evaluation layer for accuracy and repeatability, added a Policy Builder so users could test policies against real repositories before deploying them and introduced agents that could pull in wider repository context, research frameworks from approved sources and check dependencies and licenses. We also learned that natural language alone was not enough, because people phrase questions in very different ways and ambiguity creates drift, so we built a Policy Assistant to help users write precise, testable policies.
None of that is visible in a thirty-second demo, and all of it is what makes the difference between an agent that occasionally impresses and one a security team can rely on every day.
How to evaluate an agentic AppSec vendor
If every vendor on your shortlist calls itself agentic, the label stops being useful. These questions do a better job of separating real capability from agent washing.
- Where does control live? Ask which parts of the system are deterministic and which rely on model reasoning, and why. A vendor should be able to explain how it establishes facts about your code before an agent starts interpreting them.
- What happens when the model changes? A well-orchestrated system benefits from better models without depending on them. If a model swap would fundamentally change the product's behavior, accuracy is being outsourced to the model provider.
- How do you measure accuracy over time? Look for a defined test set, repeatability data, false negative analysis and a way to detect when the system has quietly degraded.
- How do you evaluate results in production? Ask whether findings are independently audited, how often and by what kind of process, and what happens to findings that fail.
- How are findings tracked across runs? If the same vulnerability can appear under different names on different days, ask how the system fingerprints and deduplicates issues so your team is not triaging the same problem twice.
- What can the agents do on their own? Get specific about what actions are autonomous, what evidence is required and what conditions cause the system to escalate to a person.
- What does it cost at scale? Token budgets are becoming a real line item. Ask how the system avoids spending model reasoning on questions traditional software can answer and how cost per finding behaves as usage grows.
Frequently asked questions about agentic AppSec
What is the difference between agentic AppSec and AI-powered SAST?
AI-powered SAST usually applies a model to a specific step, such as explaining a finding, suggesting a fix or filtering scanner results. Agentic AppSec gives agents a role in the investigation itself, letting them plan, gather context, use tools and reach bounded conclusions within an orchestrated system that evaluates their work.
What is agent washing?
Agent washing is Gartner's term for rebranding existing products such as AI assistants, chatbots or automation tools as agentic AI without adding substantial agentic capabilities. Gartner estimates that only about 130 of the thousands of vendors making agentic claims offer genuine agentic solutions.
Why do agentic AI projects fail?
Gartner attributes most cancellations to escalating costs, unclear business value and inadequate risk controls. In application security specifically, projects tend to stall when teams depend on the model for accuracy, lack a way to measure results over time and underestimate the engineering required to move from a working prototype to a dependable production system.
Can we build our own agentic AppSec tool?
Many teams can build a promising prototype quickly, and doing so is a valuable way to learn. The harder work is everything that comes after the first real finding, including evaluation, observability, repeatability, deduplication, cost control and handling failures at scale. Teams considering a build should plan for that work before making decisions about tools, vendors or headcount.
The word is easy but the work is not.
Agentic AI is a real and important shift for application security, and agents are already finding vulnerabilities that older tools miss or bury in noise. That is exactly why the label deserves scrutiny. The products worth trusting will be the ones that can show how their agents are orchestrated, measured and governed, not just what they found in a demo.
DryRun Security has spent years building the system around the model, from deterministic context and specialized analyzers to continuous evaluation and the Custom Policy Agent. If you want to see what agentic AppSec looks like when the execution is there, book a demo and we will show you how it works in your own repositories.
.png)
