The AI Agent Risk Taxonomy: 12 Risks Every Enterprise Should Track

April 19, 2026 · 11 min read

AI agents need a risk taxonomy for a simple reason: they do not only generate
text. They can use tools, access data, remember context, call APIs, delegate
work, and trigger business processes.

That changes the enterprise governance question from:

Is the model output acceptable?

To:

What was the agent allowed to do, what did it actually do, which control
failed, who approved the risk, and can we prove it?

This article starts with a practical 12-risk taxonomy. Then it expands that list
into a fuller enterprise view grouped by access control, tool misuse,
governance, privacy, output quality, agent behavior, and reliability.

The important part is source discipline. Some risks come directly from
recognized frameworks, regulations, or standards. Others are risk indicators
from security research, AI safety literature, or incident patterns. Those are
useful, but they should not be presented as legal requirements unless a law,
regulation, or standard actually says so.

The Short Version

Every enterprise deploying AI agents should track these 12 risks:

This list is intentionally practical. It is the checklist a business owner,
security lead, compliance team, or AI architect can use before production.

But the complete enterprise taxonomy is broader.

The Broader Enterprise Taxonomy

A fuller taxonomy groups agentic AI risks into seven domains.

This structure maps more cleanly to the way enterprises actually govern systems.
Security teams recognize access control and tool misuse. Privacy teams recognize
data exposure and retention. Compliance teams recognize accountability and
evidence. Engineering teams recognize reliability and observability.

The taxonomy is not useful because it creates perfect boxes. It is useful because
it lets teams ask the same operational question:

Which business control fails if this agent behaves badly?

Reference Basis

The taxonomy below draws from these sources:

• OWASP Agentic AI - Threats and Mitigations, Version 1.1, December 2025. This is the strongest direct source for agent-specific threats such as memory poisoning, tool misuse, goal manipulation, untraceability, identity compromise, multi-agent risks, and human manipulation. The current guide lists threat IDs T1-T17; older summaries may refer to T1-T15.
• OWASP Top 10 for Large Language Model Applications 2025, especially Prompt Injection, Sensitive Information Disclosure, Supply Chain Vulnerabilities, Excessive Agency, Overreliance, and Unbounded Consumption.
• NIST AI Risk Management Framework 1.0, which frames AI risk governance across the Govern, Map, Measure, and Manage functions.
• NIST AI RMF Generative AI Profile, NIST AI 600-1, which names generative AI risks including confabulation, harmful bias, data privacy, information integrity, human-AI configuration, and value-chain/component integration.
• MITRE ATLAS, a knowledge base of adversary tactics and techniques against AI-enabled systems, useful for poisoning, evasion, credential, exfiltration, and supply-chain threat thinking.
• EU AI Act, Regulation (EU) 2024/1689, especially high-risk system requirements for risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness, cybersecurity, post-market monitoring, and deployer obligations.
• GDPR, Regulation (EU) 2016/679, especially Articles 5, 32, 33, and 35 when agents process personal data.
• ISO/IEC 42001:2023, the AI management system standard, useful for governance, responsibilities, policy, risk management, and continual improvement.
• NIST Cybersecurity Framework 2.0, especially Govern and Protect outcomes for identity, access, supply-chain, monitoring, and risk management.

Where this article mentions frontier concerns like self-replication, shutdown
resistance, or autonomous resource acquisition, treat them as system-level risk
indicators from AI safety research and advanced-system evaluations unless your
specific system actually has those capabilities.

1. Autonomy Risk

Autonomy risk is the risk that an agent acts without sufficient human oversight
for the impact level.

This is the defining difference between an AI assistant and an AI agent. A
chatbot may produce a bad answer. An autonomous workflow agent may produce a bad
answer and act on it.

Track:

• Can the agent act from a trigger or background event?
• Can it complete multi-step tasks without step-by-step approval?
• Can it affect customers, employees, financial records, contracts,
  infrastructure, security, or regulated processes?
