Most guidance on securing an agent involves embedding instructions within a system prompt. This approach treats security as a set of behavioural guidelines, essentially asking the agent not to perform certain actions. This is fundamentally flawed because an instruction is a request, not a technical boundary. A request can be overruled, ignored, or circumvented by sophisticated input.
A prompt is an instruction, not a boundary. This means that relying on the agent's adherence to rules leaves the design vulnerable to adversarial input. The security model must therefore shift from managing instructions to enforcing verifiable technical limitations on what the agent can physically reach or execute.
Why the prompt is not a boundary
The current edition of the OWASP Top 10 for Large Language Model Applications, published on 4 August 2026, highlights this fundamental issue. Prompt Injection remains LLM01, the first entry on the list. Simultaneously, Excessive Agency has climbed significantly, reaching LLM03 in the 2026 edition, up from sixth place in the 2025 edition. This combination signals a critical shift in risk: the input cannot be trusted, and the permissions granted to the agent are becoming the primary vector of danger.
This risk is compounded by the nature of data itself. Text embedded within a record - whether in a document, an e-mail, a ticket description, or a web page - is data, never authorisation. An agent that treats content as instruction can be steered by anyone who can write into any system it reads. The technical separation between data and command must be enforced at the architectural level, rather than relying on the agent to correctly interpret intent.
Three things that do enforce it
Enforced isolation requires addressing three distinct, verifiable technical layers. These are credentials, access scope, and runtime.
Credentials
The principle here is that the agent must possess its own dedicated set of credentials, and these credentials must never be shared. If the agent does not hold the necessary token or key, it cannot authenticate with a system, regardless of what it is told to do. One architectural pattern is a gateway that holds the credential and injects the required identity per call. This ensures the agent never possesses the raw token itself, limiting its ability to misuse or exfiltrate authentication material.
To verify this in your own system, attempt to force the agent to authenticate using credentials it was not explicitly designed to use. If the system fails to authenticate or rejects the identity, the credential boundary is holding.
Access scope
Access scope dictates the precise boundaries of permission, ensuring that permissions are granted deliberately and narrowly, rather than broadly. It is critical to recognise that a technical ability to write to a system is not the same as authorisation to write. Permissions granted across the board - to a technical group, or by a feature flag received by everyone - constitute configuration debt, not a mandate.
Verification involves testing the agent against a resource it is technically able to see but should not be able to modify. If the system correctly refuses the action, the narrow scope is enforced.
Runtime
Runtime defines the environment in which the process executes and what it can physically reach from that point. An agent is only as contained as the environment it runs in. This layer ensures that even if the agent is successfully tricked into executing a command, the operating system or container environment limits the scope of that execution.
To verify this, attempt to make the agent interact with a resource or service that is physically outside its designated runtime environment. The system must fail the request due to environmental containment, not due to an internal rule or prompt instruction.
Containment before capability
Containment must be decided before the agent is built. It cannot be added afterwards, because every capability granted earlier has already been designed around. If you build functionality first and then try to wrap it in security layers, you are retrofitting and the resulting architecture will contain inherent vulnerabilities.
Furthermore, the system must be designed such that revocation is achieved by one change in one place, closing every door at once. This single point of control ensures that security policy changes are immediate and comprehensive, rather than requiring manual updates across multiple, disparate components.
What we deliberately do not claim
This design approach is an engineering arrangement, not a compliance certificate. We are not claiming conformance with any particular standard or audit requirement. The focus remains purely on the technical principles of isolation and verifiable refusal.
Crucially, none of these three layers - credentials, access scope, or runtime - answers whether the agent should exist at all. The architectural decision to deploy an agent remains a business and risk assessment decision, separate from the technical controls. For further consideration on this point, read the agent we decided not to build.
Questions and answers
How do you stop an AI agent from being tricked by prompt injection?
You cannot stop it solely through prompts. The defence must be architectural. This requires enforcing technical boundaries using credentials, access scope, and runtime isolation. These layers ensure that even if the agent is tricked into receiving a malicious instruction, the underlying system will refuse the action.
Is a system prompt enough to secure an agent?
No. A system prompt is merely a set of instructions, which are advisory and can be bypassed. Security must be implemented through verifiable, technical controls. The boundaries must be physical and computational, not linguistic.
What permissions should an AI agent have?
The agent should only have permissions that are deliberately and narrowly granted for specific tasks. Never grant permissions across the board. All technical abilities must be separated from actual authorisation.
What happens if an agent is compromised?
The goal of the design is to ensure that compromise remains localised. By enforcing strict credentials, narrow access scope, and contained runtime, the damage an attacker can inflict is limited to the smallest possible operational area.
The core design question that must guide any agent deployment is not: what will it be able to do? Instead, the question must be: what technical mechanism enforces its isolation if someone turns it against us? Focusing on the boundaries, rather than the capabilities, is what makes the arrangement hold.