OWASP Top 10 for Agentic Applications (2026), mapped to code

The OWASP Top 10 for Agentic Applications 2026 is the OWASP GenAI Security Project's list of the ten highest-impact risks in AI agents, numbered ASI01 to ASI10 and published on 9 December 2025 by its Agentic Security Initiative. This page gives each risk a control you can write in code, and says plainly whether Anlyon enforces that control. The short answer: a layer that makes the agent's production calls for it can enforce the controls for tool misuse, credentials and privilege, and blast radius. It does nothing for code execution, memory poisoning or agent-to-agent messaging.

Risk names and IDs below are OWASP's, from the official resource page and the document it links (version 2026, December 2025), checked on 2026-10-18. The list is maintained by the Agentic Security Initiative and builds on the OWASP Top 10 for LLM Applications 2025. The quotations are OWASP's text, licensed CC BY-SA 4.0.

TL;DR: the ten risks and where each one is handled

What does "routed through Anlyon" mean?

Everything in the last column depends on one boundary. Anlyon governs the actions routed through its hosted executor. A tool your own code calls directly is not routed through Anlyon and is not governed by it.

Without Anlyon   agent -> your API credential -> production API
With Anlyon      agent -> named action -> Anlyon -> production API

The agent names an action and passes input. Anlyon resolves the credential at dispatch and makes the request. That position is what lets it enforce a limit, an approval and a receipt. It is also why it cannot help with risks that live inside the agent's own process, such as code the agent runs or the memory it keeps.

How do you mitigate ASI01, Agent Goal Hijack?

OWASP describes attackers who "manipulate an agent's objectives, task selection, or decision pathways" through injected text, deceptive tool output or poisoned data. Its own position is that agents "cannot reliably distinguish legitimate instructions from attacker-controlled content".

So the code-level control is not a better filter. It is making sure a hijacked goal cannot turn into a consequential call. OWASP's second and fourth mitigations say the same: least privilege for tools, human approval for high-impact actions, and a policy engine that validates intent before execution.

Anlyon: contains the damage, and does not detect the hijack. A hijacked agent can still only name actions that exist. Each call is checked against policies the agent's key cannot read or change, and against a limit the agent cannot raise. No model reliably detects every prompt injection, and Anlyon does not claim to.

How do you mitigate ASI02, Tool Misuse and Exploitation?

This is the entry closest to OWASP LLM06:2025 Excessive Agency. The agent uses a legitimate tool in an unsafe way: deleting data, calling a costly API in a loop, or the OWASP example of a support bot that "also issues refunds because the tool had full financial API access". The listed mitigations are least-privilege tool profiles, action-level approval with a dry-run preview, a pre-execution policy enforcement point, and usage ceilings.

In code, that is four things: a tool that does one operation, an argument schema, a policy evaluated on every call, and a ceiling on the total. With Anlyon the setup runs once, from a deploy step, with an operator key:

import { Client } from '@anlyonhq/sdk';

const ops = new Client({ apiKey: process.env.ANLYON_OPERATOR_KEY! });

// The credential lives in the vault, bound to one host.
await ops.secrets.put('STRIPE_KEY', {
  value: process.env.STRIPE_KEY!,
  allowedHosts: ['api.stripe.com'],
});

// One operation, one account, one currency. Gated by default.
await ops.actions.create({
  name: 'refund',
  requiresApproval: true,
  adapter: {
    type: 'stripe.refund',
    config: { account: 'acct_1Nxyz', mode: 'live', currency: 'usd' },
    credentialSecret: 'STRIPE_KEY',
  },
});

// Refunds up to $25 run without a prompt. A policy must name the action to lower its gate.
await ops.approvalPolicies.create({
  name: 'small-refunds-run',
  matchKind: 'action',
  matchActionName: 'refund',
  condition: 'input.amount <= 2500',
  effect: 'auto_approve',
});

// One daily ceiling that every agent, session and key in this environment draws from.
await ops.impactLimits.create({
  name: 'Refunds per day', dimension: 'money', currency: 'usd', period: 'day', amount: 50_000,
});

The agent's process holds a different key that can invoke and cannot read the vault, change policy or raise the limit:

const agent = new Client({ apiKey: process.env.ANLYON_AGENT_KEY! });

const { data } = await agent.actions.invoke('refund', {
  paymentIntent: 'pi_3Pabc',
  amount: 1250,
  currency: 'usd',
});
// data.status: succeeded, pending_approval, failed, unknown ...

Anlyon: yes, for routed actions. The limit is reserved before dispatch, so a planner stuck in a loop is refused once the day's allowance is used. A larger refund parks for a person, who sees a preview of the exact request. Every governed call returns a receipt with a grade. Limits count governed actions, meaning an action with an adapter or a declaration. A plain HTTP action with neither is not bounded by a limit. See Impact limits and tool permissions.

How do you mitigate ASI03, Identity and Privilege Abuse?

OWASP's description centres on agents that inherit or cache credentials, confused-deputy chains between agents, and a time-of-check to time-of-use gap: "Permissions may be validated at the start of a workflow but change or expire before execution." Its mitigations include task-scoped permissions, per-action authorization, and human approval for privilege escalation.

The code-level control has three parts. The credential never enters the agent's context. The identity that asks is not the identity that approves. Authorization is checked again at the moment of use, not only at the start.

Anlyon: yes, with limits. The model never sees a credential: an action references {{secret:NAME}} and Anlyon resolves it at dispatch. The secret is bound to a destination and a placement and checked again at fire time. The credential that requested an approval can never be the one that decides it. For a governed action, Anlyon re-checks the policy, the halt switch, the requesting key, the credential binding and the remaining limit at dispatch, so an approval given an hour ago does not carry a revoked key or an exhausted limit through.

What it does not do: Anlyon does not narrow a provider key. What the key allows at the provider is what an action using it can do, inside the limits and approvals set. It does not mint short-lived tokens per task, and a connection belongs to a workspace environment, not to a specific end user. The vault covers credentials stored in it, not a key your process already holds. See secrets management for agents.

How do you mitigate ASI04, Agentic Supply Chain Vulnerabilities?

The risk is tools, MCP servers, prompts and peer agents that are malicious or tampered with. OWASP cites a malicious MCP server on npm that impersonated a legitimate one and copied emails to an attacker. Its mitigations start with provenance, allowlists and pinning "by content hash and commit ID".

In code, stop resolving tools by name at run time. Pin the exact version of every MCP server your agent starts, and install from a lockfile:

{
  "mcpServers": {
    "billing": { "command": "npx", "args": ["-y", "@acme/billing-mcp@1.4.2"] }
  }
}

Run npm ci rather than npm install in the image that hosts the agent, so a changed lockfile fails the build instead of pulling a new version.

Anlyon: no. It does not scan or attest MCP servers, packages or prompts. One adjacent property: an action definition is versioned, an agent version pins the definitions it uses, and rolling back repoints the agent at an earlier version. That restores definitions for later calls. It does not undo a call already made.

How do you mitigate ASI05, Unexpected Code Execution (RCE)?

Agents that write and run code can be steered into running an attacker's code. OWASP's mitigations: "Ban eval in production agents", never run as root, sandbox with network limits, and separate code generation from execution.

docker run --rm --network none --read-only --user 65534:65534 \
  --cap-drop ALL --memory 256m --pids-limit 64 \
  -v "$PWD/job:/work:ro" agent-runner:2026-10 python /work/task.py

Anlyon: no. Anlyon does not run your agent or its code. One indirect benefit holds only if it is true of your deployment: code that escapes into the agent's process finds an Anlyon key that can invoke actions, not the Stripe or GitHub key itself. That holds while no other copy of the provider key is in that process.

How do you mitigate ASI06, Memory & Context Poisoning?

Here an attacker seeds memory, summaries or a vector store so that later reasoning goes wrong. OWASP's mitigations: validate memory writes, segment by user and tenant, require source attribution, expire unverified entries, and prevent "automatic re-ingestion of an agent's own generated outputs into trusted memory".

In code, every memory write carries its source, tenant and expiry, and retrieval filters on them:

type MemoryEntry = {
  text: string;
  tenant: string;
  source: 'user' | 'tool' | 'web' | 'agent';
  verified: boolean;
  expiresAt: number;
};

const usable = (e: MemoryEntry, tenant: string, now: number) =>
  e.tenant === tenant && e.source !== 'agent' && (e.verified || e.expiresAt > now);

Anlyon: no. It does not store, filter or validate agent memory. What it bounds is the consequence: a poisoned memory that convinces the agent to refund the wrong order still meets the same policy and limit as any other call.

How do you mitigate ASI07, Insecure Inter-Agent Communication?

Messages between agents that are not authenticated can be spoofed, altered or replayed. OWASP asks for mutual authentication, signed messages, and anti-replay with "nonces, session identifiers, and timestamps tied to task windows".

