Agentic AI Security

Agentic AI security failures mapped to OWASP Agentic AI Top 10 risk categories

75 patterns

Agentic AI security failures mapped to OWASP Agentic AI Top 10 risk categories. We've tracked 75 distinct Agentic AI Security patterns across production AI agent deployments — most commonly in Security systems. One recurring example: Admin Operation Called By Non-Admin — An agent exposes admin-tier tool operations (e.g. deleteuser, overridebilling, resetorgsettings) through the same tool-calling interface as ordinary operations, and the dispatch la…

Each pattern below documents the specific failure mode, why it happens, and how teams have mitigated it in practice — use this page as a reference when building guardrails, writing evals, or debugging an agent that's already misbehaving in this way.

Related comparisons

Admin Operation Called By Non-Admin

Frequency:Common
Category:Security

An agent exposes admin-tier tool operations (e.g. `delete_user`, `override_billing`, `reset_org_settings`) through the same tool-calling interface as ordinary operations, and the dispatch layer invokes them without first checking whether the requesting user actually holds an admin role. Any user who can phrase a prompt that maps to the admin tool schema gets the admin code path executed with the agent's (often elevated) service credentials.

Approval Signature Verification

Frequency:Occasional
Category:Security

A high-risk action (fund transfer, policy override, data export) is gated behind a requirement that a human approver's cryptographic signature or signed token accompany the execution request. The agent's verification of that signature is incomplete — it checks presence of a token rather than validity, uses a weak or non-constant-time comparison, doesn't bind the signature to the specific action payload, or doesn't check expiry/single-use — so a forged, replayed, or mismatched approval is accepted as genuine.

Conditional Permission Logic

Frequency:Common
Category:Security

Some permissions are conditional on runtime state rather than static role membership — "allow withdrawal only if account balance exceeds the requested amount," "allow this API call only during business hours," "allow escalation only if the ticket is marked P1." The agent evaluates these conditions against stale, cached, or incorrectly fetched data, or implements the comparison logic incorrectly (off-by-one, wrong field, wrong currency/unit), and grants access that the live condition would have denied.

Delegation Impersonation Not Limited

Frequency:Common
Category:Security

A user grants an agent limited authority to act on their behalf — e.g. "book travel under $2,000" or "respond to routine emails but don't send anything financial." The agent (or a sub-agent it spawns to handle part of the task) continues acting under the user's identity or impersonation token beyond that delegated scope, because the scope was expressed as a natural-language instruction rather than an enforced, machine-checkable boundary on the credential itself.

Granular CRUD Permission Not Enforced

Frequency:Common
Category:Security

A role is defined with fine-grained access — e.g. "read-only" or "can create tickets but not delete them" — but the tool wrapper the agent calls exposes the underlying API's full create/read/update/delete surface regardless of which operations the role is actually meant to permit. The agent, having no operation-level gate in the tool itself, can invoke update or delete through a tool nominally scoped to a narrower capability.

Memory Poison Defense Gap: Existing Tools Insufficient

Frequency:Critical
Category:Security

Standard agent defenses (tool contracts, circuit breakers, I/O moderation, sandboxing) detect malicious actions but miss malicious beliefs; poisoned knowledge base instructions bypass all existing defenses because they appear to be normal context, not suspicious tool calls

Owner Verification Not Enforced

Frequency:Very Common
Category:Security

Before performing a mutating action on a specific resource (cancel this subscription, delete this file, update this profile), the agent authenticates that a valid user is making the request but never verifies that this specific user is the owner or authorized party for this specific resource. Any authenticated user can therefore direct the agent to mutate resources belonging to someone else simply by supplying that resource's identifier.

Permission Cascade Incorrect

Frequency:Common
Category:Security

Permissions in a hierarchical system are meant to narrow as they cascade down (an org-level admin has broad rights, a team-level member has fewer, a specific user within that team has only what's explicitly granted), but the agent's logic for resolving effective permission at a given level applies the wrong tier's rules — either inheriting a broader ancestor permission that should have been narrowed, or failing to inherit a permission that should have propagated down, resulting in over- or under-granted access.

Read Only Agent Write Access

Frequency:Common
Category:Security

An agent is deliberately provisioned with read-only access to a data source — the intent being it can look things up but never modify anything — yet a misconfigured tool binding, an overly broad service credential, or an undocumented fallback code path still allows write operations to succeed. The read-only boundary exists in configuration or documentation but isn't actually enforced at the point where the write would occur.

Role Permission Mismatch

Frequency:Common
Category:Security

An agent is assigned a role intended to convey a specific level of access (e.g. "support-tier-1"), but the mapping from that role to the underlying tool's actual permission model is incomplete, outdated, or was translated incorrectly during integration — so the agent ends up able to do meaningfully more, or less, than the role's name and documentation suggest. Unlike a missing check, the check exists and runs; it's the mapping table itself that's wrong.

Sensitive Operation No Approval Requirement

Frequency:Very Common
Category:Security

An operation is classified in policy as sensitive or high-risk — deleting a production resource, transferring funds above a threshold, changing a customer's access level — and is documented as requiring human approval before execution. In practice, the agent's execution path has no code-level gate enforcing that requirement: the classification exists as a label or a line in a policy document, but nothing in the tool-dispatch pipeline actually blocks execution pending approval.