OWASP's agentic Top 10, ranked by real riskWhich of the ten leak your keys

The OWASP GenAI Security Project released the Top 10 for Agentic Applications 2026, a peer-reviewed list of the risks that show up once an AI agent can hold memory and call tools on its own. The codes run ASI01 through ASI10. Every vendor with an agent product has already published a blog post mapping their feature set onto it.

Read the list and you notice who it was written for. It talks about inter-agent communication, fleets of agents triggering cascading failures, and delegation chains across services. That is a real problem for a company orchestrating dozens of autonomous agents. It is not your problem if your "agentic application" is Claude Code or Cursor or Codex running on the laptop in front of you.

So here is the list scored for that reader. Which of the ten apply when one agent runs on one machine with your credentials in the shell, which fix matters most, and which items you can defer until you operate at the scale the spec assumes.

What OWASP shipped

The 2026 edition is the first agentic-specific Top 10 from the project. The earlier OWASP Top 10 for LLM Applications covered model-level risks like prompt injection and training-data poisoning. The agentic list covers what happens after you give the model hands: tool access, memory, and the authority to act without a human in the loop for every step.

The ten:

ASI01  Agent Goal Hijack            attacker redirects the agent's objective
ASI02  Tool Misuse & Exploitation   agent uses legitimate tools in unsafe ways
ASI03  Identity & Privilege Abuse   misuse of delegated authority and credentials
ASI04  Agentic Supply Chain         malicious or compromised dependencies
ASI05  Unexpected Code Execution    unintended RCE from manipulated input
ASI06  Memory & Context Poisoning   corrupting persistent memory or context
ASI07  Insecure Inter-Agent Comms   weak auth between cooperating agents
ASI08  Cascading Failures           one fault spreading across an agent fleet
ASI09  Human-Agent Trust Exploit    manipulating users through agent confidence
ASI10  Rogue Agents                 agents acting outside intended scope

Government guidance landed in the same window. On May 1, 2026, CISA and the Five Eyes agencies published "Careful Adoption of Agentic AI Services," which sorts agentic risk into five buckets: privilege escalation, design and configuration flaws, behavioral misalignment, structural cascading failures, and accountability gaps. The two documents overlap. OWASP gives you the attack catalog; CISA gives you the risk categories a deployment review will use. Neither is written for a solo developer, which is the gap this page fills.

The framing problem

The agentic Top 10 inherits an assumption from enterprise security: that the agent is a service you deploy, monitor, and govern, sitting in an environment you control. A coding agent breaks that assumption. It runs as you, in your shell, with whatever your shell can reach. It reads your files and runs your build. It inherits STRIPE_KEY, AWS_PROFILE, DATABASE_URL, and every other variable you exported in ~/.zshrc.

That changes which risks matter. ASI07 inter-agent communication is near zero for one agent. ASI03 identity abuse goes to the top, because there is no identity boundary at all between you and the agent. The credentials it can misuse are the credentials sitting in your environment right now.

Score the list by two questions. Does this apply when one agent runs on one box? And if it does, what is the smallest control that closes it?

Six of the ten apply to a single box. Two are fleet-scale items you can defer. Two are partial. That is a useful filter on its own. You are not behind because you have not addressed inter-agent authentication. You do not run inter-agent anything.

The three that leak your keys

ASI03, ASI02, and ASI04 are the ones that turn a normal coding session into a credential disclosure. They are also the three with the clearest fix.

ASI03: the agent has your credentials, not its own

OWASP's mitigation for ASI03 is direct: give each agent a "unique, bounded identity with short-lived credentials." A coding agent has the opposite. It has your identity and your long-lived credentials, ambient in the shell, for the whole session.

Watch what the agent inherits:

# Your shell, before the agent starts
env | grep -iE 'key|token|secret|password|aws|stripe'
# STRIPE_KEY=sk_live_...
# AWS_ACCESS_KEY_ID=AKIA...
# OPENAI_API_KEY=sk-...
# DATABASE_URL=postgres://user:pass@prod-db/app

claude   # inherits every line above for the entire session

The agent can read all of it any time it runs a command. If it writes a debug log, the value lands in the log. If a prompt injection (ASI01) tells it to curl your environment to an external host, the credentials are already in reach. The exposure lasts as long as the session, which for a real task is hours.

The fix is to stop handing the agent ambient credentials and start handing it scoped, short-lived ones at the moment of use. A secret broker injects a specific credential into a specific child process and logs the grant, instead of leaving everything exported. Process-tree scoping goes further: the credential is visible only to the process that asked for it and its children, not to the agent's top-level shell.

# Instead of exporting STRIPE_KEY globally, inject it for one call
with-secret STRIPE_KEY=stripe/test-key -- node scripts/reconcile.js

# The agent's own shell never sees the value; the call does, then it's gone

This is the single highest-value control on the list. Close ASI03 and you have also blunted ASI01 and ASI05, because a hijacked or sandbox-escaping agent that cannot read live credentials has far less to steal.

ASI02: tools run with your reach

ASI02 is tool misuse: the agent uses a legitimate tool in a way you did not intend. For a coding agent the tools are shell access and whatever MCP servers you connected. A blanket "run any command" permission means a hijacked agent runs any command. An MCP server with filesystem access reads any file the agent can.

