65 controls for running AI agents in production, mapped to the OWASP Top 10 for LLM Applications (2025), the OWASP Top 10 for Agentic Applications (2026) and the NIST AI Risk Management Framework.
AI agent security is the set of controls that limit what an AI agent can see, disclose and do in the systems it connects to. An agent reads company systems and acts on them, so its risks include harmful actions as well as data leaks.
This enterprise AI agent security checklist covers both parts. Most of the depth goes to actions, because actions are where agent risk differs from chatbot risk.
The first pass belongs before an agent reaches production. A new tool, a new data source or a step up in autonomy each calls for another pass, since any of them changes what the agent can reach or do. Our guide to enterprise AI agents covers the architecture and rollout decisions behind these controls.
How to use this checklist
- Mark each control Yes, Partial, or No.
- Mark 8.4 N/A for single-tenant systems. In the scoring rows, N/A on 8.4 counts as Yes.
- Each control has a tier:
- T1, required for any production agent.
- T2, required once the agent can write, send, pay, or change records.
- T3, required in regulated environments (finance, health, public sector) or for fully autonomous agents.
- Ship rule: Every T1 at Yes. Every T2 at Yes if the agent can write, send, pay or change records. In regulated environments or for fully autonomous agents, every T3 at Yes or covered by a written, owner-signed exception. Partial counts as No.
Mapping keys
- OWASP LLM: OWASP Top 10 for LLM Applications (2025):
- LLM01 Prompt Injection
- LLM02 Sensitive Information Disclosure
- LLM03 Supply Chain
- LLM04 Data and Model Poisoning
- LLM05 Improper Output Handling
- LLM06 Excessive Agency
- LLM07 System Prompt Leakage
- LLM08 Vector and Embedding Weaknesses
- LLM09 Misinformation
- LLM10 Unbounded Consumption
- OWASP Agentic: OWASP Top 10 for Agentic Applications (2026):
- ASI01 Agent Goal Hijack
- ASI02 Tool Misuse & Exploitation
- ASI03 Identity & Privilege Abuse
- ASI04 Agentic Supply Chain Vulnerabilities
- ASI05 Unexpected Code Execution
- ASI06 Memory & Context Poisoning
- ASI07 Insecure Inter-Agent Communication
- ASI08 Cascading Failures
- ASI09 Human-Agent Trust Exploitation
- ASI10 Rogue Agents
- NIST AI RMF functions: GOVERN, MAP, MEASURE, MANAGE.
An ASI ID appears only where the control directly addresses the named risk. No control in this list maps to ASI07. The checklist is written for a single agent. Multi-agent systems, where agents send messages to other agents, need further agentic AI security controls for those messages.
1. Identity and access
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 1.1 | The agent has its own service identity. It never runs on a human user's personal credentials. | T1 | LLM06 | ASI03 | MANAGE |
| 1.2 | When the agent acts for a user (on-behalf-of or delegated auth), its rights are the overlap of the user's permissions and the agent's tool scope. | T1 | LLM06 | ASI03 | MANAGE |
| 1.3 | Credentials live in a secrets manager and are injected at call time. No keys in prompts, code, or config files. | T1 | LLM02, LLM07 | ASI03 | MANAGE |
| 1.4 | Tokens are short-lived and scoped per tool, not one master key for everything. | T2 | LLM06 | ASI03 | MANAGE |
| 1.5 | Agent identities show up in your IAM reviews like any other service account. | T2 | — | ASI03 | GOVERN |
2. AI agent permissions, tools and guardrails
Each tool an agent holds widens what it can reach or change. Amount caps and recipient allow-lists (2.6) are AI agent guardrails, and they live in code outside the model, out of reach of injected text. An MCP server is one more tool. MCP security therefore starts with the rest of sections 2 and 3, and control 2.8 adds a review before use and a pinned version.
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 2.1 | There is a written inventory of every tool the agent can call, with an owner for each. | T1 | LLM06 | — | GOVERN |
| 2.2 | Each tool exposes the narrowest function needed (e.g. create_draft_invoice, not run_sql). |
T1 | LLM06 | ASI02 | MANAGE |
| 2.3 | Read and write tools are separate. A read-only agent has no write tools loaded at all. | T1 | LLM06 | ASI02 | MANAGE |
| 2.4 | Tool inputs are validated against a schema on the server side, not only described in the prompt. | T1 | LLM05, LLM06 | ASI02 | MANAGE |
| 2.5 | High-impact tools (payments, deletes, external email, permission changes) need human approval. See section 6. | T2 | LLM06 | ASI02 | MANAGE |
| 2.6 | Hard limits sit outside the model: amount caps, recipient allow-lists, record-count limits per call. | T2 | LLM06 | ASI02 | MANAGE |
| 2.7 | Destructive actions are reversible where possible (soft delete, drafts, staged changes). | T2 | LLM06 | — | MANAGE |
| 2.8 | Third-party tools and MCP servers are reviewed before use and pinned to known versions. | T2 | LLM03 | ASI04 | GOVERN |
3. Prompt injection and untrusted input
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 3.1 | Every input source is labelled trusted or untrusted. Emails, web pages, uploaded files, tickets, and tool results count as untrusted. | T1 | LLM01 | ASI01 | MAP |
| 3.2 | Untrusted content is passed to the model as data, clearly delimited, and never merged into system instructions. This reduces injection; it does not prevent it. 3.3 and 3.5 are the controls. | T1 | LLM01 | ASI01 | MANAGE |
| 3.3 | An agent that reads untrusted content cannot also take high-impact actions in the same run without approval. | T2 | LLM01, LLM06 | ASI01, ASI02 | MANAGE |
| 3.4 | Indirect injection is tested: hidden instructions in documents, web pages, file names, and image text. | T1 | LLM01 | ASI01 | MEASURE |
| 3.5 | Security never relies on "the system prompt tells it not to". Controls are enforced in code and permissions. | T1 | LLM01, LLM07 | ASI01 | MANAGE |
| 3.6 | The system prompt holds no secrets, and leaking it would not cause harm. | T1 | LLM07 | — | MANAGE |
4. Data protection
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 4.1 | Data the agent can reach is classified, and the agent's scope matches the use case. | T1 | LLM02 | — | MAP |
| 4.2 | PII and secrets are masked or tokenized before reaching the model where the task allows. | T2 | LLM02 | — | MANAGE |
| 4.3 | The model provider's data retention and training terms are confirmed in writing. | T1 | LLM02, LLM03 | — | GOVERN |
| 4.4 | Data residency requirements are met for the model endpoint, vector store, and logs. | T3 | — | — | GOVERN |
| 4.5 | Agent memory and conversation history are scoped per user or tenant. Nothing leaks across users or tenants. | T1 | LLM02 | ASI06 | MANAGE |
| 4.6 | Logs that contain prompts and outputs are protected like the data inside them. | T1 | LLM02 | — | MANAGE |
5. Output handling
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 5.1 | Model output is never executed or rendered directly. Code runs only in a sandbox, SQL is parameterized, HTML is encoded. | T1 | LLM05 | ASI05 | MANAGE |
| 5.2 | Structured outputs are validated against a schema before anything acts on them. | T1 | LLM05 | — | MANAGE |
| 5.3 | Links, emails, and messages the agent produces are checked for data exfiltration (e.g. sensitive data in URLs). | T1 | LLM02, LLM05 | — | MANAGE |
| 5.4 | Factual or numeric outputs that drive decisions are checked against a source of record. | T2 | LLM09 | — | MANAGE |
| 5.5 | Users can see when content was generated or an action was taken by an agent. | T2 | LLM09 | — | GOVERN |
6. Human in the loop: autonomy and approval
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 6.1 | Every action is assigned a risk tier: observe, suggest, act with approval, act alone. | T1 | LLM06 | — | MAP |
| 6.2 | The approval screen shows exactly what will happen (recipient, amount, records) and not only the agent's summary. | T2 | LLM06, LLM09 | ASI09 | MANAGE |
| 6.3 | Approvers are named roles, and the agent cannot approve its own requests. | T2 | LLM06 | — | GOVERN |
| 6.4 | Autonomy for an action type goes up only after measured results at the level below: a set number of decisions, an approval rate the owner sets, and a review of every rejection and edit. | T2 | LLM06 | — | MEASURE, GOVERN |
| 6.5 | A kill switch stops the agent, revokes its tokens, and stops queued and in-flight runs in one step. It has been tested. | T1 | LLM06 | ASI10 | MANAGE |
7. Models and AI agent supply chain security
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 7.1 | Model, version, and provider are recorded for every deployment. | T1 | LLM03 | ASI04 | GOVERN |
| 7.2 | Model upgrades go through the same evaluation suite as code changes before release. | T2 | LLM03, LLM09 | — | MEASURE |
| 7.3 | Open-weight models and libraries come from verified sources, with integrity checks. | T2 | LLM03, LLM04 | ASI04 | MANAGE |
| 7.4 | Fine-tuning data is reviewed and access-controlled. | T3 | LLM04 | — | MANAGE |
| 7.5 | There is a fallback plan if the provider changes its terms or retires the model version in use. | T2 | LLM03 | — | GOVERN |
8. RAG security: retrieval and knowledge bases
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 8.1 | Retrieval enforces the asking user's document permissions at query time. | T1 | LLM08, LLM02 | ASI03 | MANAGE |
| 8.2 | Write access to the knowledge base is controlled, since anything indexed can steer the agent. | T1 | LLM04, LLM08 | ASI06 | MANAGE |
| 8.3 | Sources are tracked, so every answer can cite which documents it used. | T2 | LLM09 | — | MEASURE |
| 8.4 | Tenant isolation is enforced by the retrieval service: a separate index or namespace, or a tenant filter set by application code that the model cannot change. | T1 (if multi-tenant) | LLM08 | — | MANAGE |
| 8.5 | Deletions and permission changes reach the index when they happen, with a scheduled check to catch misses. | T2 | LLM08, LLM09 | — | MANAGE |
9. Logging, monitoring, and audit
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 9.1 | Every run logs inputs, retrieved context IDs, tool calls with arguments, approvals, and outputs, with the masking from 4.2 applied. | T1 | — | — | MEASURE |
| 9.2 | Logs are tamper-evident and kept for the retention period your regulators require. | T3 | — | — | GOVERN |
| 9.3 | Alerts fire on unusual patterns: tool-call spikes, new recipients, repeated refusals, approval bypass attempts. | T2 | LLM01, LLM06, LLM10 | ASI10 | MEASURE |
| 9.4 | Any action can be traced back to the run, the user, and the approver. | T2 | — | — | GOVERN |
10. Cost and resource limits
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 10.1 | There are per-run limits on steps, tool calls, and tokens. | T1 | LLM10 | — | MANAGE |
| 10.2 | Per-user and per-day spend caps stop the agent at the limit and alert at a lower threshold. | T1 | LLM10 | — | MANAGE |
| 10.3 | Loops are detected (the same tool with the same arguments repeated) and the run stops. | T2 | LLM10 | — | MANAGE |
| 10.4 | Rate limits protect downstream systems from the agent. | T2 | LLM06, LLM10 | ASI08 | MANAGE |
11. Testing and red teaming
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 11.1 | An evaluation set of real tasks, with expected outcomes, runs before every release. | T1 | LLM09 | — | MEASURE |
| 11.2 | The adversarial test set covers direct and indirect injection, data exfiltration, and tool misuse. | T2 | LLM01, LLM06 | ASI01, ASI02 | MEASURE |
| 11.3 | Red-team results are tracked to closure like security bugs. | T2 | — | — | MANAGE |
| 11.4 | A third-party or internal independent review is done before the first production launch. | T3 | — | — | GOVERN |
12. Security incident response for AI agents
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 12.1 | Your incident runbook includes agent scenarios: injection, wrong action at scale, data leak. | T2 | — | — | MANAGE |
| 12.2 | You can list every action in a time window, and reverse or compensate the ones that can be. | T2 | LLM06 | — | MANAGE |
| 12.3 | You know who to notify (security, legal, data protection officer, customers) and when. | T2 | — | — | GOVERN |
13. AI agent governance
The controls in this section attach names and records to each agent, and together they form a short AI governance checklist. Control 13.1 names a business owner and a technical owner. The register in 13.2 records what the agent is for and what it can touch, and 13.3 sets the condition for switching it off. Regulated uses also need legal sign-off (13.4). After any new tool, data source or autonomy increase, the agent goes back through this whole checklist (13.5).
| # | Control | Tier | OWASP LLM | OWASP Agentic | NIST |
|---|---|---|---|---|---|
| 13.1 | Every agent has a named business owner and a named technical owner. | T1 | — | — | GOVERN |
| 13.2 | The use case, data, tools, and autonomy level are documented in an agent register. | T1 | LLM06 | — | GOVERN |
| 13.3 | There are success metrics and a stop condition (when to switch the agent off). | T2 | LLM09 | — | MEASURE, MANAGE |
| 13.4 | Legal and compliance have signed off on regulated use cases (EU AI Act risk class, sector rules). | T3 | — | — | GOVERN |
| 13.5 | The checklist is re-run on every new tool, data source, or autonomy increase. | T1 | — | — | GOVERN |
Scoring
The first row that fits your agent, reading from the top, is its result. Any Partial answer is scored as No here, as it is in the ship rule.
| Result | What it means |
|---|---|
| Any T1 not at Yes | Not ready for production. |
| Regulated or fully autonomous | All T1 at Yes, all T2 at Yes if the agent acts, and every T3 at Yes or covered by a written, owner-signed exception: ready for production. Otherwise not ready. |
| All T1 at Yes, agent reads or suggests only, not regulated | Ready for production as a read/suggest agent. |
| All T1 at Yes, agent takes actions, any T2 not at Yes | Suggest-only pilot until the T2 gaps close. |
| All T1 and T2 at Yes, not regulated, not fully autonomous | Ready for production with approval gates. |
Five gaps to check first
- One API key with full access, shared by every tool (1.3, 1.4). If that key leaks or is misused, every system it can reach is exposed.
- Security that lives only in the system prompt (3.5). A prompt instruction is text, and injected text can override it.
- Agents that read inbound email and can also send email, with no approval in between (3.3). One malicious email can instruct the agent to send data out.
- RAG that ignores document permissions (8.1). Users can read documents through the agent that they could not open directly.
- No step or spend limits, so one loop keeps calling tools until a person notices (10.1–10.3). Each pass through the loop costs money, and if the call writes data, each pass also changes records.
Frequently asked questions
What are the main AI agent security risks and vulnerabilities?
An agent can leak data, as a chatbot can, and it can also take harmful actions with the tools it holds. Where a control addresses a named OWASP agentic risk, the OWASP Agentic column gives its ID; no control here covers ASI07, inter-agent communication. The five gaps above are the vulnerabilities to check first. Two of them are one shared API key (1.3, 1.4) and RAG that ignores document permissions (8.1).
How do you secure AI agents?
Securing AI agents follows the tiers on this page. The T1 controls come first, because no agent should reach production without them, read-only agents included. Once the agent can act on records, money or messages, the T2 controls come next, and the T3 controls follow for regulated or fully autonomous agents. After launch, the checklist runs again with each new tool, data source or step up in autonomy (13.5).
What are enterprise AI agent security best practices?
An agent runs under its own service identity, never a person's credentials (1.1), and each tool does one narrow job, such as drafting an invoice instead of running raw SQL (2.2). Caps and allow-lists sit in code outside the model, because injected text can override a prompt instruction (2.6, 3.5). Payments, deletes and other high-impact actions wait for a human approver (2.5). Every run leaves a log of its inputs, tool calls and approvals (9.1), and the kill switch has been tested (6.5).
What is the OWASP Top 10 for Agentic Applications?
It is the OWASP GenAI Security Project's list of ten security risks for agentic applications, published on 9 December 2025. The IDs run from ASI01 Agent Goal Hijack to ASI10 Rogue Agents, and the mapping keys above list all ten. Each control in this checklist names the ASI ID it directly addresses, where one applies.
About the author
Aamir Tauqir has been a full-stack developer since September 2016. Since January 2022 he has been Co-Founder & CTO of Vortex Web Innovate, where he leads product and engineering. He leads technical discovery and the written architecture assessment for every engagement, oversees the LLM, retrieval and agent work, and owns security, launch and ongoing reliability.
Next step
For the architecture, autonomy model, and rollout plan behind these controls, read Enterprise AI Agents: Use Cases, Architecture, Security & Implementation.
We build production AI agents. See our AI solutions, or contact us.
Free to copy and adapt, including in public documents, with a link back to this page.
References
- OWASP Top 10 for LLM Applications 2025: https://genai.owasp.org/llm-top-10/
- OWASP Top 10 for Agentic Applications for 2026 (published 9 December 2025): https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications/
- OWASP GenAI Security Project, announcement listing ASI01 to ASI10: https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
- OWASP AI Agent Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
- NIST AI Risk Management Framework (AI RMF 1.0): https://www.nist.gov/itl/ai-risk-management-framework
- OWASP GenAI Security Project, Agentic Security Initiative: https://genai.owasp.org/
