What should an LLM security checklist cover?

Seven areas: an inventory of every model endpoint and every caller, identity and per-request authorization, classification of the assembled context window, handling of model output as untrusted input, scoping and validation of the tool surface, independent per-decision evidence, and vendor and supply-chain tracking. A checklist covering only prompt-level defenses addresses one technique and leaves the identity, evidence, and tool-surface gaps that regulatory and incident reviews land on.

How is this different from the OWASP LLM Top 10?

The OWASP Top 10 for LLM Applications is a risk taxonomy: it names what can go wrong and ranks it. A checklist is an audit instrument: it states a criterion a specific deployment either meets or fails on a given day. Use OWASP to decide what to worry about, and a checklist with pass criteria to find out where your deployment currently stands. They answer different questions and both belong in a program.

Who should own the LLM security checklist?

The platform or security engineering team that owns the AI request path, with sign-off from the compliance function on the evidence section. Splitting ownership by application produces per-application answers to items that only have one correct answer at the infrastructure layer, such as whether AI decisions are recorded independently of the application that made them.

How often should this be run?

Against every new AI application before it reaches production, and quarterly against the whole estate, because the inventory items decay fastest. A new model endpoint, a new SaaS feature with an embedded assistant, or a new agent framework changes items 1 through 5 without anyone filing a ticket. Section 7 needs a faster cadence than quarterly, given that AI infrastructure CVEs are now arriving weekly.

Does passing this checklist make an LLM deployment compliant?

It produces the operational controls and the evidence that most AI regimes ask for, which is the hard part. Compliance also requires the documentation, risk classification, and conformity work specific to each regime, such as EU AI Act Annex IV technical documentation. The checklist gets the architecture into a state where those documents describe something real, rather than describing intent.

The LLM Security Checklist: 34 Items With Pass Criteria You Can Actually Fail

A checklist item that reads "implement prompt injection protection" cannot be failed. Every team reviewing it will mark it green, because every team has done something in that direction. The item that changes a deployment decision reads: "an indirect injection embedded in a retrieved document is refused before the model call, and the refusal writes a record carrying the requesting identity." That one gets failed, and the failure is informative.

Below are 34 items across seven sections. Each has a criterion specific enough to produce a red mark. Netwrix found 97% of organizations that suffered AI-related breaches lacked proper access controls for AI services (Netwrix), which suggests most of these have never been run against a live deployment.

Section 1: Inventory and discovery

Every LLM endpoint reachable from the production network is listed by hostname, including self-hosted inference servers.
Every application, service, and agent that calls a model is mapped to an owner and a business purpose.
AI traffic egressing to unapproved provider domains is measured, with a current number rather than an assumption. Cloud Radix put unauthorized AI tool use at 78% of employees and IT-leader blindness to those interactions at 86% (Cloud Radix).
Browser extensions and IDE plugins that reach model APIs are inventoried.
Every API key issued to a model provider is attributed to a named owner and a rotation date.

Section 2: Identity and authorization

Every model call carries a verified subject identity, rather than a shared service account.
Authorization is evaluated per request against that identity, rather than once per session at login.
The set of models each role may call is declared as policy and enforced at the call, so an unapproved model or provider is refused.
Per-identity and per-route rate and spend limits are enforced inline.
Agent identities are distinct from the human identities that delegate to them, and the delegation is scoped and expiring.
A revoked identity stops making model calls within the revocation window, verified by test.

Section 3: Prompt and context controls

The fully assembled context window, including retrieved documents and injected system content, is classified before the model call.
Data classifications that may not leave the environment are enumerated, and a prompt carrying them is redacted or denied.
Retrieval is authorized against the requester's entitlement at retrieval time, rather than filtered by a query parameter.
Untrusted content is marked by provenance so the model does not receive document text in an instruction role.
Indirect injection carried in retrieved content is caught at the boundary rather than only inside the application.
Prompt content is stored as a hash in the audit record, so the evidence trail is not a second copy of the sensitive data.

