TOPIC: SECURITY ENGINEERING
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.
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.