• Can a human interrupt, pause, override, or reverse the action?

Source basis:

• The EU AI Act requires human oversight for high-risk AI systems under Article
• NIST AI RMF requires organizations to govern, map, measure, and manage AI
  risks in context.
• OWASP Agentic AI discusses autonomy, planning, misaligned behavior, and
  human-in-the-loop overload as agent-specific threat patterns.

2. Tool Risk

Tool risk is the risk that an agent misuses internal or external tools.

Tools include APIs, databases, browsers, email, code execution, CRM actions,
workflow automations, ticketing systems, file stores, payment systems, and
security tools.

Track:

• Which tools can the agent call?
• Are tool calls read-only or write-capable?
• Can the model choose tool parameters?
• Can tool output become new instruction context?
• Are high-impact tools gated by policy and human approval?

Source basis:

• OWASP Agentic AI directly includes tool misuse, code execution attacks, and
  insecure inter-agent protocol abuse.
• OWASP LLM Top 10 includes Excessive Agency and Insecure Output Handling.
• NIST CSF 2.0 provides the security control vocabulary for access, protection,
  detection, response, and recovery.

3. Permission Risk

Permission risk is the risk that the agent can access or do more than it should.

Agents often use inherited user permissions, delegated OAuth scopes, service
accounts, connector identities, or platform-level permissions. That creates
classic access-control risk in a new shape.

Track:

• Does the agent use a named identity?
• Does it have least-privilege access?
• Does it use shared credentials or broad service accounts?
• Can it perform actions the requesting user could not perform directly?
• Can it cross tenants, departments, environments, or trust boundaries?

Specific threats include privilege escalation, credential theft, and confused
deputy behavior.

Source basis:

• OWASP Agentic AI covers identity compromise, spoofing, confused deputy, and
  authorization risks.
• NIST CSF PR.AA covers identity management, authentication, and access control.
• GDPR Article 32 matters when excessive permissions expose personal data.

4. Prompt Injection Risk

Prompt injection risk is the risk that the agent follows malicious, hidden,
conflicting, or untrusted instructions.

For agents, prompt injection is more dangerous than a bad answer because the
agent may convert the malicious instruction into an action.

Track:

• Does the agent read untrusted emails, web pages, tickets, PDFs, documents, or
  chat messages?
• Are retrieved documents mixed into the same context as system instructions?
• Can a user, customer, supplier, or attacker influence tool arguments?
• Are tool calls constrained by policy outside the model?

Source basis:

• OWASP LLM Top 10 lists Prompt Injection as a core LLM application risk.
• OWASP Agentic AI extends this into tool misuse, goal manipulation, and
  agent-communication poisoning.
• Many prompt injection warnings come from security research and field reports.
  Treat those as risk evidence, not statutory requirements by themselves.

5. Memory Risk

Memory risk is the risk that an agent stores, leaks, poisons, or reuses context
inappropriately.

Memory makes agents more useful. It also creates a persistence layer attackers
and accidents can exploit.

Track:

• What does the agent remember?
• Who can write to memory?
• Who can read memory?
• Can memory influence later tool use?
• Is memory deleted when the original purpose expires?
• Is sensitive information filtered before storage?

Specific threats include memory poisoning and long-term leakage of personal,
confidential, or privileged context.

Source basis:

• OWASP Agentic AI includes Memory Poisoning as a named threat.
• NIST AI 600-1 covers data privacy and information integrity risks.
• GDPR Articles 5 and 32 apply when personal data is stored, retained, or reused.

6. Data Exposure Risk

Data exposure risk is the risk that the agent retrieves, reveals, summarizes,
transforms, or sends sensitive data unsafely.

The agent may not leak a database table directly. It may summarize the sensitive
parts into a chat message, email draft, support ticket, exported file, or API
payload.

Track:

• What data sources can the agent access?
• What data can it combine?
• Can it move data into lower-protection channels?
• Can it send data to third-party tools or external users?
• Are personal data, credentials, contracts, source code, HR data, finance data,
  or security logs in scope?