Section 4: Response handling

Model output is treated as untrusted input by every downstream consumer, with no path where a response reaches an interpreter, a shell, or a SQL layer without validation.
Responses are scanned for sensitive data before they reach the requester, including data the model retrieved on the requester's behalf that the requester is not entitled to.
A refusal-to-compliance flip within a session raises a signal, which is the observable form of a successful jailbreak.
Structured output is validated against a schema before use.

Section 5: Tools and agents

Every tool an agent may call is declared, scoped, and least-privileged against the agent's task.
Tool arguments produced by a model are validated before execution.
Irreversible actions require a human approval step, defined by effect rather than by tool name.
Tool descriptions are treated as untrusted content, because a compromised description changes model behavior without changing any code.
MCP servers reachable over HTTP authenticate the caller and authorize the tool invocation. The June 2, 2026 NSA and CISA cybersecurity information sheet on MCP security design makes this an explicit expectation for federal deployments (NSA).

Section 6: Evidence and audit

Every AI decision writes a record: who asked, what policy applied, which model answered, what the outcome was.
The record is written by a component other than the application that made the call.
The record commits before the response returns to the application, so a crash after inference leaves evidence behind.
Records are signed and tamper-evident, with a retention period set against the applicable regime.
The policy version in force at the moment of each decision is recoverable from the record.

Section 7: Vendor and supply chain

Model provider contracts have been read for the liability position, and the position is documented. When The Register asked Microsoft, SAP, Oracle, Salesforce, ServiceNow, and Workday how much liability they accept for AI agent decisions, Microsoft and SAP declined to comment and the rest did not respond (The Register).
SaaS vendors with embedded AI features are inventoried, and their model providers are known.
AI infrastructure components in the stack, including gateways, orchestrators, and inference servers, are tracked against active CVE feeds. LiteLLM took seven CVEs in June 2026 alone, and Langflow's CVSS 9.9 CVE-2026-55255 reached active exploitation on July 8 (Help Net Security).

The three that fail most often

Item 8, model authorization. Nearly every deployment authenticates the caller to the gateway and then permits any model the gateway can reach. Which models a given role may call is rarely policy, which means a new provider endpoint added by any team becomes reachable by every identity.

Item 12, context-window classification. Applications classify the user's typed input. The assembled context window, after retrieval and system-prompt injection, is a different object and is usually two to twenty times larger. The data that leaves the environment lives in the part nobody classified.

Item 28, evidence independence. The application that made the AI decision writes the log about the AI decision. That is the self-attestation problem, and it is the item that quietly fails a regulatory review rather than a security review. In every other regulated domain the system under audit does not author its own evidence.

Regulatory anchoring

The evidence items are not optional in the EU. Article 12 of the EU AI Act requires automatic recording of events over the lifetime of a high-risk system to ensure traceability, with logs covering the period of use, the input data, and the identification of natural persons involved (Practical AI Act). Article 99 sets penalties at €15 million or 3% of global annual turnover, whichever is higher (EU AI Act Article 99). Article 50 transparency obligations still apply from August 2, 2026, even after the Digital Omnibus moved the standalone high-risk deadline to December 2, 2027.

DeepInspect

This is the gap DeepInspect closes. Items 6 through 21 and 27 through 31 all describe controls at the same architectural location: the point where an HTTP request leaves an application for a model endpoint. DeepInspect is a stateless proxy at that point, between authenticated users or agents and any HTTP-based LLM, evaluating identity, role, prompt classification, and model authorization on every call and permitting, redacting, or denying inline with a fail-closed default.

Each decision writes a signed record committed before the response returns to the caller, carrying the identity, the model, the policy version, and the outcome. The application never has custody of the write path, which is what makes item 28 passable rather than aspirational. Because the proxy is model-agnostic, one policy set covers OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, and self-hosted endpoints in the same deployment.

If you want to run this checklist against a live deployment and see which items come back red, book an AI readiness assessment.