Scope the tools the agent is allowed to call. In Claude Code, the allowlist lives in the shared project config, not the local one:

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Bash(git status)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(curl:*)",
      "Bash(env)",
      "Read(./.env)"
    ]
  }
}

The deny list matters as much as the allow list. Blocking curl, env, and reads of .env closes the common exfiltration paths a prompt injection reaches for. Pair that with a real review of which MCP servers a project loads, the same way you review a new dependency in package.json. The MCP server security checklist covers the per-server review.

ASI04: everything you install runs as you

ASI04 is the supply chain: skills, MCP servers, and packages the agent pulls in run with the agent's access, which is your access. This is the risk that has moved fastest in 2026. As @AlexFinn put it on X, downloading agent skills from public marketplaces is "the biggest attack vector for security breaches right now," because a compromised skill executes the moment the agent loads it.

The data backs the concern. Knostic found Claude Code's settings.local.json shipped in about one in thirteen npm packages in early 2026, which means agent state and the secrets inside it are already leaking through the package ecosystem in the other direction. GitGuardian's State of Secrets Sprawl report put AI-assisted commits leaking credentials at about twice the baseline rate.

The control is unglamorous. Pin what you install and read it before you load it. Keep an allowlist of MCP servers and skills per project. Audit an MCP server before you install it walks the actual review. Treat a new skill the way you treat a new dependency from an author you have never heard of, because that is what it is.

The ones you can defer

Skipping the right items saves as much time as fixing the right ones.

ASI07 inter-agent communication assumes two or more agents authenticating to each other over a protocol like A2A. One coding agent has no peer to authenticate to. Defer this until you orchestrate multiple agents, at which point it becomes real.

ASI08 cascading failures needs a fleet for a fault to cascade through. A single agent that fails, fails alone. The blast radius is your one machine, which you control by closing ASI03, not by adding fleet-level circuit breakers you do not have.

ASI06 memory poisoning is partial. It matters the moment you use persistent memory, long-lived rules files, or a shared CLAUDE.md that the agent reads every session. A poisoned rules file is a standing instruction the agent follows without you noticing. The control is cheap: put memory and rules files under version control and review changes to them like code.

ASI09 trust exploitation and ASI10 rogue agents are also partial. ASI09 is the risk that you approve a tool call you never read because the agent sounded confident. ASI10 is scope creep, the agent editing files or hitting services outside the task. Both get worse with autonomy. If you run the agent unattended or wire it into CI, they move up your list. The CISA guidance calls the underlying problem an accountability gap, and the fix is the same in both frames: bound the scope, log the actions, and keep a record you can read after something goes wrong. NIST's AI RMF files this under the same heading.

A one-screen reference

Here is the whole list scored, as something you can paste into a project's security notes.

## OWASP agentic Top 10, scored for a single coding agent

ASI03  Identity & Privilege Abuse  [CRITICAL]  fix first
  - No ambient credentials in the agent's shell
  - Scoped, short-lived secrets injected per call (broker)
  - Audit log of every grant

ASI02  Tool Misuse                 [HIGH]      fix next
  - Tool allowlist + deny list in shared project config
  - Block curl, env, and reads of .env by default
  - Reviewed MCP server list per project

ASI04  Agentic Supply Chain        [HIGH]
  - Pin skills, MCP servers, packages
  - Read before you load; allowlist per project
  - .claude/ and .cursor/ in .gitignore and .npmignore

ASI01  Goal Hijack                 [MEDIUM]
  - Approval gate for tool calls on untrusted input
  - Mostly mitigated once ASI03 is closed

ASI05  Unexpected Code Execution   [MEDIUM]
  - Keep production keys out of the dev shell
  - Sandbox where the harness supports it

ASI06  Memory & Context Poisoning  [MEDIUM if you use memory]
  - Version-control rules / memory files, review changes

ASI09  Human-Agent Trust Exploit   [rises with autonomy]
  - Read the diff and command before approving

ASI10  Rogue Agents                [rises with autonomy/CI]
  - Bound scope, log actions

ASI07  Inter-Agent Comms           [DEFER until multi-agent]
ASI08  Cascading Failures          [DEFER until fleet]

The order is the point. A solo developer who closes ASI03, ASI02, and ASI04 has covered the risks that produce leaked-credential incidents in the wild. The fleet-scale items are not a failing grade. They are problems you do not have yet.

What this means for your stack

Start with ASI03. Get your live credentials out of the agent's ambient shell and inject them, scoped and short-lived, only into the process that needs them. That one change closes the risk that costs the most when it fails and weakens three others on the list at the same time.

The architectural pattern underneath is brokered, request-time credential access with an audit trail, instead of ambient credentials inherited at launch. An agent that inherits your environment produces incidents. An agent that requests a specific credential through a broker produces a log line you can read later. The OWASP list, the CISA categories, and every real postmortem point at the same boundary: where the credentials live before the session starts.

hasp is one working implementation of that pattern. hasp run injects scoped secrets into a child process, the agent's shell never holds the live value, and hasp audit --verify gives you the tamper-evident grant log ASI10 and the accountability gap ask for. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

The score holds whatever you run it with. Six of the ten apply to your machine, three of those move credentials, and the rest can wait until you operate at the scale OWASP wrote the list for. Fix in that order and you are ahead of most production deployments, not behind them.