OWASP has published its Top 10 for Agentic Applications — a peer-reviewed catalogue of the ways autonomous AI systems fail in production. We have read it end to end and mapped it against what organisations are actually deploying.
This piece is what we think it means for you.
First, why it matters now. Most organisations are closer to running agents than their security model assumes. Not a chatbot answering questions — something that holds credentials, calls tools, remembers across sessions, and takes actions without a human approving each one. That is a different security problem, and the controls that made a chatbot safe do not transfer. A chatbot that is manipulated says something wrong. An agent that is manipulated does something wrong, with your permissions, against your systems.
Second, the finding that should shape your roadmap. Read the ten entries together and only two or three are genuinely about the model. The rest are identity, privilege, supply chain, network and operations problems — disciplines your organisation already has, staffed by people already on your payroll. That is good news, and it should determine where you start.
A list is not a plan, so what follows is the ten grouped by the problem they represent, with the controls to build against each and the order we would build them in.
The ten, briefly
| ASI01 | Agent Goal Hijack |
| ASI02 | Tool Misuse and Exploitation |
| ASI03 | Identity and Privilege Abuse |
| ASI04 | Agentic Supply Chain Vulnerabilities |
| ASI05 | Unexpected Code Execution (RCE) |
| ASI06 | Memory & Context Poisoning |
| ASI07 | Insecure Inter-Agent Communication |
| ASI08 | Cascading Failures |
| ASI09 | Human-Agent Trust Exploitation |
| ASI10 | Rogue Agents |
Ten entries, and the shape of the problem is already visible: goal hijacking and memory poisoning are model-adjacent, but identity abuse, supply chain, code execution, inter-agent communication, cascading failures and rogue agents are all things you have controls for in other contexts.
Start with identity, because it caps everything else
Addresses ASI03 and ASI10.
The most consequential decision you will make is whether an agent has its own identity or borrows a human's. Borrowing is the default, because it is easiest, and it is the choice that makes every other risk worse: you cannot tell agent actions from human ones in the logs, you cannot scope permissions to the task, and you cannot revoke the agent without locking out a person.
What to implement:
- A distinct identity per agent, never a shared service account and never a human's credentials.
- Short-lived, task-scoped credentials — scoped tokens or mTLS certificates issued per task, not long-lived keys sitting in configuration.
- Permission boundaries that cap what the identity can reach even if something upstream grants more. This is what stops privilege inheritance quietly accumulating.
Do this first. It bounds the damage from most of the other nine, and it is the one control that is genuinely harder to retrofit than to build in.
Then constrain what tools can do
Addresses ASI02 and ASI05.
An agent's tools are its hands. Most incidents are not exotic model failures; they are an agent using a legitimate tool in a way nobody anticipated, at a scale nobody rate-limited.
- Per-tool least-privilege profiles — define scopes, maximum call rates, and egress allowlists for each tool rather than granting a general capability.
- No direct path from agent to production. Agent-generated code and actions go through the same pre-production checks as human ones. If your agent can deploy, you have not built an agent, you have built an unreviewed committer.
- Sandbox execution. Anything the agent generates and runs executes in a contained environment, not on a host with credentials.
The instinct is to give an agent broad tooling so it is useful. Resist it in the same way you resist giving a service account broad IAM rights — usefulness is not the only variable.
Treat every input as hostile, including your own documents
Addresses ASI01 and ASI06.
Goal hijacking is the risk people picture, and the mitigation is well understood in principle: route all natural-language input through injection safeguards before it can influence planning or tool calls.
What organisations underestimate is which inputs count. Not just what a user types — retrieved documents, tool outputs, content from a shared drive, a PDF someone uploaded. If it reaches the context window, it can carry instructions.
Memory makes this durable. An agent that writes to persistent memory can be poisoned once and act on it for weeks. So:
- Validate on write, not just on read — scan anything entering memory before it is committed.
- Segment memory by user session and domain, so one poisoned context cannot leak across tenants or teams.
- Require human approval for high-impact or goal-changing actions. This is the backstop when everything above fails, and it is the control most worth arguing for.
Know what your agent is made of
Addresses ASI04.
Agentic stacks assemble quickly from prompts, tool definitions, framework plugins and community packages — and the supply chain around them is younger and less curated than the one you are used to.
- Sign and attest manifests, prompts and tool definitions. A prompt is executable configuration; treat it like code.
- Maintain an inventory of AI components — SBOMs, and increasingly AIBOMs.
- Allowlist and pin dependencies, and scan for typosquats in the ecosystems these frameworks pull from.
If you already run software composition analysis, this is an extension of a capability you have, not a new programme.
Multi-agent systems need network discipline
Addresses ASI07 and ASI08.
The moment agents talk to each other, you have a distributed system with all the failure modes that implies — plus a new one, where a manipulated message propagates through a chain and every downstream agent treats it as trusted.
- Mutual authentication and end-to-end encryption between agents, with per-agent credentials.
- Sign messages and validate them for hidden instructions, not just for integrity.
- Trust boundaries and sandboxing so a failure is contained rather than cascading.
- Design for failure. Assume a component will be unavailable or wrong, and make the system degrade rather than propagate.
If you are running a single agent today, read this section anyway. Multi-agent is where most roadmaps are heading, and the architecture decisions you make now determine whether that transition is a configuration change or a rewrite.
Do not let the interface do the persuading
Addresses ASI09.
A fluent, confident agent earns trust it has not necessarily justified. Users approve things they would have scrutinised in a form, because the interaction feels like a conversation with a competent colleague.
- Explicit confirmation before sensitive data access or risky actions — a real decision point, not a dialog people click through.
- Immutable logs of queries and actions, so an after-the-fact question has an answer.
- Behavioural monitoring for sensitive data appearing in conversations and for risky actions accumulating over time.
Where to actually start
If you are deploying your first agent, in this order:
- Give it its own identity with short-lived, task-scoped credentials. Nothing else works properly without this.
- Write down every tool it can call and the scope, rate limit and egress allowlist for each. If that list surprises you, stop and fix it before launch.
- Put a human approval step in front of high-impact actions. You can relax this later with evidence; you cannot add it credibly after an incident.
- Turn on immutable logging of actions and tool calls before the first real user.
- Inventory what the agent is built from — prompts, tools, framework dependencies — and sign what you control.
The first four are achievable in a normal delivery cycle and remove most of the practical risk. None of them requires a specialist AI security product. They require treating an agent as what it is: a non-human identity with credentials, network access and the ability to act — a category your organisation has governed for years, now moving faster and explaining itself more persuasively.
Risk names and mitigation themes are drawn from the OWASP Top 10 for Agentic Applications (2026), published by the OWASP Gen AI Security Project. The grouping, the sequencing and the judgements about what to implement first are CyberCtrl's.
Running agents, or about to be? We help teams put these controls in before the first production deployment rather than after the first incident. Get in touch.
Want help putting this into practice?
We work alongside your team to design, build, and operate the controls described above.