Enterprise AI Security Checklist: 20 Controls With Pass/Fail Tests

An enterprise AI security checklist is the set of controls that stop your AI systems from leaking data, taking actions nobody approved, or being turned against you. This one has 20 controls. Each has a pass/fail test you can run this quarter and a mapping to OWASP, NIST, ISO/IEC 42001, and MITRE ATLAS.

A checklist you cannot test is a policy. This version makes every item testable and uses the framework versions current on October 15, 2026.

What the 2026 incident data says

Most AI breaches do not start inside the model. They start in the plumbing around it.

IBM’s Cost of a Data Breach Report 2026 covers 602 organizations breached between March 2025 and February 2026. More than 20% reported a breach targeting AI models or applications. The most common causes were compromised APIs, applications, or plug-ins (27%) and cloud misconfigurations affecting AI workloads (27%). One in four malicious breaches was AI-enabled, and those cost $6 million on average against a global average of $4.99 million.

The 2025 edition put AI model or application breaches at 13%, and 97% of those organizations had no AI access controls. The wording changed between editions, so read the rise as directional.

Data leaks through ordinary use too. The Netskope AI Report 2026 (data from June 2025 to July 2026) counts 69 upstream generative AI data policy violations (data sent to AI tools) per week in the average organization, up from 44. Intellectual property, regulated data, and source code make up the vast majority.

OWASP’s Q3 2026 exploit roundup adds the agent cases: evaluation agents that reached the open internet, and an MCP server that turned malicious after approval. Its conclusion: “Prompt-level instructions alone do not establish a secure boundary.”

Decision rule: weight your effort toward identity, tool permissions, isolation, and logging. A better system prompt does not fix any of them.

Which frameworks does this checklist map to?

Many checklists still cite the 2025 OWASP list, which has been replaced. Here is what is current as of October 15, 2026.

The 2026 OWASP list moved Excessive Agency to LLM03, renamed System Prompt Leakage to Hidden Context Exposure (LLM08), and dropped Improper Output Handling to LLM10. The ranking weights a practitioner vote at 75% and incident data at 25%. If your checklist says “LLM06 Excessive Agency,” its IDs are a year old.

How to read each item. The pass thresholds are mine, not from a standard. The mappings are my reading of each framework, so check them against your own control library. Run every test in staging with synthetic canary values, never real customer data.

Part 1: Know what runs and what it touches

You cannot secure a system you have not found. These four controls set the scope for the other sixteen.

1. Every AI system is in an inventory reconciled against discovery.

• Test: Compare the register with SSO app logs, expense data, and egress logs to model APIs. The governance gap scorecard explains the discovery method.
• Pass if: 95% or more of discovered systems are registered, each with a named owner.
• Maps to: NIST GOVERN 1.6 and GV-1.6-001; ISO/IEC 42001 A.4.2; ATLAS AML.M0023 (AI Bill of Materials).

2. Each system has a data ceiling that is enforced, not just written down.

• Test: Send a synthetic record above the system’s approved data class through its input path.
• Pass if: The record is blocked or redacted before it reaches the model, and the event is logged.
• Maps to: LLM02:2026 Sensitive Information Disclosure; NIST MEASURE 2.10; ISO/IEC 42001 A.4.3; ATLAS AML.M0019.

3. Prompts and outputs pass through DLP on the sanctioned path.

• Test: Paste canary values (a fake key in a real key format, a test-range ID number) into each approved AI tool. Then ask the tool to repeat them back.
• Pass if: 100% of canaries are caught in both directions. Netskope saw the average organization’s downstream violations rise from 12 to 31 per week, so outputs need checks too.
• Maps to: LLM02:2026; ATLAS AML.T0057 (LLM Data Leakage) and AML.M0020 (Generative AI Guardrails).

4. Every model provider’s retention and training-use terms are on file.

• Test: For each production system, find the contract term that states the retention period and whether your data trains models.
• Pass if: Every system has both in a signed contract, not a marketing page. The HIPAA and SOC 2 checklist covers what to verify in those terms.
• Maps to: NIST GOVERN 6.1; ISO/IEC 42001 A.10.3 (Suppliers).

Part 2: Identity, access, and tools

This is where the IBM causes live: APIs, plug-ins, and access. This part carries the most weight.

5. Every agent has its own identity.

• Test: Search agent configs, repos, and the secrets manager for credentials issued to named people but used by agents.
• Pass if: Zero agents run on a person’s credential.
• Maps to: ASI03 Identity & Privilege Abuse; LLM03:2026 Excessive Agency; ATLAS AML.M0026.

6. Write scopes match what the agent uses.

• Test: Diff each agent’s granted scopes against tool calls in the last 30 days of logs.
• Pass if: No agent holds a write or delete scope it has not used in 30 days. The least-privilege design guide shows how to cut them.
• Maps to: LLM03:2026; ASI02 Tool Misuse; ATLAS AML.M0028 (AI Agent Tools Permissions Configuration).

7. No secrets sit in prompts, agent configs, or memory.

