AI is changing how software is built, tested, and secured, but the speed of development is also creating new challenges for application security teams. As AI coding tools and autonomous agents increase the volume and pace of software development, security teams are facing a growing gap between vulnerability detection, prioritisation, and remediation.
In this interview with
Rahul Sood, GM, Application Security at Harness, we explore how AI application security is evolving as developers increasingly rely on AI-assisted coding and software agents. Sood discusses why traditional checkpoint-based security processes are struggling to keep pace, how organisations can bring security controls closer to the point where code is created, and why automated
vulnerability remediation could become increasingly important.
The conversation also examines the
security risks associated with AI agents that can access repositories, APIs, infrastructure and production environments. Sood explains why identity, least-privilege access, observability and human oversight will become increasingly important as software gains greater autonomy, and why application security will need to address not only what software contains, but also what autonomous systems are authorised to do.
Read the full interview below for Rahul Sood’s perspective on the changing
application security landscape and the security challenges emerging as AI takes a more active role in software development.
The Cyber Express: What is the biggest change AI is bringing to the application security landscape?
Rahul Sood: The biggest change is speed. We have spent years making software development faster, and AI has accelerated that dramatically. Security processes, however, haven't accelerated at the same rate.
Most security scanning is still triggered at fixed checkpoints - a pull request, merge, or nightly build - designed for a world where a developer produces a handful of meaningful commits a day.
LLM-based scanning can potentially find 10x more
vulnerabilities vs. traditional scanning tools. That sounds great, but it also means the discovery side of the pipeline is now outpacing triage and remediation even more than it already was.
That's where AI agents also become part of the answer, not just part of the problem. An agent can identify something and begin acting on it in close to the same motion, which is exactly the kind of compression this gap needs. The challenge is making sure that speed is matched with the right judgment and oversight.
The Cyber Express: AI coding assistants can introduce insecure code at scale. What should teams be doing differently?
Rahul Sood: The instinct is to assume AI-generated code is introducing more vulnerabilities because AI is somehow worse at writing secure code. I don't think that's the real story. Even if AI wrote code exactly as securely as a person does, the sheer volume of code now being produced would still overwhelm the way most organisations scan for issues today.
Scanning at the commit is already struggling to keep pace, as we discussed. The next step is pushing security further left than that, into the coding tool or agent itself, so secrets detection, dependency checks, and application security testing happen as the code is being written, and those same controls continue through build and deployment rather than starting over at each stage. You need both: controls at the point of creation to cut volume, and a verification layer that confirms what's really going out the door.
I expect the industry to move from automated detection towards much more automated resolution. Systems will increasingly identify an issue, establish whether it is actually exploitable, create a potential fix, verify that fix and then bring a developer in where judgement or approval is required. Human oversight remains important, but it should be concentrated on decisions where human judgement adds value rather than every mechanical step surrounding them.
The Cyber Express: What new security challenges emerge when AI agents can make decisions and take actions?
Rahul Sood: A coding assistant can suggest something insecure, but there are usually other controls between that suggestion and production. An agent with access to APIs, repositories or infrastructure is different. It has been given authority to act. That makes identity, permissions and the scope of that authority fundamental security questions.
One principle I think will become increasingly important is that autonomy should be proportional to the consequence of the action. The more consequential and difficult an action is to reverse, the stronger the controls around it should be.
More broadly, enterprises will need a security architecture for non-human actors: distinct identities, least-privilege access, short-lived credentials, complete auditability and clear boundaries around which decisions an agent can make independently.
The important question isn't how autonomous an agent is. It's what we've given it the authority to do, where the boundaries are, and what happens when it gets a decision wrong.
The Cyber Express: What becomes harder to secure when applications behave dynamically?
Rahul Sood: AI-native applications introduce another layer because some risks only become visible through behaviour. The security question is no longer limited to whether the underlying code contains a known vulnerability. You also need to understand what the system is doing at runtime.
One of the more concerning findings in the AI-native application security research we conducted last year was how basic the visibility problem still was. Many security practitioners told us they didn't have a reliable way of identifying all of the LLMs operating within their environment. That's a significant problem because you cannot meaningfully govern something you don't know exists.
As applications become more dynamic, understanding behaviour becomes just as important as understanding what's in the code.
The Cyber Express: Is shift-left still enough?
Rahul Sood: Shift-left was an important correction because security was happening far too late. But moving security earlier in development doesn't solve the entire problem on its own, since
risk doesn't only enter through code. It can come through a dependency, an API, a model interaction, a deployment configuration, or the way an application behaves once it's actually running.
There is also a growing mismatch between how quickly vulnerabilities can be exploited and how long organisations take to remediate them. The 2026 Edgescan Vulnerability Statistics Report puts the average time to close high and critical vulnerabilities at roughly 55 days. At the other end of that equation, exploitation of newly disclosed vulnerabilities can now begin within hours.
Finding a vulnerability earlier is useful, but the more consequential metric is the period between discovery and protection. The next phase of application security is less about moving a scanner to an earlier point in the lifecycle and more about compressing the entire exposure window, from discovery to protection.
The Cyber Express: How can teams identify which risks actually matter?
Rahul Sood: Security teams don't have an alert problem as much as they have a context problem.
A vulnerability can have a severe technical rating and still present relatively little immediate risk if the affected component isn't reachable or exposed. Another vulnerability with a lower score could sit in an internet-facing, business-critical application and deserve immediate attention.
So prioritisation has to move beyond severity. That means combining technical severity with signals like EPSS scores for real-world
exploit probability, static reachability analysis to confirm whether a vulnerable path can actually be called, and false-positive reduction to cut out findings that never posed real risk in the first place.
The goal shouldn't be to help a security team process 10,000 alerts faster. It should be to make sure they don't have to treat 10,000 alerts as equally important in the first place.
The Cyber Express: What does a healthy developer–security relationship look like?
Rahul Sood: The healthiest organisations I've seen don't treat security as a handoff between two teams. Developers understand that security is part of building good software, while security teams take responsibility for making the secure path practical.
If following security policy means leaving the developer workflow, opening a ticket, waiting several days and then interpreting a scanner report, people will inevitably look for ways around the process. That's an operating-model problem, not simply a developer behaviour problem.
We saw how wide that gap had become in research we conducted last year. Seventy-four percent of security professionals surveyed said developers viewed security as a blocker to AI innovation.
Security teams should define acceptable risk, policies and guardrails. Engineering teams should then be able to work within those boundaries without constantly asking for permission. That is ultimately what a mature DevSecOps model should achieve. Security becomes part of the engineering system rather than another team standing beside it.
The Cyber Express: What one assumption should organisations rethink today?
Rahul Sood: One assumption I would rethink is that knowing what software contains is enough to understand its security posture.
Application security has traditionally been very good at analysing components: the code, libraries, dependencies, APIs and vulnerabilities that make up an application. But with autonomous software, knowing what it's made of is only part of the picture. We also need to understand the authority we've given it.
An agent may be built from approved components and have no obvious vulnerability in its code, yet still create significant risk because it can access the wrong
data, has excessive permissions or can take an action that was never anticipated when those permissions were granted.
We have spent decades building security around software that executes instructions written by people. We are now introducing software that can interpret a goal, decide how to pursue it and interact with other systems along the way.
The security architecture for that world cannot rely only on finding vulnerabilities. It also has to govern delegated authority. I think that will become one of the defining application security problems of the agentic era.
Want to Be Part of Security Pill?
Are you a cybersecurity professional, researcher, CISO or industry expert with insights to share? The Cyber Express is always looking to bring new voices and perspectives to the cybersecurity community.
If you would like to be featured on Security Pill or discuss a potential podcast collaboration, reach out to us at [samiksha.jain@thecyberexpress.com].
Have a story, expertise, or perspective to share? Let’s start the conversation.
Login
