OWASP Agentic Top 10 Checklist:
The Complete Pre-Production Audit

How to Use This Checklist

Not every item applies with equal force to every agent. A read-only research assistant with no write access and no financial authority doesn't need the same rigor as an agent that can approve transactions or modify infrastructure. Use this checklist as a completeness tool, not a uniform gate — work through the categories relevant to your agent's actual capabilities, and treat unchecked items as genuine, named gaps rather than something to silently skip. If your organization can't confidently check most items in a category, that category is a real, current exposure, not a theoretical one.

The companion piece to this checklist is the OWASP Agentic Top 10 Technical Guide, which explains the reasoning, real incidents, and full attack scenarios behind each category. This document is deliberately the opposite — dense, itemized, and built for working through directly rather than reading start to finish.

ASI01 — Agent Goal Hijack

• Are all natural-language inputs — user text, uploaded documents, retrieved content — routed through the same prompt-injection safeguards before they can influence goal selection, planning, or tool calls?
• Is least privilege enforced on every tool the agent has access to, specifically to limit the blast radius if a goal is hijacked?
• Does any goal-changing or high-impact action require human approval, not just the agent's own judgment?
• Are the agent's system-level objectives explicitly locked and audited, with any change to goals or reward definitions going through configuration management and human approval?
• At runtime, is both user intent and agent intent validated before executing a goal-changing or high-impact action?
• Are connected data sources — RAG inputs, emails, calendar invites, uploaded files, peer-agent messages — sanitized and validated before they can influence agent goals?
• Is there a behavioral baseline for the agent's goal state and tool-use patterns, with alerts on unexpected goal changes or anomalous sequences?
• Have you run periodic red-team tests specifically simulating goal override, and verified rollback actually works?

ASI02 — Tool Misuse and Exploitation

• Does every tool have a defined, per-tool least-privilege profile — scope, maximum rate, egress allowlist — rather than broad, ambient access?
• Is explicit authentication required for each tool invocation, with human confirmation for high-impact or destructive actions specifically?
• Is a pre-execution plan or dry-run diff shown before high-impact actions are actually approved?
• Does tool or code execution run in isolated sandboxes, with outbound network access restricted to an approved allowlist?
• Is there a pre-execution policy enforcement point that validates intent and arguments before a tool call executes, rather than trusting the planner's output directly?
• Are usage ceilings — cost, rate, or token budgets — enforced with automatic throttling or revocation when exceeded?
• Are credentials issued just-in-time and ephemeral, expiring immediately after use, rather than standing access?
• Are tool names fully qualified and version-pinned, to prevent alias collisions or typosquatted tool names from being resolved by mistake?
• Are tool invocations logged immutably, with monitoring for unusual chaining patterns — such as a database read immediately followed by an external transfer?

ASI03 — Identity and Privilege Abuse

• Are short-lived, narrowly scoped tokens issued per task, with rights capped by explicit permission boundaries?
• Does each agent run in a per-session sandbox with separated permissions and memory, wiped clean between tasks?
• Is each privileged step re-verified against a centralized policy engine at execution time, rather than relying on an authorization check performed earlier in the workflow?
• Is human approval required for high-privilege or irreversible actions specifically, as a safety net independent of the automated checks?
• Are OAuth tokens bound to a signed intent — subject, audience, purpose, session — with any mismatched use rejected outright?
• Is your organization using (or evaluating) an agentic identity management platform that treats agents as managed non-human identities with scoped credentials, audit trails, and lifecycle controls?
• Is re-authentication required on context switch, with privilege inheritance across agents blocked unless the original intent is re-validated?
• Do you actively monitor for delegated and transitive permissions — cases where an agent gains access indirectly through a delegation chain, not through a direct grant?

ASI04 — Agentic Supply Chain Vulnerabilities

• Are manifests, prompts, and tool definitions signed and attested, with SBOMs and AIBOMs maintained and periodically re-attested?
• Is there a curated, allowlisted registry for dependencies, with untrusted sources actively blocked?
• Are dependencies pinned and scanned for typosquats across every ecosystem you actually use (PyPI, npm, LangChain, LlamaIndex, etc.)?
• Do sensitive agents run in sandboxed containers with strict network and syscall limits, using reproducible builds?
• Are prompts, orchestration scripts, and memory schemas under version control with peer review, scanned for anomalies?
• Is mutual authentication and attestation (PKI, mTLS) enforced for inter-agent communication, with no open registration?
• Are signatures, hashes, and SBOMs re-checked at runtime, not just at initial install?
• Is there a genuine emergency revocation mechanism that can instantly disable a specific tool, prompt, or agent connection across every deployment the moment a compromise is detected?

ASI05 — Unexpected Code Execution (RCE)

