Implement AI agents securely by scoping tools, isolating identity, and keeping authorization outside the model. Permissions decide the damage, not detection.
To implement AI agents securely, scope each agent’s tools to its task, run it under its own identity, keep authorization outside the model, and require human approval for high-impact actions. Prompt injection cannot be reliably blocked. Therefore permissions, not detection, decide how much damage an attacker does.
A chatbot answers. An agent acts. That single difference reshapes how you implement it, and every control below follows from it.
An agent plans a task, calls tools, holds memory between steps, and runs without a human approving each action. It reads a ticket, queries a database, sends an email, and updates a record. Consequently its mistakes are not wrong answers. They are transactions.
OWASP drew the line cleanly across its two 2026 standards. The Top 10 for LLM Applications governs what a model says. The Top 10 for Agentic Applications governs what a system does. Crucially, the second extends the first rather than replacing it. Autonomy turns a model-layer weakness into a live one.
The practical test is simple. Ask what happens if the system is wrong at 3am with nobody watching. For a chatbot, someone reads a bad answer. For an agent, money moves.
Most guidance on implementing AI agents cites no standard at all. Two now exist, both dated 2026, and both are free to work from.
| Standard | Published | Covers |
|---|---|---|
| OWASP Top 10 for LLM Applications 2026 | 3 August 2026 | Model-layer risk: prompt injection, sensitive information disclosure, excessive agency, supply chain, poisoning |
| OWASP Top 10 for Agentic Applications 2026 | 9 December 2025 | System-layer risk: goal hijacking, tool misuse, memory and context poisoning, entries ASI01 to ASI10 |
The agentic list came from the OWASP Agentic Security Initiative, with more than 100 contributors and a review board drawn from NIST, Cisco, Microsoft, and AWS. Meanwhile the LLM list arrived alongside a new Agent Control Standard covering runtime enforcement.
Both map to NIST, MITRE ATLAS, and CWE. As a result you can trace an agent control back to a framework your auditor already accepts, which is usually the blocker for getting agent work funded.
Discover how Threatcop protects your workforce from modern cyber threats.
Excessive agency sat at sixth place in the 2025 LLM Top 10. In the 2026 edition it moved to third. Supply chain and poisoning risks dropped below it.
The reason is adoption rather than any new attack. Agents now reach real tools, real APIs, and real work systems. More reach means more impact when the system is manipulated, drifts outside its scope, or simply decides wrongly.
OWASP splits excessive agency into three root causes, and the split is worth memorising because it tells you where to look:
Notice that none of these is a model problem. Each one is a decision somebody made during rollout.
Prompt injection has held the top OWASP spot for three straight editions. It persists because models read instructions and data through the same channel. The model cannot tell a document’s contents from a command, so hostile text inside a web page, a PDF, or an email can redirect it.
OWASP’s own work on agentic security found prompt injection maps to six of the ten agentic risk categories. In short, it is the most common delivery mechanism.
Here is the part that changes how you spend money. The resulting damage is almost always mediated by whatever permissions the injected agent happens to hold. Injection gets the attacker in. Permissions decide what they get.
Accordingly, chasing perfect injection defence is a losing investment. Detection classifiers help and they will never be complete. Scoping the agent’s authority is bounded, testable work you can finish. Governance questions of this kind are explored in AI automation and the governance layer.
OWASP’s advised fixes are specific, which is unusual for AI guidance. Build them in during rollout, because retrofitting permissions onto a live agent means breaking workflows people already depend on. Work through them in this order, because each one shrinks what the next has to cover.
Notably, none of these controls tries to make the model safer. Each one limits what happens when the model is already wrong. That is the whole design principle, and it is why agent security looks like privilege management far more than content filtering. Data-protection framing for the same problem appears in the role of PSM in data privacy.
| Control | What it means |
|---|---|
| Scope tools to the task | The agent gets exactly the functions its job needs, and nothing adjacent |
| Run in the user’s security context | Never a generic high-privileged service identity shared across agents |
| Authorize outside the model | External systems make access decisions; the LLM is never the gatekeeper |
| Require approval for high-impact actions | Payments, deletions, external sends, and permission changes stop for a human |
| Give each agent its own identity | Distinct credentials, so logs attribute actions and revocation is surgical |
| Separate prompts from data | System prompts and settings never sit in a store the agent can write to |
| Log every tool call | Inputs, outputs, and the identity used, retained for review |
The sixth row deserves weight. When system prompts live alongside the data an agent queries, a single injection or injection-adjacent flaw lets an attacker rewrite the guardrails themselves. Guardrails stored where the agent can reach them are not guardrails.
Human approval is the control most agent designs lean on hardest. It is also the one most likely to fail quietly.
The failure mode is familiar. MFA push fatigue works because people approve prompts they no longer read. Agent approvals fail the same way. An analyst clearing forty agent actions an hour is not reviewing them. They are clicking.
So the design question is not whether to require approval. It is how few approvals you can ask for.
Three rules help. Set thresholds so routine actions run alone and only consequential ones stop. Show the approver what changes, not that something changed. And measure approval latency, because approvals granted in under two seconds were not read. Human-layer failures of this shape are covered in how to reduce human error in cybersecurity.
An agent’s permissions come from somewhere. Usually a person granted them, often in a hurry, frequently by accepting a default scope during setup.
That makes agent security a workforce habit before it is an architecture problem. The employee who connects an agent to a mailbox, approves an OAuth scope, or pastes an API key into a config file is making a security decision. Few of them know it.
Three habits matter most. People should read the scope before granting it, rather than accepting the defaults an integration proposes. They should treat a standing connection as permanent until revoked, because it is. And they should report an agent behaving oddly, instead of assuming it is a bug someone else has noticed.
Threatcop’s TLMS delivers this as role-specific content, so the developers wiring agents and the operations staff approving their actions get different material rather than one shared AI module. Building that layer is the subject of human risk as the biggest attack surface.
Run this before an AI agent touches production, as the last gate of any secure rollout. Each item maps to an OWASP control above. Above all, treat it as a gate rather than a form.
Step 6 is the one teams skip. Test with the input an attacker would actually send, not with the prompts your developers thought of.
Alert counts tell you about the monitoring. These six tell you about the AI agent itself. Similarly, they measure decisions people made rather than traffic the system saw.
Start with the first one. Agents often hold tools nobody has called since launch. Removing them costs nothing.
Pick one agent running in your systems today. List the tools it can call. Then list the ones it has actually called this month.
That gap is your excess functions. You can close it this week without a new product, a new vendor, or a new budget line. Do that before you buy anything designed to stop prompt injection.
Then look at who granted those permissions and whether they understood the scope. Train the people wiring agents together on what a standing connection actually means, because the build is only as tight as the last default somebody accepted.
Scope each agent’s tools to its task and nothing adjacent. Run it under its own identity rather than a shared high-privilege account. Keep authorization in external systems, never delegated to the model. Require human approval for high-impact actions such as payments and deletions. Store prompts and settings outside anything the agent can write to. Finally, log every tool call with the identity used.
Set the permissions during the build rather than after it. Retrofitting scope onto a live agent means breaking workflows teams already rely on, which is what makes security feel like a blocker. Start each agent with the narrowest tool set that completes its job, then widen deliberately when a gap appears. Consequently the default is safe and every expansion is a decision somebody records.
Excessive agency is LLM03 in the OWASP Top 10 for LLM Applications 2026, up from sixth place in 2025. OWASP names three root causes: excess functions, where an agent reaches tools beyond its task; excessive permissions, where those tools run with more privilege than needed; and excessive autonomy, where high-impact actions proceed without human approval.
Not reliably. Models process instructions and data through the same channel, so they cannot tell apart a command from content. Detection classifiers and input filtering reduce the rate without closing the gap. Because damage depends on the permissions the agent holds, limiting authority and requiring approval for high-impact actions gives a better return than pursuing complete injection defence.
Yes. OWASP recommends running agent extensions in the user’s security context rather than under generic high-privileged identities. Distinct identities make logs attributable, let you revoke one agent without disrupting others, and stop a single compromised credential from granting access across every automated workflow.
The OWASP Top 10 for Agentic Applications is a ranked list of the ten most critical risks in AI systems that plan, use tools, retain memory, and act autonomously. The OWASP Agentic Security Initiative published it on 9 December 2025. Entries run ASI01 to ASI10 and cover goal hijacking, tool misuse, and memory poisoning. It extends the LLM Top 10 rather than replacing it.
Sushant Kumar is the AVP – Technology at Threatcop, bringing over a decade of experience in technology leadership and product development. He has worked across technology-driven organizations, including Paytm, and focuses on building scalable solutions that address evolving business and cybersecurity challenges. His areas of interest include cybersecurity technology, AI-driven security, product innovation, and enterprise technology. He is passionate about using technology to solve complex security challenges.
AI now runs inside live malware. See where AI defence genuinely helps, where egress policy beats it, and a...
AI phishing prevention starts with a correction: AI authorship cannot be measured reliably. See which recognition signals died, which...
Continuous compliance readiness means evidence accumulates as controls operate. See what assessors ask for, the parameter trap, and a...