AI Runtime Security Checklist: A Go-Live Gate for Every Model Route

An AI runtime security checklist decides which routes may carry production traffic. The acceptance unit is a chatbot or RAG service, a batch job, a copilot, or an agent calling a model. Each route needs a named route owner and a security owner. It also needs tested policy behavior and evidence tied to the release. I would reject any gate that closes with "monitoring planned." A reviewer should be able to point at one green or red row on the release sheet and explain the decision.

TL;DR

• Inventory every production model route, including chatbots and RAG pipelines plus background jobs. Include copilots and agent loops.
• Test identity propagation and prompt classification, then model authorization and response handling. Test quotas plus failure behavior with recorded evidence.
• Give each exception an owner and reason. Record its expiry date and compensating control. Exclude unmanaged routes explicitly.
• Sign a go-live acceptance record tied to the deployed service version and policy version. Include the route configuration and rollback plan.

AI runtime security checklist scope

Record the calling service and human or workload identity. Add the upstream and fallback models. Record prompt data classes and the response consumer, followed by the policy version and owner. A diagram on a conference-room screen should show every arrow crossing the AI request boundary. Give hidden fallbacks their own rows because an outage can move regulated prompts to a provider with different terms.

The NIST AI Risk Management Framework calls for production monitoring under MEASURE 2.4 and a deployment proceed or stop decision under MANAGE 1.1. The NIST source text supports a route-level acceptance record. This gate covers HTTP traffic sent to an LLM. Shell execution and filesystem permissions need separate controls. Tool sandboxes and credential storage do too. The boundary matches agentic AI runtime security and extends acceptance to non-agent paths.

1. Identity reaches every model call

Pass when each request carries a verified human user or service identity. A workload or agent identity must also include role and tenant context. Test a normal user and privileged role. Then test a disabled account and cross-tenant attempt. Include a background job. Shared credentials need an upstream record that resolves the initiating principal or a documented service-only policy.

Evidence should include sanitized request metadata and the policy decision. NIST SP 800-53 AC-3 requires approved authorizations for logical access to information and system resources. The control catalog includes users and processes acting on their behalf. Login authentication leaves a gap if context disappears before the model call.

2. Prompt data classes drive route policy

Pass when policy classifies the assembled prompt before forwarding and maps each class to allowed models and actions. Test PII and credentials alongside source code. Test customer-confidential text and regulated classes. Include retrieved passages and system-added context.

The decision record should show the detected class and rule identifier. It should also show the matched policy and outcome such as permit or deny, with redaction where required. OWASP lists sensitive information disclosure as LLM02:2025 and recommends strict access controls plus restricted data sources. It also recommends tokenization or redaction. Its official guidance also warns that system-prompt restrictions may be bypassed. The route therefore needs enforceable policy outside model behavior.

3. Model and fallback authorization are tested

Pass when policy permits only approved model endpoints for this workload and data class. The same approval must cover region and identity. Force the primary endpoint to fail and observe the fallback. A successful functional fallback can still fail security acceptance if it changes provider or retention terms. Changes to geography or model capability can also fail acceptance.

Record each attempted destination and its allow or deny rule. Cover streaming endpoints and embeddings in use. Cover multimodal routes and batch APIs too. This catches the quiet route added during an outage at 2 a.m. and forgotten later.

4. Request and response handling fail safely

Pass when malformed requests and classifier failure produce the approved response. The same requirement applies to unavailable policy state and audit-write failure. Exercise timeout and retry alongside a partial stream. Then test oversized context and provider errors. Prove what reaches the caller and the model.

Responses need their own handling rules. Validate sensitive output and prompt-injection indicators. Check unsafe structured output and rendering into downstream HTML or commands. OWASP LLM05:2025 treats insufficient validation and sanitization of model output as improper output handling. A model response remains untrusted input to the next component.

5. Quotas and escalation have owners

Pass when rate limits bind to identity and tenant. They must also bind to route and cost budget. Test bursts and long prompts. Test retries and concurrency. OWASP LLM10:2025 recommends rate limits and quotas alongside timeouts and throttling. It also recommends resource monitoring and queued-action limits in its unbounded consumption guidance.

Define who receives the alert and who may raise a quota. State which evidence supports the change. A customer-support surge may justify temporary capacity. An unknown identity creating expensive requests justifies a block and investigation. Both events can look identical in a provider billing graph, so route identity and decision logs carry the distinction.

6. Audit and incident evidence can reconstruct one turn

Pass when a reviewer can select one request and recover the time and source identity. The record must identify the route and model. It must also contain the prompt classification and policy version. Finish with the outcome plus response classification and correlation identifier. NIST SP 800-53 AU-3 names the event type and time alongside the location and source. It also names the outcome and associated identity as audit-record content. Store only the prompt material required by policy, because audit trails can create their own privacy exposure.

Run the reconstruction before approval. Then connect the record to AI security incident response. The framework includes incident response and recovery alongside change management. It also includes appeal and override in post-deployment monitoring plans. A route with logs but no tested response owner stays red.

7. Unmanaged exclusions are explicit

List traffic excluded from this gate: direct browser use and personal API keys, plus local models. Add unregistered vendor AI and workloads that bypass the approved route. Assign discovery or blocking controls to each exclusion. Local tool execution and filesystem access sit outside an LLM HTTP enforcement point.

The release record should state residual risk in plain language and name the approving owner. Tie exceptions to an expiry date. This prevents a temporary bypass from becoming permanent architecture and keeps the checklist distinct from a broad threat catalog.

8. The acceptance record is signed and repeatable

The final artifact names the service build and route configuration. It records the policy version and test evidence. It also lists exceptions and rollback, followed by the security approver and workload owner. Re-run the gate after a model change and fallback or a data source change. A new identity mapping or material policy update also requires a new run. The framework calls for tracking emergent risk in deployed contexts, so material route changes require new approval.

The signed record produces a go or no-go decision. It also gives operations a stable baseline for the monitoring pattern in why AI security must be inline.

DeepInspect

DeepInspect can enforce policy for HTTP traffic on accepted routes. The application supplies identity context. DeepInspect evaluates role and route, followed by destination and data classification. It then writes a per-decision record. Agent sandboxes and tool permissions remain with their runtime. Local execution and filesystem access do too.

Book a demo today.