LLM Security Checklist: 18 Checks Before an Enterprise Pilot

The short answer: an LLM security checklist has to cover six areas, not one. Prompt injection gets the attention, but enterprise pilots are more often blocked by ordinary failures that happen to sit inside an AI product: a login token that lasts a week, an endpoint that forgets to filter by customer, no record of who asked the model what. Each check below names the evidence that proves it, because “we have guardrails” is not an answer a security reviewer accepts.

Why a Checklist, and Why Evidence

The OWASP Top 10 for LLM Applications 2025 is the shared vocabulary for AI-specific risk, from LLM01 Prompt Injection to LLM10 Unbounded Consumption. It tells you what can go wrong. It does not tell you what to show a customer’s security team to prove it will not.

That second part is where pilots stall. A questionnaire asks how you prevent one customer seeing another’s documents, and the honest answer in many AI products is a paragraph about intent. The answer that closes the question is a test: sign in as customer A, request customer B’s record through every path, including the vector search, and show it fails. So every check below comes with the evidence I would ask for.

What Blocked a Real Pilot

On an AI platform for pharmaceutical manufacturers that I hardened before its enterprise pilots, a 26-check assessment found 2 critical, 4 high and 3 medium issues. The two critical findings were not exotic. Access tokens were valid for seven days, so a stolen token meant a week of access to manufacturing data; they were cut to eight hours. And one document endpoint was missing its tenant filter, so one customer could read another’s files; it was fixed with entity-scoped queries and tested across every API path.

The AI-specific work came after: input and output guardrails backed by more than fifteen test cases, and an audit trail covering every AI query. The platform closed its engagement with 24 of 24 acceptance criteria passed and was approved for enterprise pilots seven weeks after the first check. The lesson for a checklist is the order: the boring findings are the ones that block you first.

The 18 Checks

1. Prompt injection and jailbreaks

OWASP mapping: LLM01 Prompt Injection, LLM06 Excessive Agency

1. Prompt injection and jailbreaks: checks and the evidence that proves each
Check	Evidence a reviewer accepts
The model cannot take a consequential action (send, write, pay, delete) without a human confirming it.	A list of every tool the model can call, and a test that an injected instruction to call one is not executed.
Hostile instructions planted in a retrieved document are tested, not just ones typed in the chat box.	A test index seeded with instruction-shaped documents, and assertions on behaviour rather than wording.
Input and output guardrails exist, can be switched between blocking and logging, and are covered by tests.	Guardrail test cases that go red when the guardrail is disabled.

2. Data leakage in answers

OWASP mapping: LLM02 Sensitive Information Disclosure, LLM07 System Prompt Leakage

2. Data leakage in answers: checks and the evidence that proves each
Check	Evidence a reviewer accepts
Outputs are scanned for personal data, credentials and secrets before they reach the user.	Output-guardrail tests with planted API keys and personal data in source documents.
The system prompt contains nothing that would matter if it leaked: no keys, no internal URLs, no other customers’ names.	The system prompt itself, reviewed. Assume it will be extracted.
What is sent to the model provider is known, and the provider’s retention and training terms are recorded.	A data-flow diagram and the provider terms you rely on, dated.

3. Tenant isolation, end to end

OWASP mapping: LLM08 Vector and Embedding Weaknesses

3. Tenant isolation, end to end: checks and the evidence that proves each
Check	Evidence a reviewer accepts
Every API path that returns a record filters by tenant, including detail views and downloads.	A cross-tenant test per endpoint: sign in as tenant A, request tenant B’s record by ID.
The vector store enforces the same boundary as the database (namespace or filter per tenant), so retrieval cannot return another customer’s chunks.	A retrieval test run as tenant A that asserts no tenant B chunk IDs come back.
Caches, conversation history and uploaded files are scoped the same way.	The cache key and storage path schemes, showing the tenant in each.

4. Sessions, secrets and platform

OWASP mapping: LLM03 Supply Chain (plus ordinary application security)

4. Sessions, secrets and platform: checks and the evidence that proves each
Check	Evidence a reviewer accepts
Access tokens are short-lived, measured in hours rather than days.	Token lifetime configuration from production.
Secrets live in a secret store, not in the repository, the container image or the prompt.	A secret scan of the repository history and images.
Containers run as non-root with capabilities dropped, and images are scanned for critical vulnerabilities.	Deployment manifests and the latest image-scan report.

5. Audit trail and traceability

OWASP mapping: Supports every item above; required for EU AI Act Article 12 in high-risk systems