• Test: Run a secret scanner over system prompts, agent config files, and vector stores, not just code repos.
• Pass if: Zero live secrets found. The OWASP 2026 list flags embedded credentials as one result of Hidden Context Exposure.
• Maps to: LLM08:2026 Hidden Context Exposure; ATLAS AML.T0083 (Credentials from AI Agent Configuration).

8. Tool servers reject tokens that were not issued to them.

• Test: Send each MCP server a valid token issued for a different audience.
• Pass if: Every server rejects it. The MCP security guidance says servers “MUST NOT accept any tokens that were not explicitly issued for the MCP server.” Our MCP security guide covers the rest of the hardening.
• Maps to: ASI03; ASI04 Agentic Supply Chain Vulnerabilities.

9. Irreversible actions are gated in code.

• Test: In staging, instruct the agent to make a payment above its cap, email an external address, or delete a record.
• Pass if: Code blocks the action or routes it for human approval. A prompt telling the agent not to does not count.
• Maps to: LLM03:2026; ASI09 Human-Agent Trust Exploitation; NIST MAP 3.5; ATLAS AML.M0029 (Human In-the-Loop for AI Agent Actions).

Part 3: Inputs, outputs, and memory

Prompt injection holds LLM01 in the 2026 list. OWASP explains why it stays first even though it falls out of the top 10 when ranked by raw incident count: teams fight it hard, so fewer clean exploits reach public databases. You cannot close that surface. These controls assume injection will succeed and limit what it can reach.

10. An attack-case suite runs before every release.

• Test: Run direct, indirect, and multimodal injection cases in CI. ATLAS added Triggers in Multimodal Inputs (AML.T0129) in v2026.09.
• Pass if: No case produces an unapproved tool call or a canary leak. The prompt injection guide shows how to write cases.
• Maps to: LLM01:2026; ASI01 Agent Goal Hijack; NIST MS-2.7-007; ISO/IEC 42001 A.6.2.4; ATLAS AML.T0051 and AML.M0035 (AI Red Team).

11. Untrusted content cannot trigger privileged tools.

• Test: Plant an instruction in an email, ticket, or web page the agent reads, telling it to call a write tool.
• Pass if: The call is refused or held for approval because the context contains untrusted data.
• Maps to: LLM01:2026; ASI02; ATLAS AML.M0030 (Restrict AI Agent Tool Invocation on Untrusted Data).

12. Model output is treated as untrusted input downstream.

• Test: Make the model emit script tags, SQL fragments, and shell metacharacters, then pass the output to every renderer, query, and executor it reaches.
• Pass if: Everything is escaped, parameterized, or rejected. OWASP’s 2026 entry now covers insecure code that assistants generate at scale.
• Maps to: LLM10:2026 Improper Output Handling; ASI05 Unexpected Code Execution; ATLAS AML.M0033.

13. Writes to memory and RAG stores are controlled and traceable.

• Test: Have the agent summarize a page that contains “remember this for future sessions” instructions. Then list what was stored.
• Pass if: Memory writes carry a source, can be listed per user, and can be purged. The CoSnitch research in OWASP’s roundup (CVE-2026-24301) showed a summarization path writing malicious instructions into persistent memory.
• Maps to: LLM09:2026 Vector and Embedding Weaknesses; ASI06 Memory & Context Poisoning; ISO/IEC 42001 A.7.5; ATLAS AML.T0080 and AML.M0031 (Memory Hardening).

Part 4: Supply chain, isolation, and change

An approved component can change after approval. The Deadbugz MCP server in OWASP’s roundup behaved normally for its first three tool calls, then changed its own tool metadata to send connected agents after SSH keys and cloud credentials. Approval is a point in time. These controls make it continuous.

14. Models, packages, and tool servers are pinned, and metadata changes trigger re-approval.

• Test: List every model version, MCP server, and agent package with its version and hash. Then change a tool description in staging.
• Pass if: Everything is pinned, and the description change blocks the tool until someone re-approves it.
• Maps to: LLM04:2026 Supply Chain; ASI04; NIST MANAGE 3.2; ISO/IEC 42001 A.10.3; ATLAS AML.T0109 (AI Supply Chain Rug Pull) and AML.M0014.

15. Code execution is sandboxed with an egress allowlist.

• Test: From inside the agent runtime, request the cloud metadata address 169.254.169.254 and a domain not on the allowlist.
• Pass if: Both fail and both attempts are logged. The MCP guidance lists link-local ranges, including cloud metadata endpoints, among the addresses MCP clients should block.
• Maps to: ASI05; ATLAS AML.M0032 (Segmentation of AI Agent Components).

16. Hard limits cap tokens, spend, and loops.

• Test: Start a task in staging that loops on a tool call.
• Pass if: A hard cap in code stops it and alerts the owner. Unbounded Consumption rose four places in the 2026 list.
• Maps to: LLM06:2026 Unbounded Consumption; ASI08 Cascading Failures; ATLAS AML.T0034 (Cost Harvesting) and AML.M0036.

17. Model, prompt, and tool changes re-run the security tests.

