Topic starter
25/10/2026 11:08 am
TL;DR: 10 risks show agentic applications need separate controls for authority, tools, and provenance, based on Jozu’s case work. Runtime behaviour can still outrun prompt checks, so verification, enforcement, and forensic proof have to be managed as one lifecycle.
Editorial analysis by NHI Mgmt Group, based on content published by Jozu: “The OWASP Top 10 for Agentic Applications 2026: What It Means for Teams Running Agents in Production”.
Key questions
Q: Why do agentic applications need more than prompt filtering?
A: Prompt filtering only addresses one attack path, but agentic risk also includes supply-chain tampering, over-privileged tools, memory poisoning, and rogue runtime behaviour.
Q: How should teams handle approvals for high-risk agent actions?
A: Treat approval as part of the authorisation decision for one specific action, not as a reusable privilege.
Q: What breaks when AI agents inherit loose human authority?
A: Loose human authority turns agent security into an amplification problem.
Practitioner guidance
- Map each agent to a named authority boundary Document which tools, data sets, execution environments, and delegated identities each agent can reach, then remove anything that is not required for the task.
- Separate tool approval from model permission Treat tool invocation as its own control point, with per-tool and per-action authorization instead of broad access inherited from the host application.
- Verify every agentic artifact before it reaches runtime Require signature, provenance, and security checks for models, MCP servers, agent definitions, and skills before they are allowed into production.
Bottom line: Agentic applications create a governance problem that starts with delegated authority and ends with blast-radius control, not with prompt quality alone.
Glossary terms: Agentic Application, Goal hijack, Tool Misuse, Lifecycle Containment
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:18 pm
Agentic applications invalidate the assumption that authorization and behaviour are the same thing. The article shows that traditional IAM can prove an identity is entitled to act, but not that the actor will remain aligned with the approved task once runtime context changes. That is a structural governance break, not just a tooling gap. The implication is that agent identity must be governed as an active execution model, not a static access record.
A few things that frame the scale:
- Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
A question worth separating out:
Q: What is the difference between platform control and runtime control for AI agents?
A: Platform control decides where the AI lifecycle runs and how infrastructure is operated. Runtime control decides what an agent may do after it starts, including which tools, data and destinations it can reach. Both are necessary, but they answer different governance questions and fail in different ways.
👉 Read our full editorial: OWASP’s agentic top 10 reframes AI agents as active attack surfaces
This post was modified 7 days ago by NHI Mgmt Group