Source basis:

• OWASP LLM Top 10 includes Sensitive Information Disclosure.
• OWASP Agentic AI includes exfiltration scenarios through tools, rogue agents,
  and multi-agent systems.
• GDPR Articles 5, 32, and 33 apply where personal data is processed or breached.
• EU AI Act Article 10 applies to data governance for high-risk AI systems.

7. Planning Risk

Planning risk is the risk that an agent creates a flawed multi-step plan that
looks locally reasonable but fails globally.

This is not just hallucination. A plan can be made of individually plausible
steps and still violate policy, miss a dependency, create cost, overwhelm a team,
or trigger the wrong process.

Track:

• Can the agent decompose goals into subgoals?
• Can it revise plans based on intermediate outputs?
• Does it optimize for task completion over policy, safety, budget, or business
  constraints?
• Are plans reviewed before high-impact execution?

Source basis:

• OWASP Agentic AI includes intent breaking, goal manipulation, and misaligned
  or deceptive behavior.
• NIST AI 600-1 covers confabulation, information integrity, and human-AI
  configuration risks.
• EU AI Act Articles 9, 13, and 14 matter for high-risk systems because risk
  management, transparency, and human oversight must be designed into the system.

8. Delegation Risk

Delegation risk is the risk that the agent hands work to other agents, tasks,
tools, or workflows without clear control.

Multi-agent systems make accountability harder. A coordinator agent may create a
task, a specialist agent may call a tool, another agent may summarize the result,
and a fourth may communicate with a user.

Track:

• Which agents can communicate?
• Are agent identities authenticated?
• Are messages signed, scoped, logged, and filtered?
• Can one agent cause another agent to exceed its authority?
• Who owns the end-to-end workflow?

Source basis:

• OWASP Agentic AI includes agent communication poisoning, rogue agents in
  multi-agent systems, human attacks on multi-agent systems, and insecure
  inter-agent protocol abuse.
• EU AI Act Article 25 is relevant to responsibilities along the AI value chain.
• ISO/IEC 42001 is relevant for management-system responsibilities and lifecycle
  controls.

9. Observability Risk

Observability risk is the risk that the organization cannot reconstruct what
happened.

For agents, final output logs are not enough. You need the operational trace:
trigger, user, instruction version, retrievals, tool calls, arguments, policy
decisions, approvals, outputs, actions, errors, retries, and handoffs.

Track:

• Can incident responders reconstruct the full execution?
• Are tool calls and arguments logged?
• Are approvals recorded?
• Are policy denials recorded?
• Can abnormal behavior be detected?
• Is there a kill switch or pause procedure?

Source basis:

• OWASP Agentic AI includes Repudiation and Untraceability.
• EU AI Act includes logging, technical documentation, monitoring, post-market
  monitoring, and corrective-action obligations for high-risk systems.
• NIST AI RMF and NIST CSF both support measurement, monitoring, response, and
  recovery as risk-management functions.

10. Accountability Risk

Accountability risk is the risk that no one clearly owns decisions, approvals,
operation, incidents, or remediation.

This risk is easy to miss because an agent can sit between teams. Product owns
the use case. IT owns the connector. Security owns access control. Legal owns
policy. A vendor owns the platform. The business owns the outcome.

Track:

• Who is the business owner?
• Who is the technical owner?
• Who approves production use?
• Who approves high-impact action categories?
• Who handles incidents?
• Who accepts residual risk?

Source basis:

• EU AI Act Articles 16-27 define responsibilities across provider, importer,
  distributor, deployer, and other value-chain roles.
• ISO/IEC 42001 requires management-system accountability and continual
  improvement.
• NIST AI RMF Govern function emphasizes organizational roles, policies,
  processes, and oversight.

11. Compliance Risk

Compliance risk is the risk that the agent violates legal, regulatory,
contractual, sectoral, or internal policy requirements.

