CJIS AI Controls Mapping: Requirements at the Authenticated LLM Boundary

An authenticated justice application sends an HTTPS request to an LLM. A useful CJIS AI controls mapping identifies the requirement; control point; owner; test; artifact; and uncovered path. Assigning a control family to one transaction weakens the mapping.

I prefer maps with visible gaps because they attract the right technical argument before assessment.

TL;DR

• Map each CJIS requirement to one control point; accountable owner; repeatable test; retained artifact; and stated boundary.
• Treat IA-2 as upstream identity work; use AC-3 and AC-4 at the routed request point when the caller's identity plus destination and data context are available.
• Separate audit generation and protection from weekly human review; reporting; approved retention; and broader incident handling.
• Limit gateway coverage to authenticated HTTP requests routed through it; direct provider traffic; local execution; endpoints; and opaque vendor calls need other controls.

Use six fields for every control

The FBI CJIS Security Policy version 5.9.5 aligns its control identifiers with NIST SP 800-53 Revision 5. Each mapping entry should contain six fields:

• Requirement: the selected CJIS control objective and its applicable parameters.
• Control point: the system component where the mechanism operates.
• Owner: the role accountable for configuration and operation.
• Test: a repeatable action with an expected result.
• Evidence: the retained configuration and events, with the relevant report or sign-off.
• Boundary: traffic and systems covered, plus adjacent paths requiring another control.

Start with the request path and identify which component can stop the relevant action. The zero trust for AI guide applies the same reasoning.

IA-2 supplies the principal

Requirement: uniquely identify and authenticate organizational users or approved processes under IA-2.

Control point: identity provider and calling application before the outbound model request.

Owner: IAM lead with application owner.

Test: authenticate a staged user and validate the assertion. Join that event to the AI decision, then repeat with an expired assertion.

Evidence: authentication record; assertion schema; validation result; role mapping; correlation identifier; and denial event.

Boundary: a gateway can validate supplied identity context. Proofing; account lifecycle; authenticator management; and compromised-session investigation remain upstream. Discarded identity cannot be reconstructed at the model boundary.

AC-3 enforces the routed request

Requirement: enforce approved authorizations for logical access under AC-3.

Control point: inline HTTP decision point before the request reaches the LLM endpoint.

Owner: CJIS policy owner with AI platform engineering.

Test: send approved and disallowed roles to the route, then omit policy context. Confirm each result before forwarding.

Evidence: versioned policy; identity and role; destination; decision event; UTC timestamp; response status.

Boundary: direct coverage applies when in-scope calls traverse the control point. Network and application owners prove routing and bypass prevention. Provider-console administration belongs somewhere else.

AC-4 controls information flow

Requirement: enforce approved information-flow authorizations within the system and between connected systems under AC-4.

Control point: prompt and response inspection on the routed HTTP exchange.

Owner: CJI data owner with application security.

Test: place approved synthetic markers in prompts and model output. Verify classification and the configured action for each destination.

Evidence: classification definitions; test prompts; findings; applied policy version; transformed content where authorized; and linked response disposition.

Boundary: this point covers visible routed HTTP payloads. Bypassed traffic; local models; copied files; and opaque vendor inference require other mechanisms. The CMMC AI compliance guide shows a related boundary under another government control regime.

AU-2 and AU-12 establish event generation

Requirement: select auditable events under AU-2 and generate their records under AU-12.

Control point: enforcement service and its protected event writer.

Owner: audit owner with AI platform engineering.

Test: execute each selected event type, including denials and errors. Reconcile decision counters with retained records for the same UTC window.

Evidence: event selection; generation configuration; schema version; counters; reconciliation output; linked request and response records.

Boundary: the request layer covers events it observes. Provider internals; later application actions; endpoints; and unobserved routes need separate sources.

AU-3 defines decision content

Requirement: create records containing enough information to establish what occurred, when and where, source, outcome, and identities involved under AU-3.

Control point: event schema and serialization at the AI decision point.

Owner: audit owner with the CJI data owner.

Test: validate staged events against the approved schema, then omit one required field. The test should flag the incomplete event.

Evidence: request identifier; principal; relay application; model destination; prompt classification; policy version; decision; timestamp; response disposition; and schema-validation output.

Boundary: protected content may reside in a separate store. A fingerprint supports correlation when approved retrieval reconnects it to source evidence. The AI audit log schema guide offers an implementation pattern.

AU-6 and AU-7 turn records into review evidence

Requirement: review and analyze audit records at least weekly under AU-6, report findings to designated personnel, and provide search and reporting under AU-7 while preserving original content and time ordering.

Control point: security operations query and case-management process.

Owner: SOC lead with the designated CJIS reporting authority.

Test: search a historical period by principal; destination; policy version; and decision. Confirm traceability and order, then preserve reviewer sign-off.

Evidence: saved queries; exported report; source record identifiers; ordering check; weekly review record; escalation; and closure ticket.

Boundary: a gateway supplies searchable records. Human review; reporting; evidence correlation; and remediation remain operational responsibilities. Coverage is partial.

AU-8, AU-9, and AU-11 preserve the record

Requirement: use authoritative timestamps under AU-8, protect audit information and tools under AU-9, and retain records for at least one year under AU-11.

Control point: trusted time source; protected audit store; access-control plane; integrity verifier; and archive.

Owner: audit-log custodian with cloud security and records management.

Test: compare event time with the approved source, alter a copied event, attempt deletion, and retrieve the oldest available period.

Evidence: time configuration; access roles; failed modification and deletion results; integrity output; retention configuration; restoration record; and historical query.

Boundary: the event service can stamp, sign, store, and retrieve routed records. Records management approves the schedule. Other logs retain separate custody. The tamper-evident audit log guide examines integrity in more depth.

The compact mapping

Use these entries as a working crosswalk, not a claim of system-wide coverage:

• IA-2: identity provider; IAM owner; assertion join test; authentication and validation evidence; partial at the gateway.
• AC-3: inline HTTP decision point; AI policy owner; allowed and denied role tests; per-request decision; direct for routed traffic.
• AC-4: content inspection point; CJI data owner; synthetic flow test; classification and action record; direct only for visible routed content.
• AU-2/AU-12: event writer; audit and platform owners; event reconciliation; configuration and generated records; direct for observed traffic.
• AU-3: event schema; audit owner; missing-field test; complete decision record; direct for generated gateway events.
• AU-6/AU-7: SOC workflow; review owner; weekly search and ordering test; report and disposition; partial.
• AU-8/AU-9/AU-11: time; protected store; archive; log custodian and records owner; time, tamper, access, and retrieval tests; shared responsibility.

Mark each direct claim in the architecture workbook with this boundary: authenticated HTTP AI traffic routed through the named enforcement point. That prevents a request-layer mechanism from implying complete CJIS compliance.

DeepInspect

DeepInspect supplies an inline control point for authenticated HTTP traffic that applications route to LLM endpoints. It validates application-supplied identity context; evaluates role, content classification, destination, and policy version; permits or denies the request, with redaction where policy allows; inspects the response; and writes a signed, tamper-evident event outside the calling application's ordinary write path.

That mechanism can contribute direct evidence for selected AC and AU objectives within routed traffic. IAM; routing assurance; endpoint controls; records approval; weekly review; broader logging; and incident handling remain with the owners named in the map. Book a technical deep dive at deepinspect.ai.