Eleven publications from seven bodies bear on the risk of AI agents. They are not competing lists. This page states what each one is for, and crosswalks all of them into five categories with the business impact of each.
Maintained by NexNith. Last reviewed 15 August 2026. Free to use, cite, and circulate.
A practitioner who meets three of these frameworks without a map will reasonably assume they are alternatives, and will then spend time deciding which one to adopt. They sit at different altitudes and answer different questions. Adopting one does not exclude another, and none of them is sufficient alone.
One finding is worth stating at the top. Nothing published to date by ISACA, the Institute of Internal Auditors, ISO, or the European Union names a single agentic risk category. The professional bodies whose certifications this audience holds have not yet written this down, which is why a crosswalk has to be assembled rather than looked up.
OWASP describes what goes wrong. MITRE describes how an attacker makes it go wrong. The Cloud Security Alliance describes how to find it before it happens. NIST and ISO describe how to run the program that manages it. The Institute of Internal Auditors describes how to give assurance over it. The EU AI Act describes what the law requires.
| Body and publication | Date | What it is for | Granularity |
|---|---|---|---|
| OWASP GenAI Security Project Top 10 for Agentic Applications | December 2025 | The consensus list of what goes wrong in agentic systems. Security led, agent specific, freely licensed under Creative Commons, and short enough to teach. The basis of the five categories below. | ASI01–ASI10 |
| OWASP GenAI Security Project Agentic AI: Threats and Mitigations | February 2025 | The longer engineering taxonomy the Top 10 was distilled from, with mitigations stated against each threat. Use it when a category needs to be decomposed into testable conditions. | T1–T15 |
| OWASP GenAI Security Project Top 10 for LLM Applications | November 2024 | Risks of the model layer underneath every agent. Still applies in full. LLM06, Excessive Agency, is the direct ancestor of the agentic list. | LLM01–LLM10 |
| NIST AI 600-1, Generative AI Profile | July 2024 | Societal and organizational harms from generative AI, including confabulation, information integrity, human and AI configuration, and value chain integration. It does not address agent architecture. | 12 risks |
| NIST AI Agent Standards Initiative, control overlays for securing AI systems, and the agent identity and authorization project | From February 2026, in progress | Controls rather than risks. Single agent and multi agent overlays on the federal control catalogue are in development, and the agent identity work covers identification, authorization, delegation, and logging. Not yet published. | controls |
| MITRE ATLAS | Ongoing; agentic techniques added during 2026 | Adversarial tradecraft against AI systems, in the same form as the ATT&CK framework. Agentic additions cover agent tool credential harvesting, agent tool data poisoning, data destruction through agent tool invocation, and luring an AI browser into unintended actions. | tactics, techniques |
| Cloud Security Alliance MAESTRO | February 2025 | A seven layer threat modelling method for agentic systems, running from the foundation model through data operations, agent frameworks, infrastructure, evaluation and observability, security and compliance, and the agent ecosystem, with cross layer threats for supply chain, lateral movement, and privilege escalation. | 7 layers |
| Cloud Security Alliance Draft agentic profile for the NIST AI Risk Management Framework | April 2026 | Governance extensions to the AI RMF, including autonomy tier classification, delegation accountability, agent inventory and lifecycle, tool risk classification, action and consequence analysis, behavioural telemetry, delegation chain monitoring, and agent decommissioning. | 12 controls |
| ISO/IEC 23894, guidance on AI risk management, and 42001, AI management system | 2023 | Process and management system rather than taxonomy. How to run risk management for AI, and how to build a certifiable management system around it. Neither document names an agentic risk. | process |
| The Institute of Internal Auditors Artificial Intelligence Auditing Framework | 2024 | Assurance structure on the Three Lines Model, covering governance, management, and internal audit, with checklists and a glossary. It predates agents and names no agentic risk. | framework |
| European Union AI Act | 2024 | Legal obligation by risk tier to people, being unacceptable, high, limited, and minimal, plus duties on general purpose models. Article 14, on human oversight, is the provision agentic deployments most often fail in substance rather than in form. | legal tiers |
| Google Secure AI Framework, agent focus | 2025 | Two agent risks only, being sensitive data disclosure and rogue actions, with five principles covering least privilege, layered defence, auditability, user approval, and data minimization. Concise, and a vendor framework rather than a standard. | 2 risks |
Five categories are used for teaching because ten items are more than a foundations audience holds. All ten OWASP agentic items are covered, each appearing exactly once, and the other taxonomies map onto the same five.
| Category | OWASP agentic | Absorbs, from the other published taxonomies |
|---|---|---|
| 1. The agent pursues the wrong goal | ASI01, ASI06 | OWASP T1 Memory Poisoning, T6 Intent Breaking and Goal Manipulation · LLM01 Prompt Injection, LLM04 Data and Model Poisoning · MITRE ATLAS agent tool data poisoning and AI agent clickbait · MAESTRO layers 1 and 2 · NIST information integrity and confabulation · SAIF rogue actions |
| 2. The agent does more than it should | ASI02, ASI03, ASI05 | OWASP T2 Tool Misuse, T3 Privilege Compromise, T11 Unexpected Code Execution · LLM06 Excessive Agency · MITRE ATLAS agent tool credential harvesting and data destruction through tool invocation · MAESTRO layers 3 and 4 · CSA agent tool risk classification and action and consequence analysis |
| 3. The agent trusts something it should not | ASI04, ASI07 | OWASP T9 Identity Spoofing and Impersonation, T12 Agent Communication Poisoning · LLM03 Supply Chain · MAESTRO cross layer supply chain · NIST value chain and component integration · NIST agent identity and authorization work · ISO/IEC 42001 third party controls |
| 4. Failures spread, and failures hide | ASI08, ASI10 | OWASP T5 Cascading Hallucination, T8 Repudiation and Untraceability, T13 Rogue Agents in Multi-Agent Systems · LLM10 Unbounded Consumption · MAESTRO layer 5 · CSA behavioural telemetry, delegation chain monitoring, agentic incident response, and agent decommissioning |
| 5. People trust the agent wrongly | ASI09 | OWASP T7 Misaligned and Deceptive Behaviors, T10 Overwhelming Human-in-the-Loop, T14 Human Attacks on Multi-Agent Systems, T15 Human Manipulation · LLM09 Misinformation · NIST human and AI configuration · EU AI Act Article 14 · IIA transparency and accountability |
Nine of the twelve NIST generative AI risks fall outside these five categories, because they concern content harms rather than agent architecture. They include chemical, biological, radiological and nuclear information, dangerous or hateful content, environmental impact, harmful bias, intellectual property, and obscene or abusive content.
Those risks are real and they are governed elsewhere in an AI program. They are not properties of an agent’s architecture, and a control designed for one will not address the other.
Business impact is stated first in each category. Governance, risk, and audit professionals are accountable for the consequence before they are interested in the mechanism, and a technical risk that cannot be expressed as a business consequence does not survive a committee.
Work is completed to an objective nobody in the organization authorized. Funds are misallocated through credits, refunds, or payments that were never approved, and confidential information leaves the organization inside an action that looks entirely ordinary.
Because the instruction sits in content the organization owns, every log records a normal transaction. The loss is therefore usually reported by a customer or a counterparty rather than found by a control, and the organization cannot then say when the behaviour started. A contained loss becomes an open ended remediation and a disclosure problem.
An agent cannot distinguish an instruction from content. Retrieved text and operator instructions arrive in the same package at the same level, so anything the agent reads can carry an instruction. Where the agent writes to stored state, one poisoned entry changes behaviour on every subsequent run and no session boundary clears it.
An insurer’s claims assistant consults its procedure library before answering. An internal editor updates one procedure page and adds a line instructing the assistant to copy every claim summary to an external address for quality review. The assistant complies for eleven weeks. Nothing in the logs looks unusual, because sending a summary is a permitted action.
Direct financial loss at machine volume. A limit that a person would breach once, an agent breaches on every eligible transaction until somebody notices, so the exposure scales with throughput rather than with intent.
Where the tool reaches regulated data, the result is a reportable privacy breach and a control failure that has to be disclosed to the auditor and the regulator. Remediation ordinarily costs more than the loss itself, because the whole population of affected transactions has to be identified, reversed, and explained.
A tool runs under an identity, and that identity holds whatever permission it was granted. A constraint written into the instructions is a request to the model, not a control. Service identities are granted broadly during development because narrowing them is slow, and the narrowing is rarely revisited before launch. Where the tool set includes anything that executes code or issues free-form queries, the reachable surface is far larger than the tool description suggests.
A procurement assistant is instructed that it may approve invoices up to five thousand dollars. The service identity behind the approval tool holds no amount condition at all. Over one quarter the assistant approves nineteen invoices above the stated limit, the largest at forty-one thousand dollars, every one of them within its granted permission.
A supplier the organization never contracted with sits inside a customer-facing process. Third-party assessments, vendor attestations, and the outsourcing register filed with the regulator all describe a system that is not the one running.
When something fails, liability is contested and contractual recourse is thin, and the organization cannot answer the basic supervisory question of who processed the data and under what terms. For regulated firms this becomes a concentration and outsourcing finding before it becomes a security one.
Agents acquire capability by connecting to components: tool servers, connectors, frameworks, model providers, and other agents. Connectors are installed the way software libraries are installed, from public registries, by a developer, during a sprint. A message arriving from another agent is usually accepted without authentication, so a permission granted at one end of a chain is exercised at the other.
An onboarding assistant calls a directory connector installed from a public registry to create staff accounts. Nine months later the connector’s maintainer transfers the package to another party. The organization’s vendor register lists the assistant’s model provider and its own human resources system, and names neither the connector nor the party now maintaining it.
The cost of an incident is set by how long it ran and how many customers it touched, and both are unbounded when nobody can establish them. Remediation becomes a full population review instead of a targeted correction, at a cost that scales with the portfolio rather than with the error.
Where notification duties apply, the organization must either over-notify or miss a deadline, and both are expensive. The lasting damage is to the assurance function itself, because an opinion cannot be given over a process that leaves no attributable record, and every downstream reliance fails with it.
Agents call other agents and write to shared state, so one wrong output becomes the next agent’s input. Speed removes the natural circuit breaker, because an agent repeats a mistake at full rate until something outside it intervenes. Logging is usually built for debugging rather than for accountability, capturing prompts and responses instead of what changed, for whom, and under whose authority.
A logistics assistant reprices shipments and passes the results to a downstream billing agent. A unit conversion error runs for six days. The logs hold every conversation and no record of which shipments were repriced, so the operator reissues every invoice in the period rather than the four hundred that were affected.
The control the organization has described to its board, its auditor, and its regulator does not operate. Every assurance claim resting on the sentence “a person approves this” is unsupported, which converts a design weakness into a governance and disclosure failure.
Customers and staff act on confident, wrong output, and the organization carries liability for advice it never intended to give. Where the deployment is high risk under the EU AI Act, the human oversight obligation in Article 14 is not met in substance, even though a reviewer appears on the process map.
A reviewer sees what the agent presents, in the form the agent presents it, at the rate the agent produces it. Approval quality falls as volume rises, which is the automation bias NIST files under human and AI configuration. The reviewer is also shown only the recommendation, not the evidence behind it or the alternative discarded, so the review cannot be substantive even when the reviewer is attentive. A checkpoint that slows throughput is usually removed once the deployment is judged to be working.
A billing team reviews every adjustment an assistant proposes. In the first month a reviewer handles thirty a day and rejects four. By the fourth month the volume is four hundred a day, the rejection rate is nil, and the review step is removed to protect handling times. No risk assessment records the change.
| If you are doing this | Start here |
|---|---|
| Briefing a board or a risk committee | The five categories above, with the business impact stated first. Cite the OWASP identifiers so the material can be traced. |
| Scoping an internal audit of a deployed agent | The five categories for the risk universe, the CSA agentic RMF profile for the governance controls to test, and the IIA framework for how the opinion is structured. |
| Threat modelling a system before it is built | MAESTRO for the layered method, then the OWASP fifteen threats for the conditions to test at each layer. |
| Red teaming or building detections | MITRE ATLAS, which is expressed in the form detection engineering already consumes. |
| Building or certifying a management system | ISO/IEC 42001 for the system and 23894 for the risk process, with the five categories supplying the agent-specific risk register entries neither standard names. |
| Establishing regulatory position in the European Union | The AI Act risk tiers first, since they determine obligation. Article 14 on human oversight is where an agentic deployment most often falls short in substance. |
| Writing policy for a United States federal context | The NIST AI Risk Management Framework and the generative AI profile, watching for the agentic control overlays now in development. |
This page is the reference behind one section of a free thirty minute guided module. The module covers what an agent is, the four components, the loop and the harness, the six positions at which a control can sit, and these five risk categories worked through with examples.
No code is required, nothing is scored, and no registration is needed.
Open Module 0 The agents pathway