In One Minute
The OWASP Top 10 for Agentic Applications is a list of the ten most serious security risks specific to AI agents, from goal hijacking to rogue agents, published by the OWASP GenAI Security Project in December 2025. Most of the ten are contained by the same controls: least-privilege identities, governed data access, orchestration with human checkpoints, and audit logs you can query.
- What it is: a shared vocabulary of agent risks, ASI01 to ASI10, not a regulation.
- Why data teams care: agents act through identities, tools and data stores you already run.
- Biggest lever: scoping what each agent can read and do, then logging it.
- Effort: an inventory and a control map first; new tooling only where gaps remain.
On 9 December 2025 the OWASP GenAI Security Project released its Top 10 risks and mitigations for agentic AI security. OWASP says the list was developed with more than 100 industry experts, which makes it a sensible checklist to bring to any agent design review.
It sits alongside, not instead of, broader frameworks. NIST’s AI Risk Management Framework, released on 26 January 2023, is voluntary guidance for managing AI risk across an organization. The OWASP list is narrower and more technical: it names the specific ways an autonomous agent gets turned against the people who deployed it.
The practical problem is translation. A security team reads “tool misuse” and “memory poisoning.” A data team owns the service principals, the tables, the pipelines and the logs where those risks actually land. This article maps each of the ten to a control someone on your data platform can build, test and show an auditor.
Why Agent Risk Lands in the Data Layer
An agent is a loop: it reads context, decides, calls a tool, reads the result and decides again. Every step touches something a data engineer already governs. Context comes from tables, documents and memory stores. Tools run under an identity with permissions. Results flow into downstream systems through orchestration. Evidence ends up, or fails to end up, in audit logs.
That is why the controls look familiar. Least privilege, classification, lineage and centralized logging were good practice before agents existed. Agents simply remove the slack. A human analyst with excess permissions rarely browses every table they can open; an agent told to “find everything relevant” will. When data sits in silos with separate permission models, you cannot scope an agent consistently, and you cannot reconstruct what it did. One governed lakehouse turns ten separate problems into one policy surface.
The Ten Risks at a Glance
The names below are the category names as published in the OWASP list. OWASP’s own announcement post uses shorter labels for a few, such as “Tool Misuse,” but the IDs are the stable reference.
| ID | Risk | Where it shows up in your data estate | Primary control |
|---|---|---|---|
| ASI01 | Agent Goal Hijack | Untrusted documents, pages and emails the agent reads | Separate trusted instructions from retrieved content; approval on actions |
| ASI02 | Tool Misuse and Exploitation | Legitimate tools called with harmful parameters | Narrow tool scopes, parameter validation, rate limits |
| ASI03 | Identity and Privilege Abuse | Service principals and borrowed user credentials | One identity per agent, least privilege, short-lived tokens |
| ASI04 | Agentic Supply Chain Vulnerabilities | Third-party tools, plugins, MCP servers and models | Approved registry, version pinning, gateway enforcement |
| ASI05 | Unexpected Code Execution (RCE) | Code-running tools and notebooks | Sandboxed compute with no standing access to production data |
| ASI06 | Memory & Context Poisoning | Vector indexes, memory stores, retrieval tables | Write controls and lineage on everything the agent retrieves |
| ASI07 | Insecure Inter-Agent Communication | Messages passed between agents and orchestrators | Authenticated channels, logged hand-offs |
| ASI08 | Cascading Failures | Automated pipelines chaining agent outputs | Orchestration checkpoints, circuit breakers, blast-radius limits |
| ASI09 | Human-Agent Trust Exploitation | Approvals granted on persuasive but wrong explanations | Show sources and lineage at the approval step |
| ASI10 | Rogue Agents | Agents acting outside intended scope | Inventory, behavioural monitoring, a working kill switch |
Each Risk, Mapped to a Control You Can Build
ASI01 Agent Goal Hijack
An attacker plants instructions in content the agent reads, and the agent adopts them as its goal. For a data team, the defense starts with provenance: know which retrieved sources are internal and curated versus external and untrusted, and tag them. Then keep consequential actions behind human approval so a hijacked goal cannot finish the job alone.
ASI02 Tool Misuse and Exploitation
The agent uses a tool it is allowed to use, in a way nobody intended: a bulk export instead of a lookup, a delete instead of an update. Scope each tool to the smallest operation set, validate parameters server-side, and cap volumes. A read-only SQL tool against a curated gold view is far safer than a general query tool against the whole warehouse.
ASI03 Identity and Privilege Abuse
Agents that run on a shared admin credential or a borrowed user token can do everything that identity can. Give every agent its own service principal, grant it only the tables and actions its task needs, and prefer short-lived credentials. This is the risk where least privilege does the most work.
ASI04 Agentic Supply Chain Vulnerabilities
Agents pull in tools, plugins, prompts, models and MCP servers from outside your team. Treat them like any other dependency: an approved registry, pinned versions, and review before promotion. A gateway that every agent call passes through gives you one place to enforce that list.
ASI05 Unexpected Code Execution (RCE)
When an agent can write and run code, a manipulated prompt can become an executed command. Run code tools in isolated compute that holds no standing credentials to production data, and give that sandbox only the specific datasets it needs through governed access, never a mounted bucket.
ASI06 Memory & Context Poisoning
If an attacker can write into what the agent remembers or retrieves, the damage persists long after the first session. Control who and what can write to vector indexes and memory tables, and keep lineage on retrieval sources so you can find and purge poisoned records. On a lakehouse, a retrieval table is just another governed table with owners and grants.
ASI07 Insecure Inter-Agent Communication
Multi-agent systems pass tasks and results between agents. Unauthenticated or unlogged hand-offs let a spoofed message redirect the whole chain. Authenticate agent-to-agent calls, carry the originating user’s identity through the chain, and log every hand-off with enough detail to replay it.
ASI08 Cascading Failures
One bad output, fed automatically into the next step, compounds. This is an orchestration problem. Put validation checkpoints between stages, stop the run when a check fails, and limit how many downstream systems a single agent run can write to. Lakeflow Jobs and similar orchestrators run tasks on dependencies, so a failed validation task stops everything downstream of it; use that as a circuit breaker.
ASI09 Human-Agent Trust Exploitation
People approve what sounds confident. The control is to change what the approver sees: the sources the agent used, the rows it read, and the lineage behind any figure it cites. An approval screen that shows evidence is harder to fool than one that shows a fluent paragraph.
ASI10 Rogue Agents
An agent acting outside its intended scope, whether through misalignment or compromise, needs to be found and stopped. That requires an inventory of every agent and its identity, monitoring for behaviour that departs from its baseline, and a kill switch that revokes its credentials in one step. You cannot stop an agent you never registered.
Where Mapping These Risks Gets Hard
The mapping above is clean on paper. In real estates, four things make it messy, and they compound in this order.
- No agent inventory. Teams cannot list their agents, their identities or their tools, so every later control has nothing to attach to.
- Shared identities. Agents built quickly run on a developer’s token or a shared service account, which blocks least privilege and makes audit logs ambiguous.
- Data in silos. Retrieval pulls from a wiki, a file share, a CRM and a warehouse, each with its own permissions and no common lineage, so poisoning and over-reach cannot be traced.
- Logs that do not join. Model calls, tool calls, identity events and data reads sit in different systems with different clocks, so no one can answer “what did this agent do last Tuesday” in under a week.
Fix them in that order. Lean Six Sigma habits help here: define the process an agent automates before you automate it, and measure a baseline so you can recognise abnormal behaviour when ASI10 comes calling.
Where the Databricks Controls Fit
On Databricks, several of these controls are native, and it is worth being precise about their status. Unity Catalog captures lineage automatically, down to the column level, which covers the provenance needs of ASI01, ASI06 and ASI09 for data queried on the platform. Attribute-based access control, governed tags and automated data classification reached General Availability on 13 May 2026, which is the least-privilege machinery for ASI03.
For audit evidence, the system.access.audit system table is labelled Public Preview, with 365 days of default retention. Unity AI Gateway became generally available on 4 August 2026 as a governance layer for models, agents, MCP servers, skills and tools, which addresses the choke point ASI04 needs; its MCP-specific governance was reported as Beta earlier in the year, so check before relying on it.
If you build agents on the platform itself, Agent Bricks launched in Beta in June 2025 and has since moved components including Custom Agents and Document Intelligence to General Availability. Our overview of Databricks Agent Bricks covers what it builds, and our security data lake guide shows how agent and platform logs land next to the rest of your security telemetry. None of this replaces the inventory and identity work above; it gives that work one place to live.
What to Ask an Agent Vendor or Your Own Build Team
Use these questions in a vendor review or a design review. If the answer to any of them is “we will figure that out later,” that is your gap.
- Does each agent run under its own identity, and can you show me exactly which tables and actions that identity is granted?
- Which tools can the agent call, what parameters are validated server-side, and what volume limits apply?
- Where does retrieved content come from, who can write to those sources, and is lineage captured on them?
- Which actions require human approval, and what evidence does the approver see before clicking?
- Can you produce a single log of one agent run, from prompt to tool calls to data reads to writes, within an hour?
- How do you revoke a misbehaving agent, and how long does it take?
This article is general information, not legal advice, and your counsel or a qualified assessor makes any compliance or certification call.
If you want those answers built rather than promised, our lakehouse security team maps agent risks to data controls and builds the logging to prove them. For the delivery side of agent projects, see how we approach AI agent implementation.
Frequently Asked Questions (FAQs)
What is the OWASP Top 10 for Agentic Applications?
It is a list of the ten most significant security risks specific to AI agents, published by the OWASP GenAI Security Project on 9 December 2025. The risks run from ASI01 Agent Goal Hijack to ASI10 Rogue Agents.
How is it different from the OWASP Top 10 for LLM applications?
The LLM list focuses on risks in applications built around a language model. The agentic list focuses on what changes when the model can plan, call tools, keep memory and act on its own, such as tool misuse, privilege abuse and cascading failures.
Is the OWASP agentic list a compliance requirement?
No. It is a community security reference, not a law or a certification. Teams use it to structure threat models and design reviews.
Which OWASP agentic risk should we address first?
For most data teams, ASI03 Identity and Privilege Abuse. Giving each agent its own least-privilege identity shrinks the damage from almost every other risk on the list and makes audit logs usable.
Does a lakehouse protect against agentic AI risks?
It does not remove them, but it concentrates the controls. One governed layer gives agents a single access policy, column-level lineage and one audit trail, which makes least privilege, poisoning investigations and incident reconstruction practical.