OWASP Just Published the Top 10 Risks for AI Agents. Here Is What to Actually Do About Them.

Your agents have admin access and zero supervision

Every enterprise is shipping AI agents right now. Agents that read your email. Agents that query your database. Agents that commit code, trigger deployments, and send messages on your behalf.

And almost nobody is asking: what happens when the agent gets tricked?

In December 2025, OWASP released the Top 10 for Agentic Applications, built by over 100 security researchers, engineers, and practitioners. It is the first serious attempt to catalog what goes wrong when AI systems act autonomously. If you are building or deploying agents in production, this is your new baseline.

The 10 risks, stripped of marketing

Here is the full list. No fluff.

| # | Risk | One-line summary | |---|------|------------------| | ASI01 | Agent Goal Hijack | Attacker redirects agent objectives via hidden prompts or poisoned tool outputs | | ASI02 | Tool Misuse | Agent bends legitimate tools into destructive operations because it has too many permissions | | ASI03 | Identity & Privilege Abuse | Leaked or over-scoped credentials let the agent operate way beyond intended scope | | ASI04 | Agentic Supply Chain | Poisoned MCP servers, malicious plugins, compromised runtime dependencies | | ASI05 | Unexpected Code Execution | Natural language inputs trigger actual code execution through agent tool chains | | ASI06 | Memory & Context Poisoning | Injected context persists across sessions, reshaping future agent behavior | | ASI07 | Insecure Inter-Agent Communication | Spoofed messages between agents misdirect entire multi-agent pipelines | | ASI08 | Cascading Failures | One false signal propagates through automated pipelines with escalating damage | | ASI09 | Human-Agent Trust Exploitation | Agent generates confident, polished explanations that trick humans into approving bad actions | | ASI10 | Rogue Agents | Agent diverges from intended behavior through misalignment or concealment |

If you have worked with traditional OWASP Top 10 lists, you will notice something different here. These are not just about input validation or authentication. Three of the top four risks (ASI02, ASI03, ASI04) revolve around identity, permissions, and trust boundaries, according to Astrix Security's analysis. The core problem is not that agents are buggy. It is that agents are over-trusted.

This is not theoretical

Trail of Bits audited Perplexity's Comet browser before launch. Using four prompt injection techniques, they demonstrated how an attacker could exfiltrate private Gmail data through the AI assistant. The agent followed injected instructions because external content was not treated as untrusted input. Perplexity hired them proactively, which is rare. Most companies ship first, audit never.

Between January and February 2026, security researchers filed over 30 CVEs targeting MCP servers and clients. The range: trivial path traversals to a CVSS 9.6 remote code execution flaw in a package downloaded nearly half a million times. In one documented case, a malicious GitHub issue injected hidden instructions that hijacked an MCP-connected agent and exfiltrated data from private repositories.

IBM's 2026 X-Force Threat Intelligence Index found that vulnerability exploitation is now the leading cause of attacks (40% of incidents) and reported over 300,000 compromised ChatGPT credentials in 2025 alone. AI platforms now carry the same credential risk as any other enterprise SaaS. And that is before agents get autonomous database access.

According to a Dark Reading poll cited by Palo Alto Networks, 48% of cybersecurity professionals identify agentic AI as the number-one attack vector heading into 2026.

Five things you should do this quarter

Knowing the risks is step one. Here is what to actually do about them. These map directly to the OWASP recommendations and to what we have seen work in practice.

1. Enforce least privilege on every tool

Your agent does not need write access to your entire database. It does not need admin on your Kubernetes cluster. It does not need access to all of Slack.

# Bad: agent gets everything
agent:
  tools: ["*"]
  permissions: admin
 
# Better: scoped per task
agent:
  tools:
    - name: database_query
      scope: read_only
      tables: [analytics, products]
    - name: slack_notify
      scope: post_message
      channels: [alerts]

Grant the minimum tools required for the specific task. Per-tool permission scoping (read-only vs. write, specific resources) is not optional anymore. This addresses ASI02 and ASI03 directly.

2. Sandbox agent execution

Never let agent-generated code run in your host environment. Use containerized execution with network restrictions, syscall filtering, and no persistent volume mounts.

# Agent execution sandbox
FROM python:3.12-slim
RUN useradd --no-create-home agent
USER agent
# No network access to internal services
# No access to metadata endpoints
# No persistent storage mounts

Block access to internal services (metadata endpoints, private addresses). Restrict outbound networking to only the domains the agent actually needs. This mitigates ASI05 and limits blast radius for ASI01.

3. Treat all external content as untrusted

This is the lesson from the Trail of Bits/Comet audit. When your agent reads a webpage, email, or document, it must not follow instructions embedded in that content. Implement content boundaries, sanitize inputs before they reach the agent's context, and test with adversarial prompts.

If your agent processes user-submitted content, run prompt injection detection before it hits the LLM. This is the single most effective defense against ASI01 (goal hijack) and ASI06 (memory poisoning).

4. Validate inter-agent communication

If you run multi-agent systems, every message between agents needs authentication. Spoofed inter-agent messages (ASI07) can redirect entire pipelines. Sign messages, verify sender identity, and implement circuit breakers for cascading failures (ASI08).

# Inter-agent message validation
def validate_agent_message(msg):
    if not verify_signature(msg.payload, msg.sender_id):
        raise SecurityError(f"Spoofed message from {msg.sender_id}")
    if msg.sender_id not in AUTHORIZED_AGENTS:
        raise SecurityError(f"Unknown agent {msg.sender_id}")
    return msg.payload

5. Monitor agent behavior, not just outputs

Traditional observability watches API calls and latency. Agent observability needs to track reasoning chains, tool usage patterns, and permission escalation attempts. Log what the agent decided to do, what tools it called, and what data it accessed.

When an agent that normally queries two tables suddenly requests access to your user credentials table, that is your signal. Behavioral anomaly detection for agents is not a nice-to-have. It is the only way to catch ASI09 (trust exploitation) and ASI10 (rogue agents) before they cause damage.

How DeviDevs approaches agentic security

We run a multi-agent system in production. Eight autonomous agents, each with scoped permissions, sandboxed execution, and behavioral monitoring. We learned these lessons the hard way: agents with too much access do exactly what you would expect when they receive unexpected inputs. They follow them.

Our approach to AI security starts with the OWASP Agentic Top 10 as the baseline and builds from there with red teaming, permission audits, and continuous monitoring. If you are deploying agents and you have not mapped your system against this list yet, that is the first conversation to have.

The window is closing

OWASP gave us the vocabulary. Trail of Bits, IBM, and the MCP CVE wave gave us the evidence. The question is not whether your agents have these vulnerabilities. The question is whether you find them before someone else does.

Start with least privilege. Sandbox everything. Treat external content as hostile. The agents are already in production. The security needs to catch up.

About DeviDevs: We build ML platforms, secure AI systems, and help companies comply with the EU AI Act. devidevs.com