CJIS AI Compliance Checklist: Owners, Evidence, and Pass Conditions

A CJIS reviewer can start with an authenticated user sending a prompt containing criminal justice information to one model. The CJIS AI compliance checklist follows that request through identity, flow enforcement, audit generation, weekly review, protected storage, and retrieval. Every action has an owner and a pass condition tied to an artifact, because a policy sentence without an executable test leaves the control open to interpretation.

I would refuse to mark an item complete when its evidence is a slide deck. A pass should resolve to a system result or signed operating record.

TL;DR

• Name one accountable owner for every CJIS AI control action, then record where its evidence lives and which test result counts as a pass, before assessment work begins.
• Carry the originating principal into each routed AI request, enforce the destination and data rules against it, then keep the decision context that enforcement produces.
• Staged records should test five things: complete event generation, weekly review, searchable reports, protected storage, at least one year of retrieval.
• Mark direct calls, local tools, compromised endpoints, vendor-embedded inference and upstream authentication as separate control boundaries.

1. Register the AI data path

Owner: CJIS system owner with the security architect.

Evidence: system boundary, AI data-flow diagram, model destination inventory, connection details, data classes, responsibility record.

Draw six boxes: application, authenticated principal, HTTP enforcement point, model endpoint, response path, audit store. Label where criminal justice information can enter the prompt and where a response returns. Include third-party model services and retrieval components.

Pass condition: every model destination observed in routed traffic appears in the approved inventory and diagram. Each entry carries a named owner, a data classification, a connection path.

2. Preserve the originating identity

Owner: IAM lead with application engineering.

Evidence: authentication configuration, identity assertion schema, validation rules, role mapping, one authentication-to-AI-event join.

The FBI CJIS Security Policy version 5.9.5 includes IA-2 for identification and authentication, using the control structure in NIST SP 800-53 Revision 5. When an application uses a shared provider credential, it should still carry the originating user or named agent into the policy decision and evidence record.

Pass condition: a sampled request resolves through one stable identifier to the authenticated principal, calling application, assigned role, model route, policy decision, UTC timestamp.

3. Enforce access at the model request

Owner: application security with the CJIS policy owner.

Evidence: versioned role-to-route policy, staged tests, decision records, exception approvals.

AC-3 directly addresses access enforcement. Translate the approved use of AI into rules that evaluate five inputs before forwarding the HTTP request: supplied identity, role, requested operation, destination, policy version.

Pass condition: an approved role reaches its permitted destination while a disallowed role receives a denial. Missing identity triggers the documented fail-closed behavior.

4. Control criminal justice information flow

Owner: information security with the CJI data owner.

Evidence: AC-4 flow rules, classification definitions, synthetic prompts, findings, redactions, denials, response handling results.

Test assembled prompts, including user text, retrieved context, system instructions, tool output. A label attached to the source document can miss a protected fragment added later in the request.

Pass condition: staged CJI markers produce the expected classification and handling action before the request reaches an unapproved model. Response-side tests preserve their own finding and disposition.

5. Define auditable events and fields

Owner: audit owner with security engineering.

Evidence: AU-2 event-selection statement, AU-3 field specification, schema version, representative event records.

Select events for permit, redact, deny, response block, policy failure, missing identity, administrative policy change, retrieval. Define fields that establish what happened: when, where, source, outcome, identity. Add the model route, prompt classification, policy version, request identifier, linked response disposition.

Pass condition: each staged event type creates a record with every required field, and schema validation flags a missing value instead of quietly accepting an incomplete record.

6. Generate records for every in-scope request

Owner: AI platform engineering with the audit custodian.

Evidence: AU-12 generation configuration, event counters, failure handling, request and response records, reconciliation output.

Compare application request counts against enforcement-point decisions and retained records for the same test window. Include errors and denied calls in the same reconciliation. The AI audit log schema guide offers a practical request-layer structure, while the organization's CJIS implementation determines required content.

Pass condition: reconciliation accounts for every in-scope event, and a failed audit write triggers the documented handling path before an unrecorded request proceeds.

7. Protect audit information and tools

Owner: audit-log custodian with cloud security.

Evidence: AU-9 access roles, write-path diagram, deletion controls, integrity mechanism, staged tamper test, access-denial result.

Separate the evidence writer and protected store from the calling application's ordinary write path. Put a copied record on screen and alter one field. Run the integrity check. The failed verification should be retained as evidence.

Pass condition: unauthorized modification and deletion attempts fail, and changed content produces an integrity failure. Privileged access is logged and reviewed.

8. Review and report every week

Owner: security operations with the designated CJIS reporting authority.

Evidence: AU-6 review schedule, saved queries, weekly results, reviewer sign-off, findings, escalation record, closure decision.

Queries should cover missing identity, unapproved destinations, repeated denials, CJI classifications, policy-version changes, response blocks. Give each finding a documented disposition and owner. The AI audit evidence guide explains how custody affects later review.

Pass condition: the latest weekly period contains executed queries, a named reviewer, retained results, reported findings, follow-up references. An empty result still needs the dated review record.

9. Produce searchable reports without changing the record

Owner: SOC engineering with the audit owner.

Evidence: AU-7 saved searches, report templates, source identifiers, ordering test, exported results.

Run searches by principal, model destination, policy version, decision, UTC range. Reports should preserve original content and chronological order while keeping a trace back to the protected source event.

Pass condition: a reviewer reproduces each report and follows every row to its source record, then confirms that filtering or export preserved content and sequence.

10. Retain and retrieve the historical record

Owner: records owner with the audit custodian.

Evidence: AU-11 retention approval, storage configuration, archive controls, deletion process, oldest-period query, restoration test.

CJIS calls for at least one year of audit-record retention. Configure the approved period, then test retrieval against the oldest available records and verify their integrity after any archive restoration. The LLM audit log retention guide provides design considerations for searchable and archived events.

Pass condition: records remain retrievable for the required period, preserve original content and order, pass integrity verification, then expire only through the authorized process.

11. Record gaps at the actual boundary

Owner: CJIS system owner with every contributing control owner.

Evidence: responsibility matrix, boundary exceptions, compensating controls, open remediation, retest results.

DeepInspect and similar HTTP enforcement points see only routed traffic. Local execution, direct provider calls, opaque vendor inference, credential compromise, endpoint activity, records approval and incident reporting require adjacent controls.

Pass condition: each requirement names its implementation point, responsible owner, test, evidence, uncovered path, remediation status. A red arrow bypassing the gateway on the diagram has a control owner rather than a footnote.

DeepInspect

DeepInspect evaluates authenticated HTTP AI traffic that an application routes between users or agents and LLM endpoints. It consumes application-supplied identity and policy context and classifies prompt and response content. Each request gets a permit, redact or deny decision plus a signed, tamper-evident per-decision record. Those records can support items covering AC-3 and AC-4, plus the AU control family, within the routed request boundary.

Your CJIS program still owns the system boundary, identity assurance, forced routing, approved records schedule, weekly review, response process. Book a technical deep dive at deepinspect.ai.