LLM AI Security and Governance Checklist: 20 Items (2026) for Prompt Injection, RAG and Permissions

An LLM/AI security and governance checklist is only actionable when you define who can use which data and tools, what to test before launch, and who can stop the system if it fails. Do not treat installing a prompt filter as a pass.

The following is an example launch review for an enterprise LLM agent that uses RAG and external tools. It is not a certification scorecard or a legal standard common to every industry. Set owners and approval criteria according to your organization's data and operational risk.

LLM AI Security and Governance Checklist: 20 Items

Record each row as pass, needs work, or not applicable, and keep links to supporting evidence. If you allowed an exception, also record the approver and the next review date. The NIST AI RMF 1.0 function column (GOVERN, MAP, MEASURE, MANAGE) is an editorial mapping example; this table is not from an official framework and is not a certification scorecard. NIST AI RMF

Prompt injection cannot be stopped with regex alone

Besides direct user input, hidden instructions in retrieved documents or web pages can influence model behavior. Blocking a specific English phrase such as ignore system prompt still leaves other languages, phrasings, and external-document paths. OWASP describes combining multiple defenses—least privilege, output validation, separating untrusted content, and controlling sensitive actions—rather than promising complete blocking. OWASP Prompt Injection

So security tests should check not only whether “the model refused the instruction,” but also whether data was actually exposed or a tool actually ran. Verify that the server-side authorization layer still blocks an inappropriate tool call even if the model proposes it.

Bind tool execution to user permissions

For example, suppose a customer-support agent proposes ticket.read. The server must compare the authenticated user's organization and role with the organization that owns the requested ticket. Do not grant access based on a tenant_id the model emitted or a sentence such as “an administrator approved this.”

You can structure the execution flow as follows.

1. Identify the user and tenant from the server session
2. Validate the tool name and arguments against the allowed schema
3. Perform server-side authorization for the target resource
4. Confirm any policy-required action approval
5. Check execution limits and duplicate prevention, then invoke the tool
6. Record the result and authorization decision as minimal audit information

This is a design example. Real access-control code must connect to each service's authentication and authorization store. For an implementation view, continue with LLM Agent Security Design Guide.

Review RAG retrieval and audit logs

Build tenant and permission filters for retrieval from the server's authentication context. Keep document IDs and versions so you can trace answer sources, but a citation does not by itself guarantee accuracy or access rights. Test that permission changes and deletions also propagate to the index and cache.

Prioritize audit-log fields needed for incident investigation: request identifier, model and prompt version, tool name, authorization result, latency, and cost. Storing full raw inputs and responses for long periods can copy personal or confidential data into logs, so define purpose, access rights, and retention first.

Example tests to run before launch

The following is a test design you can run with synthetic data and no real customer information. This article does not claim measured results for any specific product.

Also record how often legitimate requests are blocked. Do not judge operational fitness from “we blocked a few attack strings” alone.

Connect NIST AI RMF to operational records

NIST AI RMF is a voluntary risk-management framework that presents Govern, Map, Measure, and Manage functions. You can also consult the generative AI profile. The mapping below is an application example for this article. NIST AI RMF, AI RMF Core Functions

Treat not only model swaps but also new data sources, new tools, and permission expansions as triggers for re-review. What matters is whether current operations and evidence still match the checklist—not the date it was written.

When a Permission Bypass Is Found After Launch: Tracing and Regression Tests

Even after passing the checklist, you may get reports like "another user's document was quoted in an answer."

Likely causes

• Permission filters are applied after generation instead of at retrieval (content already in context leaks through summaries)
• ACLs were copied into metadata at indexing time, and source permission changes never reached the index
• Tool calls run with a service account instead of the user's token

Tracing

1. Use the request ID of the reported answer to find, in the audit log, the retrieved chunk IDs and each chunk's source document ID.
2. Compare the document's current ACL with the ACL metadata stored in the index.
3. Check the executing principal (user ID or service account) in the tool-call logs.

Fix

• Put the user's group filter in the retrieval query itself so unauthorized chunks never enter the context.
• Consume source permission-change events to update index metadata, and run a periodic full reconciliation.

Lock it in with a regression test

def test_no_cross_tenant_retrieval(retriever):
    hits = retriever.search("quarterly revenue report", user={"id": "u-a", "groups": ["team-a"]})
    assert all("team-a" in h.metadata["allowed_groups"] for h in hits)

Add a test of this shape for every bypass found and run it in CI before each deploy.