Notifications
Clear all
Topic starter
18/08/2026 2:41 pm
TL;DR: Ten agent-specific risks in the OWASP Top 10 for Agentic Applications 2026 map to real 2025 incidents, including zero-click data exfiltration, supply-chain compromise, and an autonomous agent deleting production data, according to Cycode. The central finding is that agentic risk is a blast-radius problem, because credentials, tools, memory, and delegated authority compound damage across multi-step actions.
NHIMG editorial — based on content published by Cycode: OWASP Top 10 for Agentic Applications
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: What is the difference between least privilege and access review?
A: Least privilege is the design principle that limits access to what is required, while access review is the governance activity that checks whether current access still matches that principle.
Q: What breaks when AI agents are connected through personal accounts or shared credentials?
A: Shared or personal credentials break accountability, lifecycle control, and revocation.
Practitioner guidance
- Define a unique identity for every agent Map each agent to a distinct identity, scope its permissions to the minimum task set, and revoke access as soon as the workflow ends.
- Bound each agent’s blast radius Document which tools, APIs, data sets, and MCP servers each agent can reach, then remove anything not required for the current use case.
- Inspect agent activity at runtime Log prompts, tool calls, delegation events, and memory writes so behaviour can be reviewed after an incident.
What's in the full article
Cycode's full guide covers the operational detail this post intentionally leaves for the source:
- Category-by-category mapping of ASI01 through ASI10 to real incidents and primary mitigations
- ADLC control playbook details for IDE, CLI, and pull-request enforcement
- Examples of how SAST, SCA, and runtime monitoring divide responsibility across agentic workflows
- Vendor-specific implementation guidance for the Cycode platform and workflow integration
👉 Read Cycode's guide to the OWASP Top 10 for Agentic Applications 2026 →
OWASP Agentic Applications Top 10: are your controls keeping up?
Explore further
18/08/2026 3:25 pm
Agentic AI creates an identity problem before it creates an automation problem. Once a software system can plan, call tools, and act on its own, the central control question becomes who or what is authorised to do the work. That pushes the issue squarely into IAM and PAM territory, because scoped privilege, revocation, and attribution now need to apply to non-human actors as well. Practitioners should treat agent identity as a first-order governance domain, not an implementation detail.
A question worth separating out:
Q: Who is accountable when an authorised AI agent causes a breach?
A: Accountability usually sits with the organisation that assigned the access, defined the workflow, and failed to instrument runtime oversight. The hard part is proving whether the failure was an entitlement decision, a workflow design issue, or a missing behavioural control, which is why governance ownership must span IAM, security engineering, and application teams.
👉 Read our full editorial: OWASP Top 10 for agentic applications reframes AI agent risk