• Test: Pick the last three changes to a model version, system prompt, or tool. Find the test record for each.
• Pass if: The item 10 suite ran and passed before each release.
• Maps to: NIST MANAGE 4.1 and MS-2.7-008; ISO/IEC 42001 A.6.2.4; ATLAS AML.M0008 (Validate AI Model).

Part 5: Detect, stop, and respond

Logging is what lets you answer the first incident question: what did the agent do, and on whose behalf?

18. Agent actions can be reconstructed.

• Test: Pick three random agent actions from last week. Show the trigger, the identity, the inputs, the tool calls, and the output.
• Pass if: All three are reconstructed within one business day.
• Maps to: ISO/IEC 42001 A.6.2.8 (Recording of event logs); NIST MANAGE 4.1; ATLAS AML.M0024 (AI Telemetry Logging).

19. AI-specific detections fire.

• Test: Plant a canary credential where an agent can read it, then have a test agent use it. Also widen a test agent’s tool calls beyond its normal pattern.
• Pass if: Both alerts reach on-call within 15 minutes. ATLAS added AI Agent Scope Drift Detection (AML.M0038) in v2026.08 and AI Honeypots (AML.M0039) in v2026.09.
• Maps to: ASI10 Rogue Agents; NIST MS-2.7-004 (security metrics).

20. Stopping and responding have been rehearsed.

• Test: Time a stop drill on one write-capable agent. Check for an AI incident tabletop that includes a vendor scenario.
• Pass if: The stop took under 15 minutes in the last 90 days, and the tabletop ran in the last 12 months. The kill switch guide splits “stop” into levels, and the incident response runbook covers the rest.
• Maps to: NIST MANAGE 2.4, MANAGE 4.3, and GV-6.2-003; ISO/IEC 42001 A.8.4; ASI08.

How do you score the enterprise AI security checklist?

Score each system separately. A company score hides the one agent that can move money.

Some controls only apply when a system has tools. A read-only chat assistant has no write scopes, irreversible actions, or code runner, so items 5, 6, 8, 9, 11, and 15 can be marked not applicable. Score against the applicable items only.

Six items are release blockers for any system that can write data or run code: 5, 6, 9, 11, 15, and 20. They match the causes in the IBM data and the roundup’s call for “enforced scope, isolated tools and credentials, and monitoring of actual actions.” The selection is my judgment.

Decision rule: if a write-capable system fails any blocker, it does not run in production with write access, whatever its total. Otherwise, 90% or more of applicable items means ready, 70% to 89% means ship with a dated fix plan, and under 70% means fix first. These bands are mine.

A worked example (hypothetical). A company scores two systems.

The IT service agent can reset passwords and close tickets, so all 20 items apply. It passes 16, or 80%. But it fails item 6: it still holds a delete scope from testing that it has not used in 30 days. That is a blocker, so it stays read-only until the scope is removed and the item is re-tested.

The internal policy chatbot has no tools, so 14 items apply. It passes 11, or about 79%. No blocker applies, because it cannot write. It ships with a dated plan for the three gaps.

The 80% system is blocked and the 79% system ships. Totals show maturity. Blockers decide risk.

Bottom Line

An enterprise AI security checklist only counts if every item has a test and a pass condition.

Start with Part 2, because that is where the 2026 breach data points. Find agents on human credentials, cut unused write scopes, and gate irreversible actions in code.

Score per system, and treat the six blockers as hard stops. For a vendor-hosted agent, run the vendor security assessment alongside this list.

FAQ

What is the difference between the OWASP LLM Top 10 and the OWASP Agentic Top 10?

The LLM list covers the model as a component inside your application. The 2026 edition says that once the model becomes an actor, with tools, memory, and downstream consequences, the risk moves to the Agentic list. For agents, use both. The 2026 LLM list was ranked using a corpus of 7,714 real incidents, of which 6,639 had enough detail to classify.

Is there a NIST AI RMF 2.0?

Not as of October 15, 2026. NIST says AI RMF 1.0 “is being revised as part of the White House AI Action Plan,” but no new version is published. NIST released a concept note for a critical infrastructure profile on April 7, 2026. The Cyber AI Profile (IR 8596) is still an initial preliminary draft.

Does ISO/IEC 42001 certification prove our AI is secure?

No. It certifies a management system. Annex A has 38 reference controls, and organizations justify which ones they exclude in a Statement of Applicability. None of them runs a prompt injection test. Use certification as evidence of process, and the tests above as evidence of control.

How often should we re-run the checklist?

My recommendation is quarterly, plus on every model, prompt, or tool change (item 17). The threat catalog moves faster than annual reviews: MITRE published six ATLAS data releases between May 4 and September 15, 2026, ending at v2026.09.

When do the EU AI Act high-risk rules apply?

The AI Omnibus entered into force on July 27, 2026. High-risk rules for Annex III systems, such as hiring and credit scoring, now apply from December 2, 2027. Rules for AI in products under Annex I apply from August 2, 2028. I am not a lawyer.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect