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 Australian Signals Directorate (ASD) has released new guidance on Agentic AI Harnesses, highlighting the security, governance and operational risks organisations need to consider as they adopt agentic AI systems. The publication shifts attention beyond large language models (LLMs) to the software layer that connects models with organisational data, tools and systems. According to ASD, the AI harness is a critical component of an agentic AI system because it determines what information an agent receives, which tools it can access, what actions it can perform and what controls are applied.

Why Agentic AI Harnesses Matter

An agentic AI system combines an LLM with external tools, data sources, memory and planning workflows. While the LLM processes information and proposes actions, the harness provides the surrounding infrastructure needed to execute those actions and enforce permissions. ASD said many significant organisational risks emerge when an LLM is connected to enterprise systems through a harness. Security, privacy, governance and operational risks can depend on what an agent can access, the actions it can perform and how it interacts with connected systems. The publication also notes that some risks, including prompt injection, cannot be reliably addressed within the model alone. Additional controls are required across the harness, connected systems and organisational governance processes.

Harness Becomes a Long-Term Security Focus

ASD describes the harness as the component organisations can most directly govern, secure and control. While LLMs can be replaced as models evolve, the harness and its surrounding integrations are expected to represent a longer-term organisational investment. The harness can manage context and memory, provide access to tools, enforce execution privileges and record activity for monitoring and evaluation. Its components can include a user interface, policy layer, context manager, model interface, tool registry, permission system, execution environment, connector layer, memory and session store, and audit and observability capabilities. [caption id="attachment_114032" align="aligncenter" width="600"] Image Source: ASD- https://www.cyber.gov.au/[/caption] This makes the harness a key configuration surface for agentic AI security, particularly where organisations need to control tools, permissions, approvals and system integrations.

ASD Highlights Key Agentic AI Risks

The guidance identifies five broad risk categories associated with agentic AI systems: privilege, design and configuration, behavioural, structural and accountability risks. Excessive privileges can allow a compromised agent to have far-reaching access, while insecure architecture or configuration can introduce weaknesses before deployment. Behavioural risks include unintended actions and manipulation through techniques such as prompt injection and data poisoning. Structural risks can emerge when failures cascade across interconnected components and workflows. Accountability risks may arise when complex agentic systems make it difficult to trace decisions, audit actions or assign responsibility. ASD also recommends treating multi-agent systems as a single agent for security purposes because a compromise in one component may propagate through shared context and trust relationships.

Security Controls for Agentic AI

The publication recommends established cybersecurity practices, including least-privilege access, identity and access management, secure design, monitoring and incident response. Organisations are also advised to require human oversight for high-impact actions, control access to external data and tools, validate agent outputs, maintain audit logs and apply supply-chain assurance. ASD recommends a phased approach to deployment, beginning with approved use cases, appropriate data classification and security validation before broader adoption. The guidance also stresses that no harness is inherently secure. Organisations should select harnesses appropriate to their tasks, understand their capabilities and permissions, and apply controls across multiple layers rather than relying solely on model behaviour or prompts. For executives and CISOs, ASD recommends asking what data and systems an agent can access, what actions require human approval, how AI-specific attacks are mitigated, whether significant actions can be monitored and audited, and what could happen if the harness were compromised or misconfigured. As agentic AI adoption expands, ASD's guidance positions the harness as a central part of managing the technology's security, governance and operational risks.

Ghostcommit is a proof of concept that shows how AI assistants used to review software code can be tricked by hidden instructions embedded in images.

The academic ASSET Research Group showed that an attacker can place instructions inside an image file, point to it in an AGENTS.md file, and get an AI coding agent to follow those instructions during a later task.

A pull request is basically a formal “please review and add my changes” request that a developer sends before changes are added to the main version of a software project. Human reviewers and, increasingly, AI coding tools may review the changes before they’re accepted.

While AI-assisted code review is becoming part of everyday development, Ghostcommit exposes a weakness many teams have not considered. A human reviewer may read the code and skip an attached image. In the researchers’ proof of concept, the malicious instructions were hidden inside a PNG file referenced by repository policy files, while the visible pull request looked ordinary.

As the researchers demonstrated, this can turn routine developer workflows into a channel for stealing secrets. An AI coding agent reads those hidden instructions, even though a human reviewer is unlikely to inspect the image.

The attack is simple in concept but dangerous in practice. A pull request introduces a harmless-looking image and a configuration file that tells the agent to trust it. When the agent later works on a normal task, it follows the hidden instructions, reads sensitive files, and writes the secrets back into the code in an obfuscated form. That creates a path for secret theft that may slip past both human reviewers and automated scanners.

The researchers found that the harness—the wrapper around the AI model—had a bigger impact on whether secrets were leaked than the underlying model itself. In practice, the harness (Cursor, Antigravity, Claude Code) decides which files to load, which conventions to trust, what guardrails to apply, and whether to follow instructions buried in an image. As a result, the same model can behave very differently depending on the coding tool that uses it. The model then carries out whatever task the tool presents.

For example, the same model (Claude Sonnet) behaved very differently in different tools. Under Cursor and Antigravity, Sonnet read the PNG, followed the convention, and dutifully recorded the secrets in the source code. But under Anthropic’s Claude Code harness, the same Sonnet model read the same convention and refused, explicitly stating that exfiltrating secrets was inappropriate. Claude Code refused under every model the researchers tested.

How to stay safe

The lesson is that prompt injection is no longer just a text problem. Multimodal inputs like images can also carry instructions that AI agents may obey if the toolchain allows it. Teams should assume that anything a coding agent can read—including images, documents, and other multimodal inputs—could contain attacker-controlled content.

Organizations using AI coding tools should treat this as both a software supply chain and AI agent security issue. The most important defenses are to restrict access to secrets, inspect non-text attachments, and monitor AI agents for unusual attempts to read credentials or config files.

The research also highlights that the coding tool and its permissions are ultimately what make this attack possible, rather than the AI model in isolation.

---

We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.