The Future of AppSec Is Not More Scanners .. It’s Agentic workflows

For years, application security has been built around an assumption that vulnerability discovery is relatively expensive. Attackers need time to understand an application, inspect its behaviour, search for weaknesses and work out whether those weaknesses can actually be exploited.

Defenders have therefore been able to rely on processes that are often periodic and human-heavy: SAST runs in the pipeline, penetration testing happens at certain points, AppSec teams review important changes, and developers work through findings as part of the normal engineering backlog.

Frontier AI models are beginning to challenge that assumption. Models can increasingly read large codebases, reason about how different components interact, analyse patches, identify suspicious data flows and explore potential vulnerabilities at a scale that would previously have required significant human effort. The important point is not that every attacker suddenly becomes an elite vulnerability researcher. It is that much of the expensive work involved in vulnerability research is becoming cheaper and easier to automate.

That changes the defensive question. If attackers can use AI to inspect our software more quickly, then simply finding vulnerabilities and putting them into a backlog is not enough.

The time between vulnerability discovery and verified remediation starts to matter much more.

That is why I wanted to experiment with a different AppSec workflow.

A developer opens a pull request. The normal checks run, including unit tests and SAST. Then an AI security reviewer examines the code change and finds a vulnerability.

Instead of creating another generic ticket, it explains the issue directly inside the pull request.

A second AI agent proposes a minimal patch. Tests and SAST run again.

A third agent independently checks whether the original vulnerability has genuinely been removed.

Finally, another agent summarises the entire security lifecycle for the developer.

The developer still makes the final decision and remains responsible for the merge. But a large amount of the repetitive work between finding the problem and reaching a verified remediation has been compressed.

That is the workflow I wanted to build, and I think it gives us a useful glimpse of where application security is heading.

The Problem Is Not Finding More Vulnerabilities

A few years ago, simply getting security testing into the software development lifecycle felt like a significant achievement. Organisations worked hard to integrate SAST into CI/CD, introduce dependency scanning, detect secrets earlier, conduct threat modelling and make sure important applications received penetration testing. Those controls are still essential.

The problem is what happens after they find something.

Imagine a SAST tool flags a high-severity issue in a pull request. The developer now has to understand what the scanner is actually telling them, locate the affected code, determine whether the finding is genuine, understand the root cause, decide how to remediate it, write the patch, run the relevant tests and potentially send the result back to AppSec for verification.

The scanner may have produced the finding in seconds, but the remediation cycle can take hours or days. This is the same security velocity problem that exists in vulnerability management and incident response. The technology is fast, but the process around it is still heavily dependent on human interpretation and coordination.

That led me to a simple question: what if AI handled more of the analysis and remediation work, while humans focused increasingly on verification and judgement?

The Workflow Starts Where Developers Already Work

I deliberately built the workflow around GitHub rather than creating another security portal. That might sound like a small design decision, but I think it matters.

Security works best when it becomes part of the developer's existing workflow rather than forcing developers to jump between a scanner, ticketing platform, security dashboard and messaging system just to understand what went wrong. If the vulnerability was introduced in a pull request, then the pull request is also one of the best places to explain and remediate it.

The developer therefore makes a code change and opens a PR as normal. Traditional tests and SAST still run first. AI is not being used to replace deterministic controls; it is adding a reasoning layer on top of them.

Once those checks complete, the first agent enters the workflow.

Agent One: The Security Reviewer

The Security Reviewer has read-only access to the repository. That limitation is deliberate because this agent's job is not to change anything. Its job is to understand the pull-request diff, inspect the relevant surrounding code and identify meaningful security weaknesses.

In my demonstration, the developer introduces a straightforward SQL injection vulnerability by constructing a database query using untrusted input. The AI reviewer identifies the problem and leaves a comment directly inside the PR. Instead of merely reporting "SQL Injection — HIGH," it explains which file and function are affected, how the unsafe input reaches the query, why that creates a vulnerability and what type of remediation should be considered.

That difference is important. Developers often complain about security findings because the scanner tells them that something is wrong without giving enough context to understand why. An AI reviewer can potentially bridge some of that gap by turning a scanner-like finding into a developer-friendly explanation.

But finding and explaining the issue is still only the first half of the problem.

Agent Two: The Security Fixer

The second agent receives more authority. It is allowed to modify the pull-request branch, but its permissions remain deliberately narrow. It cannot merge the PR, deploy the application or change production. Its job is simply to take the verified finding and create the smallest safe remediation.