5. Audit trail and traceability: checks and the evidence that proves each
Check	Evidence a reviewer accepts
Every AI query is logged with the tenant, the user, a request ID, the model and prompt version, and token counts.	One real log record, redacted, showing each field.
Security-relevant actions (sign-in, document access, permission changes, AI queries) are logged in an append-only store.	The store’s configuration showing records cannot be edited or deleted by the application.
Retention is set deliberately and written down, and personal data in logs has an erasure answer.	The retention setting and the policy it implements.

6. Architecture under load and failure

OWASP mapping: LLM10 Unbounded Consumption

6. Architecture under load and failure: checks and the evidence that proves each
Check	Evidence a reviewer accepts
Per-user and per-tenant rate and spend limits exist, so one account cannot run up the model bill or starve others.	The limit configuration and a test that exceeds it.
A model-provider outage degrades the product gracefully rather than failing every request.	A failover path or a documented degraded mode, and the alarm that fires.
Alarms exist for the security events above, and someone receives them.	The alarm list and its routing.

Depth on the hardest three areas is in prompt injection defence for RAG, multi-tenant RAG isolation and what to log for every LLM call.

What to Fix First

Isolation. A cross-tenant read ends the pilot and possibly the customer relationship. It is also usually a small fix once found.
Sessions and secrets. Token lifetime and leaked keys are the findings a conventional security team spots first, and they colour everything after.
What the model can do. Remove or gate any tool that sends, writes or deletes before you harden prompts. It removes more risk than any filter.
The audit trail. Without it you cannot answer the post-incident question, and regulated buyers will ask it before the incident.
Guardrails and load limits. Necessary, and weakest on their own.

Answering the Security Questionnaire

Most enterprise questionnaires for AI vendors reduce to five questions: what data goes to which model provider, who can see whose data, what the model can do on a user’s behalf, what is logged and for how long, and how you would know if something went wrong. If you have worked through the checks above, each answer is a short paragraph plus an attachment. If you have not, each answer is a promise, and experienced reviewers can tell the difference.

For teams selling into the EU, the logging answer is becoming a legal one as well as a commercial one. Article 12 of the EU AI Act requires high-risk systems to record events automatically over their lifetime; the position for UK and US companies is set out in the EU AI Act for UK and US companies.

Frequently Asked Questions

What should an LLM security checklist cover?

Six areas: prompt injection and jailbreaks, sensitive data leaking into answers, tenant and user isolation from the database through to the vector store, sessions and secrets, the audit trail, and behaviour under load and failure. The OWASP Top 10 for LLM Applications 2025 is the reference list of risks; a checklist is only useful if each item names the evidence that proves it, such as a failing test when the control is removed, rather than a statement that the control exists.

Is the OWASP LLM Top 10 enough for an enterprise security review?

It is the right vocabulary, not the whole review. Enterprise buyers also ask about the things every SaaS product is asked about: session lifetime, encryption, access to production, logging and retention, and who can reach customer data. An AI product fails those ordinary checks as often as it fails the AI-specific ones. On one pharmaceutical platform the two critical findings were a seven-day login token and a missing tenant filter, neither of them an AI risk.

How do you test an AI chatbot for security?

Test the system, not the wording of the model. Plant hostile instructions in documents in a test index as well as in the chat box, sign in as one tenant and try to retrieve another tenant’s records through every endpoint including the vector search, and assert on behaviour: no unauthorised retrieval, no tool call, no secret or personal data in the output. Run those tests on every prompt, model and retrieval change, because each is a configuration change that can reopen a closed hole.

What evidence does an enterprise security questionnaire expect for an AI product?

Evidence that a reviewer can check without trusting you: tests that fail when a control is removed, configuration showing token lifetimes and encryption, a sample of the audit log showing who asked what and which model answered, retention settings, and a written account of what the model can and cannot do on a user’s behalf. A description of a guardrail is weak evidence; a test suite that exercises it is strong evidence.

Is an LLM security review the same as a penetration test?

No. A penetration test attacks the running system from outside and reports what an attacker could reach. An architecture-level security review reads the design and code to find why those holes exist and whether the fix holds, including AI-specific risks such as indirect prompt injection that a conventional pentest scope often misses. Many enterprise buyers want both; the review is worth doing first, because it closes the obvious findings before a pentester spends time on them.

Run It Before They Do

Every enterprise customer will run some version of this checklist on your product. The only choice is whether you see the findings first. If the product is an app you built with an AI coding tool, a pre-launch review of the app is the lighter starting point. For an AI system heading to enterprise customers in the UK, US or Europe, an AI security and architecture review works through these six areas against your code and infrastructure and hands back the evidence, not just the findings.

LLM Security Checklist: 18 Checks Before an Enterprise AI Pilot