import { createHmac, timingSafeEqual } from 'node:crypto';

type AgentMessage = { body: string; ts: number; nonce: string; sig: string };

export function accept(m: AgentMessage, key: Buffer, seen: Set<string>): boolean {
  if (Math.abs(Date.now() - m.ts) > 60_000 || seen.has(m.nonce)) return false;
  const expected = createHmac('sha256', key).update(`${m.ts}.${m.nonce}.${m.body}`).digest();
  const given = Buffer.from(m.sig, 'hex');
  if (given.length !== expected.length || !timingSafeEqual(given, expected)) return false;
  seen.add(m.nonce);
  return true;
}

Anlyon: no. It does not carry or sign messages between your agents. When a second agent asks for an action, that request still meets the action's policies and approval floor, and it draws from the same limit as the first agent's, because a limit is keyed on the environment and the action, not on which agent is asking.

How do you mitigate ASI08, Cascading Failures?

One bad decision fans out across agents, retries and queues. OWASP's mitigations include "Independent policy enforcement: Separate planning and execution via an external policy engine", rate limiting, and "blast-radius guardrails such as quotas, progress caps, circuit breakers between planner and executor".

Anlyon: yes, for routed actions. A limit is keyed on things the server controls: the environment, the dimension, an optional action and resource prefix, and a period. A new session, a new API key or a child agent does not get a new allowance, so ten agents in a loop draw from the same pool as one. Anlyon does not retry an action invocation. Where a request may have reached the destination and the outcome cannot be confirmed, the invocation is recorded as unknown and you reconcile before retrying, which stops a timeout from becoming a second refund. The halt switch, below, is the circuit breaker. See shared allowances.

How do you mitigate ASI09, Human-Agent Trust Exploitation?

The agent persuades the human. OWASP lists fake explainability, "consent laundering through 'read-only' previews" that trigger side effects on open, and asks for a "plain-language risk summary (not model-generated rationales)" and to "separate preview from effect".

In code, the approval screen renders the request that will be sent, field by field. It never renders the agent's explanation as the thing being approved.

Anlyon: partly. An approval of a governed action is bound to a preview: the exact normalized request, the target, the versions, the preconditions and an expiry. A preview is typed data, never provider HTML, and building one writes nothing. Anlyon recomputes a digest of it before dispatch and refuses on any difference. A policy can require N distinct approvers, counted as distinct credentials for API-key deciders and distinct users for dashboard deciders. What it does not do is detect a persuasive rationale, or make a reviewer read. See binding approval to the executed action.

How do you mitigate ASI10, Rogue Agents?

An agent drifts from its intended function and keeps acting. OWASP's containment mitigation: "kill-switches and credential revocation to instantly disable rogue agents", plus behavioural monitoring and attestation.

const operator = new Client({ apiKey: process.env.ANLYON_OPERATOR_KEY! }); // holds environments:halt
await operator.environment.halt({ reason: 'refund loop on support agent' });

Anlyon: partly. Halting stops the agent acting and stops anything leaving the environment. It stops new dispatch: a request an external server already accepted is not recalled. Revoking an agent's key refuses its pending dispatches. Rolling back repoints the agent at an earlier version of its action definitions. Anlyon does not watch behaviour for drift or attest agent identity. See the AI agent kill switch.

What does OWASP ask for that Anlyon does not provide?

Several mitigations across ASI02, ASI08, ASI09 and ASI10 ask for immutable, tamper-evident or signed logs. Anlyon keeps durable records of every decision, with export and retention you configure. Those records are database rows with provider evidence. They are not tamper-evident and not signed, and if your threat model needs that, export them into a store that provides it.

The rest of the gap is in the table: supply chain, code execution, memory and inter-agent messaging are controls you build in the agent's own runtime. An execution layer narrows what a failure in any of them can do. It does not prevent the failure.

Is the agentic Top 10 the same as the LLM Top 10?

No. The OWASP Top 10 for LLM Applications 2025 covers single model interactions, with entries such as LLM01:2025 Prompt Injection and LLM06:2025 Excessive Agency. The agentic list extends it to agents that plan, use tools, keep memory and delegate, and each ASI entry names the LLM entries it builds on. OWASP's document also introduces "Least-Agency": avoid giving an agent autonomy it does not need, because each unneeded capability widens the attack surface.

If you are mapping your own agent against this list, start with the two rows where the damage happens: ASI02 and ASI03. Read the approvals and policies docs or start building. Free tier, no credit card.