In the SQL injection example, the appropriate fix is to replace the dynamically constructed SQL query with a parameterised one. The agent makes that change and can also add or update a regression test to ensure the original problem does not return.

Once the patch exists, the normal engineering controls run again. Unit tests run. Security tests run. SAST runs again. If those checks fail, the workflow does not pretend that the vulnerability has been resolved.

This is an important point when thinking about agentic security systems. Generating a patch is not the same as proving that the patch is correct. AI can make remediation faster, but that does not mean we should lower the standard of validation.

Agent Three: Independent Verification

This is probably the most important part of the workflow.

The agent that created the fix does not get to certify its own work.

A separate Security Verifier receives a fresh version of the repository along with the original finding, the updated code, the test results and the scanner output. Its job is to independently determine whether the vulnerability has actually been removed.

The verifier checks whether the original unsafe path remains, whether the remediation addresses the root cause, whether an obvious equivalent weakness still exists and whether the tests genuinely exercise the security condition. It can conclude that the issue is fixed, not fixed, or that human review is required.

That last option is important. An AI security workflow should be able to say, "I do not have enough confidence to approve this." The objective is not maximum autonomy. It is useful automation with clear boundaries.

The principle I keep coming back to is simple:

AI proposes. Independent verification confirms.

Agent Four: Explain Everything to the Developer

By this stage, quite a lot has happened. The original vulnerability has been identified, a patch has been proposed, tests have run, SAST has run again and an independent security agent has reviewed the result.

That creates another problem: information overload.

So the final agent has a much simpler job. It summarises the complete AppSec lifecycle in one developer-friendly comment. It explains what vulnerability was introduced, why it mattered, how it was fixed, what validation was performed and whether independent verification passed.

The developer no longer has to piece together the story from several separate tools. They can see the entire security journey inside the PR where the change originally happened.

That is an underrated part of security automation. Good automation should not just perform work faster. It should make the result easier for humans to understand.

The Developer Has Not Disappeared

Whenever AI enters a development or security workflow, the conversation quickly turns to replacement. If an agent can review the code and another agent can fix it, does the developer still matter?

I think that is the wrong way to look at it.

The developer still owns the final code change. They still need to review the proposed remediation, understand any impact on the application and decide whether the pull request should be merged.

What changes is where their time is spent.

Traditional AppSec often gives the developer a problem: "Here is a vulnerability. Go and understand it, work out how to fix it, write the fix and come back when you are done."

The emerging model gives them something much closer to a decision: "Here is what was found. Here is the evidence. Here is a proposed remediation. Here are the test results. Here is an independent security verification. Do you agree?"

The developer moves up the decision stack. So does the security engineer.

That, to me, is a much more realistic view of how AI changes security work.

This Is Where AppSec Is Heading

I do not think every organisation will implement exactly this workflow. Some will use GitHub Actions, others GitLab, Azure DevOps or commercial AppSec platforms. The models will change, the tools will improve and many of these capabilities will probably become native features inside developer platforms.

The underlying operating model is the important part.

Application security increasingly moves from find vulnerability → create ticket → wait for human remediation toward find → explain → propose remediation → test → independently verify → human approves.

That matters because frontier AI is not only becoming useful to defenders. The same capabilities that allow defenders to analyse code more deeply and more frequently will increasingly be available to attackers as well.

If vulnerability discovery accelerates while remediation remains entirely human-bound, the gap between the two becomes wider.

That is the real AppSec challenge of the frontier-model era.

The goal is not simply to find more vulnerabilities. We already have plenty of tools capable of producing more findings.

The goal is to shorten the distance between a vulnerability being introduced and a verified remediation being ready for a human to approve.

That is why I built this workflow.

And I suspect that within a few years, the idea of an AI agent reviewing a pull request, another proposing a security patch and a third independently verifying the result will feel much less experimental than it does today.

Thanks for reading this !

If you find this topic interesting .. I explore this operating model in much more detail in my new course, The CISO Playbook for Frontier Model Attacks.

Taimur Ijlal is a multi-award-winning, information security leader with over two decades of international experience in cyber-security and IT risk management in the fin-tech industry. Taimur can be connected on LinkedIn or on his YouTube channel "Cloud Security Guy" on which he regularly posts about Cloud Security, Artificial Intelligence, and general cyber-security career advice.