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.

The EU KIDS Act is set to introduce new age restrictions and safety requirements for children using social media and other online services across the European Union. The European Commission adopted the proposal on September 18, setting out rules that would prevent children under 13 from accessing social media and establish 15 as the minimum age for minors to open accounts independently. European Commission President Ursula von der Leyen discussed the proposal during a high-level dialogue on protecting children's rights in the face of artificial intelligence, pointing to growing concerns over children's exposure to online platforms and digital technologies.

EU KIDS Act Introduces Age Restrictions

Under the EU KIDS Act, children under 13 would not be permitted to access social media platforms. Children between 13 and under 15 would also not be allowed to create autonomous accounts. Instead, users in that age group could access mini accounts managed through a parent or guardian's account. These accounts would provide access to age-appropriate social media and video-sharing services, while including restrictions on social contacts and screen time. The proposal sets a limit of up to 60 minutes of screen time per day for these accounts. Parents would have the ability to reduce the permitted time. Children between 3 and under 13 would not be allowed to access social media. However, they could use specially designed child-friendly video-sharing services through guardian-managed accounts. Parents would also receive tools to restrict an adult device to those services when it is given to a child, with usage limited to a maximum of one hour per day.

Platforms Would Face Greater Safety Responsibility

A key part of the EU KIDS Act is a proposed shift in the burden of proof. Under the proposal, online platforms and service providers would have to demonstrate that their services are safe by design and appropriate for younger users. Von der Leyen said the current process under the Digital Services Act and Digital Markets Act can take months to assess whether algorithms are harming children, followed by discussions with platforms and further changes. She argued that the process can take several years before penalties are imposed, while children may continue to be exposed to potentially harmful algorithms during that period. The proposed approach would instead place responsibility on platforms to prove that their services are safe for children. If they cannot demonstrate this, they would not receive access to children under the proposed framework.

EU Raises Concerns Over Children's Online Exposure

During her speech, von der Leyen cited figures from the July Eurobarometer, saying 92% of Europeans surveyed believe more should be done to protect children online. She also said young people in Europe spend an average of four to six hours a day on screens, while those who began using them before the age of 10 spend around seven to eight hours online. Von der Leyen said many digital platforms are designed to capture users' attention and monetise it, while not necessarily being developed with children's wellbeing and development in mind. The European Commission had previously convened a panel of experts for six months, including representatives from civil society, parent organisations and youth groups, to examine possible measures. The EU KIDS Act now proposes a framework focused on age restrictions, parental supervision and greater responsibility for online service providers. Von der Leyen said the issue is not simply whether children should access social media, but how and when digital services should be allowed to reach them.

Cyber attackers are gaining an advantage from artificial intelligence that defenders cannot yet match, according to a senior official at the UK’s National Cyber Security Centre (NCSC). Dave Chismon, the NCSC’s chief technology officer for architecture, warned that AI-enabled cyber attacks could grow as organisations struggle to use automated systems for defensive actions without putting their own operations at risk.

The problem is not simply whether AI can perform a cybersecurity task. For defenders, an automated action can affect live systems, business operations and critical services. That means security teams have to consider what could go wrong before allowing AI to act on its own.

Why Defenders Cannot Use AI Like Attackers

Chismon draws a clear distinction between offensive and defensive cybersecurity.

For attackers, many of the problems are technical. They may need to find an exploit or work out how to avoid detection. The objective is often clear: compromise a system, make malware communicate with its controller or steal information.

Defenders face a different set of obstacles. Getting an outdated system replaced may require budget approval. Applying a patch could affect another service. A firewall change may need to go through a formal approval process.

As Chismon explains, defenders are often restricted by organisational policies, while attackers are more likely to be restricted by technical problems. Cybersecurity is also a cost for most organisations rather than their primary business function, making security decisions subject to competing priorities.

That difference matters for agentic cyber defence. AI systems can work well when they are given a technical problem and a measurable result. Defensive actions are harder because there may not be a single clear success state, and someone still has to take responsibility for what the system does.

AI-Enabled Cyber Attacks: NCSC on AI Automation

The NCSC is not arguing that defenders should avoid AI. Instead, Chismon says organisations need to account for the constraints around defensive actions.

Some security tasks are already suitable for greater automation. Penetration testing, vulnerability research and vulnerability discovery can be carried out in controlled environments, with findings passed to development teams for remediation. Vulnerability scanning can also become a routine process once an organisation is satisfied that the activity will not disrupt its systems.

Security operations centres offer another example. Establishing a SOC involves policies, legal considerations and moving data from live systems into platforms where suspicious activity can be detected and investigated. The resulting alerts can then be handed to human teams for action.

Chismon identifies three principles for this model: technology handles detection while humans take action, detection must not damage the organisation, and automated responses should remain tightly controlled and limited in scope.

Measuring the Risk Before AI Acts

The NCSC framework looks at five areas when assessing whether a defensive action is suitable for automation: potency, scope, criticality, rollout confidence and recoverability.

Potency considers what an AI system is actually allowed to do. At the lowest level, it may only provide information and advice to a human. At higher levels, it could collect information autonomously, change system data or configuration, or execute code.

Scope considers how many systems could be affected, while criticality looks at whether those systems support important business or mission functions. Rollout confidence examines how well the action can be tested before deployment. Recoverability considers how easily an incorrect action can be reversed.

For now, Chismon suggests starting with lower-risk actions. AI can already help defenders process large amounts of security information, summarise reports and threat intelligence, and help teams prioritise what requires attention.

Research Could Expand Autonomous Defence

The NCSC and the UK Department for Culture, Media and Sport are working on Cyber Shield, described as a national-scale agentic cyber defence ecosystem. The NCSC also plans to publish an “AI for Cyber Defence” problem book covering areas where further research is required.

One key question is whether organisations can prove that an automated defensive action is genuinely low risk. Chismon points to areas such as analysing traffic logs and understanding the network connections or processes a system may require.

That evidence could eventually allow organisations to automate more defensive actions, harden systems and reduce their attack surfaces. But Chismon cautions that this will require further research and that organisations should continue strengthening their security through conventional measures while autonomous cyber defence develops.