TOPIC: SOFTWARE TESTING
Agentic AI: Moving Complexity Rather Than Removing It
17th September 2026
Agentic artificial intelligence is often presented as a way to simplify software development and digital work. Instead of requiring a person to define every stage of a process, an agent can be given an objective and left to determine how to achieve it. This could involve writing code, inspecting files, using software tools or carrying out a sequence of routine tasks.
However, agentic AI does not eliminate complexity so much as relocate it. The detailed instructions that once had to be written by a human do not simply disappear, and they are instead replaced by a different set of technical and security requirements intended to control what the system is allowed to do.
In traditional automation, the relationship is relatively direct. A human specifies the exact steps and a computer executes those steps, and while the system may still contain considerable complexity, its behaviour is largely defined in advance. If the instructions are correct and the environment behaves as expected, the computer follows the intended process.
Agentic automation changes that arrangement. A human specifies an objective and the agent decides which steps to take, which can make automation more flexible, particularly when a task involves uncertainty or requires a degree of judgement. It can also reduce the amount of detailed planning required from the person using the system.
The important difference is that the computer is no longer merely carrying out a fixed sequence. It is choosing a sequence of actions, and once that happens, the central question changes. Instead of asking only how a task should be automated, it becomes necessary to ask what authority can safely be given to a system that decides how to automate it.
The New Security Boundary
An agent may need access to files, software tools, external services or online information. It may need to run commands, create documents or introduce changes to an environment, and while these abilities can be useful, they also create opportunities for mistakes. An agent could misunderstand its task, execute an inappropriate command or follow an instruction hidden in a file or web page.
For that reason, agentic systems need more than capable models. They also need a surrounding structure that limits the consequences of poor decisions, and this structure can include sandboxes, file system scopes, network policies, credential proxies, approval gates, audit trails and recovery mechanisms.
A sandbox can provide an isolated environment in which an agent carries out its work without gaining unrestricted access to the wider system. File system scopes can determine which files an agent can read or change, while network policies can restrict where it can connect and credential proxies can prevent sensitive passwords or access tokens from being handed directly to the model. Approval gates can require a human decision before a consequential action is completed.
Audit trails and recovery mechanisms are equally important. An audit trail helps show what the agent attempted, which tools it used and what changes it made, and recovery mechanisms make it possible to undo unwanted changes or restore an earlier state. Together, these features recognise that an agent can fail even when it is operating in good faith.
This approach differs from relying on the model to make the correct decision every time. The safer assumption is that a serious mistake will eventually occur, so the system should be designed so that a mistake has limited consequences rather than depending entirely on the agent recognising the danger in advance.
That principle is familiar from other areas of computing. Security systems commonly rely on the principle of least privilege, in which a process receives only the access it needs. Default-deny policies block access unless it has been explicitly permitted, isolation separates one process from another and mediated credentials ensure that access to sensitive services is controlled by an intermediary.
None of these measures requires software to behave perfectly. They are intended to remain useful when an application is compromised, incorrectly configured or simply wrong, and applying the same thinking to AI agents is becoming increasingly important as their ability to use tools expands.
Capability Has Advanced Faster Than Safe Delegation
The capabilities of AI systems have developed quickly, but the mechanisms for delegating authority safely have not always advanced at the same pace. An agent may now be able to complete a coding task that once required substantial manual effort, yet the process of giving it access to a suitable environment can still be difficult.
This creates a practical imbalance. A person may want an agent to perform a small task that saves ten minutes of coding, but establishing a safe sandbox could take half an hour, and the technical work required to define mounts, permissions, network rules and credentials may outweigh the benefit of the automation.
That problem is not necessarily evidence that agentic AI has no value. It may instead indicate that the supporting infrastructure is not mature enough, since early forms of many technologies require specialist knowledge before they become straightforward for general users. Over time, commonly needed safeguards can be incorporated into standard tools, reducing the amount that each user needs to understand.
The long-term aim would be for the containment layer to become standardised and largely invisible. A user could configure the security envelope once and then use agents without repeatedly considering the underlying mechanisms, similarly to how modern operating systems provide process isolation, virtual memory and privilege controls. Most people do not think about virtual memory or privilege rings every time they open an application, even though those features help determine what the application can do.
Agentic systems have not reached that stage yet. Achieving confidence may still require an understanding of more infrastructure than the task itself seems to justify, and users and organisations may need to understand how an agent is isolated, which directories are mounted, how network access is controlled and how credentials are supplied. That level of detail is reasonable for specialists, but it creates a barrier for wider adoption.
The question is therefore not simply whether agents can perform useful tasks. It is also whether the security surrounding them can become reliable enough to be used without extensive knowledge of systems.
The Role of Containment Infrastructure
This is where developments such as Docker Sandboxes, known by its command-line tool sbx, become significant. The most interesting aspect may not be another way to run an AI agent. Instead, it may be the attempt to turn the complexity created by agentic automation into infrastructure that has already been engineered and packaged for others to use.
The value of such an approach would lie in reducing the amount of security design that each user has to undertake independently. Rather than constructing a sandbox, setting file system boundaries and creating network policies from the beginning, users could rely on a prepared environment with safer defaults.
That does not mean that a system such as sbx removes the need for judgement. Different tasks require different levels of access, and some organisations will have more demanding security requirements than others. It does suggest, however, that containment is increasingly being treated as a prerequisite for autonomy rather than an optional extra.
The distinction matters. If security is added only after an agent has been given broad authority, the system may already have been exposed to unnecessary risk, whereas if isolation and restricted access are the starting point, expanding the agent's powers becomes an intentional decision rather than an accidental consequence of convenience.
A well-designed system should make the safer configuration the easiest one to select. An agent could begin with a disposable environment, tightly scoped access to relevant data, restricted networking and mediated credentials, and broader authority would require a deliberate change to the configuration.
This approach would also help establish clearer expectations. Users would know that an agent is not operating freely across their entire computer or organisation. It would instead be working within a defined space, with actions that can be observed and, where necessary, reversed.
Why Constant Approval Is Not the Complete Answer
One possible response to the risks of agentic automation is to require human approval for every consequential action. This can provide a strong layer of oversight, particularly where an action could affect finances, confidential information, production systems or other people.
However, constant approval can introduce a different problem. If users are asked to approve too many routine actions, they may begin accepting requests without proper consideration, and approval fatigue can turn a safety measure into a weakness, particularly when a person is presented with a long sequence of prompts that appear similar.
A more scalable arrangement would reserve approval for genuinely consequential boundary crossings. Routine actions could take place within a constrained environment, while actions involving sensitive information, external systems or irreversible changes would require confirmation.
This makes containment and approval complementary rather than competing approaches. Isolation reduces the harm that can result from ordinary mistakes, while approval provides human oversight when an agent is about to move beyond its normal limits.
The safest state should therefore be the default state. The agent should start with limited access and operate in an environment that can be discarded or restored, and if a task genuinely requires broader authority, that authority should be granted intentionally and with a clear understanding of what it enables.
Testing Agentic AI: What Happens When It Goes Wrong
The eventual test for an agentic system should not be whether it performs well when everything goes as intended. It should be whether it remains acceptable when the agent makes a serious mistake.
A useful question is this: if the agent misunderstands the task, follows a malicious instruction or executes an inappropriate command, is the surrounding system still capable of limiting the damage? If the answer is yes, the system may be suitable for a wider range of uses, whereas if the answer depends on the agent recognising every danger correctly, the arrangement remains fragile.
This test also offers a way to assess the maturity of the technology. If safe use requires detailed knowledge of microvirtual machines, mounts and network policy syntax, agentic systems may still be aimed primarily at technical specialists. For general use, the safer configuration needs to become the easy configuration, and weakening the boundaries should require deliberate action while retaining them should require no special expertise.
That is why current developments in containment are attracting attention. The central question in agentic AI is increasingly not only what an agent can do, but what happens when it does the wrong thing, and progress will depend on solving both problems.
The ideal experience would be relatively unremarkable from the user's perspective. A person would give an agent a task, the agent would work within a constrained environment and the person would review the result. The security machinery would remain largely underneath, managing access, recording actions and preventing routine errors from becoming serious incidents.
The industry is not quite at that point yet. There is still work to be done in standardising isolation, simplifying configuration and making safe delegation practical, and waiting for those safeguards to develop further may be sensible, particularly when the infrastructure required to protect a small task is more complicated than the task itself.
Whether the complexity of agentic AI eventually becomes mostly invisible, or whether using agents will always require a degree of systems thinking, remains uncertain. The answer may depend on how effectively projects such as sbx turn containment into a dependable and accessible foundation.
For now, the strongest direction appears to be one in which autonomy is introduced within clear boundaries. The safest option should be the default, while human approval should be reserved for actions with meaningful consequences. That combination may offer a more durable path towards useful agentic automation than relying on either unrestricted access or constant intervention alone.
The Open Worldwide Application Security Project: A cornerstone of digital safety in an age of evolving cybersecurity threats
24th February 2026
When Mark Curphey registered the owasp.org domain and announced the project on a security mailing list on the 9th of September 2001, there was no particular reason to expect that it would become one of the defining frameworks in the world of application security. Yet, OWASP, originally the Open Web Application Security Project, has done exactly that, growing from an informal community into a globally recognised nonprofit foundation that shapes how developers, security professionals and businesses think about the security of software. In February 2023, the board voted to update the name to the Open Worldwide Application Security Project, a change that better reflects its modern scope, which now extends beyond web applications to cover IoT, APIs and software security more broadly.
At its heart, OWASP operates on a straightforward principle: knowledge about software security should be free and openly accessible to everyone. The foundation became incorporated as a United States 501(c)(3) nonprofit charity on the 21st of April 2004, when Jeff Williams and Dave Wichers formalised the legal structure in Delaware. What began as an informal mailing list community grew into one of the most trusted independent voices in application security, underpinned by a community-driven model in which volunteers and corporate supporters alike contribute to a shared vision.
The OWASP Top 10
Of all OWASP's contributions, the OWASP Top 10 remains its most widely cited publication. First released in 2003, it is a standard awareness document representing broad consensus among security experts about the most critical risks facing web applications. The list is updated periodically, with a 2025 edition now published, following the 2021 edition.
The 2021 edition reorganised a number of longstanding categories to reflect how the threat landscape has shifted. Broken access control rose to the top position, reflecting its presence in 94 per cent of tested applications, while injection (which encompasses SQL injection and cross-site scripting, among others) fell to third place. Cryptographic failures, previously listed as sensitive data exposure, took second place. By organising risks into categories rather than exhaustive lists of individual vulnerabilities, the Top 10 provides a practical starting point for prioritising security efforts, and it is widely referenced in compliance frameworks and security policies as a baseline. It is, however, designed to be the beginning of a conversation about security rather than the final word.
Projects and Tools
Beyond the Top 10, OWASP maintains a substantial portfolio of open-source projects spanning tools, documentation and standards. Among the most widely used is OWASP ZAP (Zed Attack Proxy), a dynamic application security testing tool that helps developers and security professionals identify vulnerabilities in web applications. Originally created in 2010 by Simon Bennetts, ZAP operates as a proxy between a tester's browser and the target application, allowing it to intercept, inspect and manipulate HTTP traffic. It supports both passive scanning, which observes traffic without modifying it, and active scanning, which simulates real attacks against targets for which the tester has explicit authorisation.
The OWASP Testing Guide is another widely consulted resource, offering a comprehensive methodology for penetration testing web applications. The OWASP API Security Project addresses the distinct risks that face APIs, which have become an increasingly prominent attack surface, and OWASP also maintains a curated directory of API security tools for those working in this area. For teams managing web application firewalls, the OWASP ModSecurity Core Rule Set provides guidance on handling false positives, which is one of the more practically demanding aspects of deploying rule-based defences. OWASP SEDATED, a more specialised project, focuses on preventing sensitive data from being committed to source code repositories, addressing a problem that continues to affect development teams of all sizes. Projects are categorised by their maturity and quality, allowing users to distinguish between stable, production-ready tools and those that are still in active development, and this tiered approach helps organisations make informed decisions about which tools are appropriate for their needs.
Influence on Industry Practice
The reach of OWASP's guidance is considerable. Security teams use its materials to structure risk assessments and threat modelling exercises, while developers integrate its recommendations into code reviews and secure coding training. Auditors and regulators frequently reference OWASP standards during compliance checks, creating a shared vocabulary that helps bridge the gap between technical staff and leadership. This alignment has done much to normalise application security as a core part of the software development lifecycle, rather than a task bolted on after the fact.
OWASP's influence also extends into regulatory and standards environments. Frameworks such as PCI DSS reference the Top 10 as part of their requirements for web application security, lending it a degree of formal weight that few community-produced documents achieve. That said, OWASP is not a regulatory body and has no enforcement powers of its own.
Education and Community
Education remains a central part of OWASP's mission. The foundation runs hundreds of local chapters across the globe, providing forums for knowledge exchange at a local level, as well as global conferences such as Global AppSec that bring together practitioners from across the industry. All of OWASP's projects, tools, documentation and chapter activities are free and open to anyone with an interest in improving application security. This open model lowers barriers for those starting out in the field and fosters collaboration across academia, industry and open-source communities, creating an environment where expertise circulates freely and innovation is encouraged.
Limitations and Appropriate Use
OWASP is not without its limitations, and it is worth acknowledging these clearly. Because it is not a regulatory body, it cannot enforce compliance, and the quality of individual projects can vary considerably. The Top 10, in particular, is sometimes misread as a comprehensive checklist that, once ticked off, certifies an application as secure. It is not. It is an awareness document designed to highlight the most prevalent categories of risk, not to enumerate every possible vulnerability. Treating it as a complete audit framework rather than a starting point for more in-depth analysis is one of the most common mistakes organisations make when engaging with OWASP materials.
The OWASP Top 10 for Large Language Model Applications
As artificial intelligence has moved from research curiosity to production deployment at scale, OWASP has responded with a dedicated framework for the security risks unique to large language models. The OWASP Top 10 for Large Language Model Applications, maintained under the broader OWASP GenAI Security Project, was first published in 2023 as a community-driven effort to document vulnerabilities specific to LLM-powered applications. A 2025 edition has since been released, reflecting how quickly both the technology and the associated threat landscape have evolved.
The list shares the same philosophy as the web application Top 10, using categories to frame risk rather than enumerating every individual attack variant. Its 2025 edition identifies prompt injection as the leading concern, a class of vulnerability in which crafted inputs cause a model to behave in unintended ways, whether by ignoring instructions, leaking sensitive information or performing unauthorised actions. Other entries cover sensitive information disclosure, supply chain risks (including vulnerable or malicious components sourced from model repositories), data and model poisoning, improper output handling, excessive agency (where an LLM is granted more autonomy or permissions than its task requires) and unbounded consumption, which addresses the risk of uncontrolled resource usage leading to service disruption or unexpected cost. Two categories introduced in the 2025 edition, system prompt leakage and vector and embedding weaknesses, reflect lessons learned from real-world RAG deployments, where retrieval-augmented pipelines have introduced new attack surfaces that did not exist in earlier LLM architectures.
The LLM Top 10 is distinct from the web application Top 10 in an important respect: because the threat landscape for AI applications is evolving considerably faster than that of traditional web software, the list is updated more frequently and carries a higher degree of uncertainty about what constitutes best practice. It is best treated as a living reference rather than a settled standard, and organisations deploying LLM-powered applications would do well to monitor the GenAI Security Project's ongoing work on agentic AI security, which addresses the additional risks that arise when models are given the ability to take real-world actions autonomously.
An Ongoing Work
In an era defined by rapid technological change and an ever-expanding threat landscape, OWASP continues to occupy a distinctive and valuable position in the world of application security. Its freely available standards, practical tools and community-driven approach have made it an indispensable reference point for organisations and individuals working to build safer software. The foundation's work is a practical demonstration that security need not be a competitive advantage hoarded by a few, but a collective responsibility shared across the entire industry.
For developers, security engineers and organisations navigating the challenges of modern software development, OWASP represents both a toolkit and a philosophy: that improving the security of software is work best done together, openly and without barriers.
OWASP Top 10 for Large Language Model Applications
21st January 2024
OWASP stands for Open Web Application Security Project, and it is an online community dedicated to web application security. They are well known for their Top 10 Web Application Security Risks and late last year, they added a Top 10 for
Large Language Model (LLM) Applications.
Given that large language models made quite a splash last year, this was not before time. ChatGPT gained a lot of attention (OpenAI also has had DALL-E for generation of images for quite a while now), there are many others with Anthropic Claude and Perplexity also being mentioned more widely.
Figuring out what to do with any of these is not as easy as one might think. For someone more used to working with computer code, using natural language requests is quite a shift when you no longer have documentation that tells what can and what cannot be done. It is little wonder that prompt engineering has emerged as a way to deal with this.
Others have been plugging in LLM capability into chatbots and other applications, so security concerns have come to light, so far, I have not heard anything about a major security incident, but some are thinking already about how to deal with AI-suggested code that others already are using more and more.
Given all that, here is OWASP's summary of their Top 10 for LLM Applications. This is a subject that is sure to draw more and more interest with the increasing presence of artificial intelligence in our everyday working and no-working lives.
LLM01: Prompt Injection
This manipulates an LLM through crafty inputs, causing unintended actions by the LLM. Direct injections overwrite system prompts, while indirect ones manipulate inputs from external sources.
LLM02: Insecure Output Handling
This vulnerability occurs when an LLM output is accepted without scrutiny, exposing backend systems. Misuse may lead to severe consequences such as Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Server-Side Request Forgery (SSRF), privilege escalation, or remote code execution.
LLM03: Training Data Poisoning
This occurs when LLM training data are tampered, introducing vulnerabilities or biases that compromise security, effectiveness, or ethical behaviour. Sources include Common Crawl, WebText, OpenWebText and books.
LLM04: Model Denial of Service
Attackers cause resource-heavy operations on LLMs, leading to service degradation or high costs. The vulnerability is magnified due to the resource-intensive nature of LLMs and the unpredictability of user inputs.
LLM05: Supply Chain Vulnerabilities
LLM application lifecycle can be compromised by vulnerable components or services, leading to security attacks. Using third-party datasets, pre-trained models, and plugins can add vulnerabilities.
LLM06: Sensitive Information Disclosure
LLMs may inadvertently reveal confidential data in its responses, leading to unauthorized data access, privacy violations, and security breaches. It’s crucial to implement data sanitization and strict user policies to mitigate this.
LLM07: Insecure Plugin Design
LLM plugins can have insecure inputs and insufficient access control. This lack of application control makes them easier to exploit and can result in consequences such as remote code execution.
LLM08: Excessive Agency
LLM-based systems may undertake actions leading to unintended consequences. The issue arises from excessive functionality, permissions, or autonomy granted to the LLM-based systems.
LLM09: Overreliance
Systems or people overly depending on LLMs without oversight may face misinformation, miscommunication, legal issues, and security vulnerabilities due to incorrect or inappropriate content generated by LLMs.
LLM10: Model Theft
This involves unauthorized access, copying, or exfiltration of proprietary LLM models. The impact includes economic losses, compromised competitive advantage, and potential access to sensitive information.