• Is agent-generated code run through the same input-validation and output-encoding controls used elsewhere for injection risk?
• Is direct agent access to production systems prevented, with pre-production security evaluations and adversarial unit tests required first?
• Is eval banned in production agents, with safe interpreters and taint-tracking required instead?
• Does generated code ever run as root? (It shouldn't — sandboxed containers with strict, minimal limits should be the default.)
• Is filesystem access restricted to a dedicated working directory, with file diffs logged for critical paths?
• Is code generation separated from execution by an actual validation gate, not just a convention or instruction?
• Is human approval required for elevated runs, with an allowlist under version control for anything permitted to auto-execute?
• Are static scans run before execution, with runtime monitoring watching for prompt-injection patterns during the run itself?

ASI06 — Memory & Context Poisoning

• Is memory encrypted in transit and at rest, with least-privilege access enforced on who and what can read it?
• Are all new memory writes and model outputs scanned for malicious or sensitive content before being committed?
• Is memory segmented by user session and domain context, to prevent knowledge and sensitive data from leaking across boundaries?
• Are only authenticated, curated sources allowed to write into memory, with retention minimized based on data sensitivity?
• Is source attribution required for memory entries, with suspicious update patterns or frequencies actively detected?
• Is automatic re-ingestion of an agent's own generated output into its own trusted memory specifically prevented, to avoid self-reinforcing "bootstrap poisoning"?
• Do you have snapshots, rollback, and version control for memory, with human review required for high-risk actions influenced by stored context?
• Does unverified memory actually expire over time, rather than persisting indefinitely by default?

ASI07 — Insecure Inter-Agent Communication

• Is end-to-end encryption with per-agent credentials and mutual authentication used for every inter-agent channel — not implicit trust based on being "internal"?
• Are messages digitally signed, with payload and context both hashed and validated for hidden or modified instructions?
• Are exchanges protected against replay with nonces, session identifiers, and timestamps tied to specific task windows?
• Are weak or legacy communication modes actually disabled, with protocol version and capability policies enforced at gateways?
• Are allowed protocol versions (MCP, A2A, gRPC, etc.) explicitly defined and enforced, with downgrade attempts rejected outright?
• Are discovery and coordination messages authenticated using cryptographic identity, with directories access-controlled and reputations verified?
• Are agent cards / descriptors required to be signed and attested, with continuous verification before accepting discovery or coordination messages from a peer?
• Do message schemas use versioned, typed contracts with explicit per-message audiences, rejecting anything that fails validation?

ASI08 — Cascading Failures

• Is the system designed with zero-trust assumptions — assuming any single component can fail or be compromised, not just the ones you expect?
• Are agents sandboxed with network segmentation, least privilege, and mutual authentication specifically to contain propagation, not just individual compromise?
• Are short-lived, task-scoped credentials issued per agent run, with every high-impact tool invocation validated against a policy-as-code rule before executing?
• Is planning separated from execution through an independent policy engine, so a corrupted planner can't directly trigger harmful downstream action?
• Are there real checkpoints, governance agents, or human review gates for high-risk outputs before they propagate further downstream?
• Is fast-spreading activity actually detected and throttled — rate limiting genuinely in place, not just planned?
• Are blast-radius guardrails — quotas, progress caps, circuit breakers between planner and executor — actually implemented?
• Is there a behavioral and governance drift baseline being tracked, with alerts on gradual degradation over time?
• Are all inter-agent messages, policy decisions, and execution outcomes logged in tamper-evident, time-stamped records bound to cryptographic agent identities?

ASI09 — Human-Agent Trust Exploitation

• Is multi-step approval or human-in-the-loop confirmation required before the agent accesses especially sensitive data or performs a risky action?
• Are tamper-proof, immutable logs kept of user queries and agent actions for audit and forensics?
• Is behavioral monitoring in place for sensitive data exposure in conversations or agentic connections over time, not just at the point of action?
• Can users flag suspicious or manipulative agent behavior directly, triggering automated review or a temporary capability lockdown?
• Does agent autonomy and required oversight adjust based on contextual risk scoring, with low-confidence or unverified-source cues visibly flagged to the human reviewer?
• Do all recommendations and external data carry verifiable metadata — source identifiers, timestamps, integrity hashes — with actions lacking trusted provenance actually blocked?
• Is "preview" mode for an action genuinely read-only — no network calls or state changes triggered just by opening a preview?
• Are high-risk recommendations visually distinguished (warning colors, banners, explicit confirmation prompts), rather than presented identically to routine ones?

ASI10 — Rogue Agents

• Are comprehensive, immutable, and signed audit logs kept of all agent actions, tool calls, and inter-agent communication?
• Are agents assigned to trust zones with strict inter-zone communication rules, running in restricted execution environments scoped to least privilege?
• Is behavioral detection deployed — watchdog agents or equivalent — specifically to validate peer behavior and catch coordinated false signals?
• Do you have a genuine, tested kill-switch and credential-revocation mechanism to instantly disable a rogue agent, not just a theoretical plan?
• Can suspicious agents be quarantined in a sandboxed environment for forensic review, rather than only removed outright?
• Does each agent carry a signed behavioral manifest — its expected capabilities, tools, and goals — validated by orchestration before every action?
• Are per-run ephemeral credentials used with one-time audience binding, with signing keys mediated by an orchestrator rather than directly available to the agent itself?
• Before reintegrating a quarantined or remediated agent into production, is fresh attestation, dependency verification, and human approval genuinely required?

Scaling This Checklist to Your Agent's Actual Risk Profile

An agent that scores well on this checklist for its own tier isn't automatically "safe" — it's demonstrably addressed the risks that actually apply to what it can do. Re-run this checklist whenever an agent's tools, permissions, or connected agents change; a "safe" configuration from six months ago can silently drift into a genuinely different risk profile.

Frequently Asked Questions

Related Reading