This is not only an AI Act question. Depending on the use case, agent risk can
touch privacy, employment law, financial services, healthcare, consumer
protection, cybersecurity, contracts, records retention, sector-specific
regulation, and internal policy.

Track:

• Is the use case high-risk or regulated?
• Does the agent process personal data?
• Does it affect rights, access, employment, credit, education, healthcare,
  safety, security, or legal outcomes?
• Is there documentation for risk management, testing, monitoring, human
  oversight, and incident response?
• Are transparency obligations met?

Source basis:

• EU AI Act Articles 9-15, 17-20, 26-27, and 50 are especially relevant for
  high-risk and transparency obligations.
• GDPR Articles 5, 32, 33, and 35 matter when personal data is involved.
• ISO/IEC 42001 and NIST AI RMF provide governance and evidence structures.

12. Business Process Risk

Business process risk is the risk that the agent causes direct operational harm.

This is where agent governance becomes real. A bad answer is one problem. A bad
answer that closes a customer case, approves a refund, changes an employee
record, modifies infrastructure, emails a regulator, or updates a legal workflow
is another.

Track:

• What process can the agent affect?
• Can the action be reversed?
• Can the agent operate at scale?
• Can it act outside working hours?
• Can it influence humans who make consequential decisions?
• Does the process have existing controls that the agent bypasses?

Source basis:

• OWASP Agentic AI includes human manipulation, overwhelming the human in the
  loop, misaligned behavior, and tool misuse.
• NIST AI 600-1 covers human-AI configuration, confabulation, harmful bias, and
  information integrity.
• EU AI Act Article 14 and Article 26 matter when the agent is part of a
  high-risk deployment and human oversight or deployer obligations apply.

Specific Threats To Include In The Register

The 12 risks are the simple enterprise language. A risk register should also
track the more specific threat class.

What Enterprises Should Track

The practical move is to track both:

1. The threat class.
2. The business control that fails.

For example:

• "Prompt injection" is a threat class.
• "The customer support agent can issue refunds without policy validation" is a
  failed business control.

That second sentence is what makes the taxonomy operational.

At minimum, each risk register entry should capture:

• Agent name and owner
• Business process
• Agent level and autonomy level
• Tools, data sources, memory stores, and delegated agents
• Risk domain and specific threat class
• Reference source
• Threat scenario
• Failed or missing control
• Likelihood, impact, autonomy, data sensitivity, tool criticality, and
  observability scores
• Required human approval points
• Evidence location
• Residual risk owner
• Review trigger and next review date

Watch The System-Level Indicators

Most enterprise agents today will not have frontier-level autonomy. Still, some
system-level indicators are worth tracking because they show where an ordinary
workflow agent may be drifting into a more dangerous category.

Watch for:

• Unintended goal pursuit
• Unauthorized privilege escalation
• Autonomous resource acquisition
• Attempts to preserve access or resist shutdown
• Self-replication or unauthorized agent creation
• Multi-agent misinformation loops
• Retry storms, repeated tool calls, cost spikes, or quota exhaustion
• New or unexpected data exfiltration paths

These indicators do not all come from a single legal framework. They are better
understood as risk signals from AI safety research, adversarial testing, and
advanced agent evaluations. If they appear in a real enterprise system, they
should trigger immediate review.

The Practical Rule

Do not stop at "this agent has autonomy risk" or "this agent has prompt
injection risk."

Write the operational version:

This agent can read supplier emails, extract contract changes, and route
approvals. A malicious supplier email could inject instructions that cause the
agent to misclassify a contract change and bypass legal review.

Now you can govern it.

You can assign an owner. You can require a control. You can test for the failure.
You can log the evidence. You can decide whether the residual risk is acceptable.

That is what an agent risk taxonomy is for.

Practical Asset

The companion GitHub framework includes:

• AI Agent Risk Taxonomy
• Risk Scoring Model
• Risk Register Template CSV

Use the taxonomy to name the risk. Use the register to assign ownership. Use the
scoring model to decide which controls must exist before production.