CJIS Security Policy v6.1 and AI: which controls apply when an LLM touches CJI

RedLens AI Security Research · 8 October 2026 · Read against CJISSECPOL v6.1 (25 June 2026) and v5.9.5 (9 July 2024)

The short answer

The CJIS Security Policy has no separate chapter for AI. When an AI system processes, stores or transmits Criminal Justice Information (CJI), it is part of the environment the policy already covers, and the existing controls apply to it.
We map 17 of those controls across 8 families to evidence an AI security programme actually produces. 11 are sanctionable now (marked [Existing] or [Priority 1], sanctionable since 1 October 2024); 6 sit in the zero-cycle that ends 30 September 2027.
6 of the 17 do not exist in v5.9.5 (CA-5, CA-7, SA-9, SA-11, SR-5, SR-10). They are where AI testing evidence fits best, and an agency still working from the older document has no control number to file it under.
The FBI does not certify any product or vendor for CJIS, RedLens included. Your agency's CJIS Systems Officer or CJIS Systems Agency decides.

How v6.1 is organised, and how to cite it

CJISSECPOL v6.1 reorganised the policy around the NIST SP 800-53 control families. It keeps only two numbered policy areas, 5.1 Information Exchange Agreements and 5.20 Mobile Devices, and lists the families between them as unnumbered headings whose requirements are cited by bare control id: RA-5, SI-10, CA-7. Version 5.9.5 numbered them as sections instead (5.5 Access Control, 5.15 System and Information Integrity, 5.19 Risk Assessment). That is why every citation below carries a v6.1 control id and, where one exists, the v5.9.5 section.

Sanction status is a property of each requirement's marking, not of which version an agency holds. Section 1.4 of v6.1 says that from 1 October 2024, "requirements existing prior to the CJISSECPOL modernization (i.e., version 5.9) and those identified as [Priority 1] will be the set of sanctionable requirements", and that [Priority 2] through [Priority 4] modernised requirements sit in a zero-cycle that ends on 30 September 2027.

The three controls that matter most for AI

`SI-10` Information Input Validation

SI-10 requires validating "any system or application input that might receive or process CJI". A language model in a dispatch or records workflow takes free text as input and can treat it as instruction. That is the failure a conventional input validator does not look for, and exactly what prompt-injection, indirect-injection and retrieval-poisoning tests exercise. It is [Priority 1], so it is sanctionable now.

`AC-6` Least Privilege

AC-6 explicitly reaches "processes acting on behalf of users", which is what an AI agent is. An agent that can call more tools, or reach more data, than its task needs is a least-privilege failure in the policy's own words. Excessive-agency, tool-chain-hijacking and containment-escape tests produce the evidence.

`CA-7` Continuous Monitoring

CA-7 is [Priority 1] and already sanctionable, and it is the control where "we tested it once" is not enough by definition. The evidence is scheduled, recurring assessment on a recorded cadence, with the change between runs scored. CA-7 does not exist in v5.9.5 at all.

The version gap

Six of the mapped controls, CA-5, CA-7, SA-9, SA-11, SR-5, SR-10, are new in v6.x and have no v5.9.5 counterpart. They cover continuous assessment, plans of action, external services, developer testing and supply-chain risk, which is where AI security testing produces its strongest evidence. An agency audited against v5.9.5 has nowhere to file that evidence, so the evidence package says "not present in v5.9.5" rather than quietly printing only the v6.1 number.

All 17 controls, and what an AI security programme can evidence for each

"Evidence" means recorded activity relevant to the control. It never means the control is satisfied. Open each row for why it applies and where its limits are.

Control (v6.1)	Family	Sanction status	v5.9.5	What RedLens records as evidence
RA-3 Risk Assessment	Risk Assessment	Zero-cycle to 30 September 2027 [Priority 2]	§5.19 RA-3	Adversarial red-team scans, AI asset inventory Why it is relevant, and its limits Adversarial red-team scans against the agency's registered AI systems identify threats and vulnerabilities in those systems and record severity, and the asset inventory establishes which AI systems were in scope. This is a threat-and-vulnerability input to the agency's risk assessment covering the AI slice of the environment only -- not the risk assessment itself, which must cover every system that processes, stores, or transmits CJI.
RA-5 Vulnerability Monitoring and Scanning	Risk Assessment	Sanctionable now [Priority 1]	§5.19 RA-5	Adversarial red-team scans, Finding lifecycle (owner, status, dates) Why it is relevant, and its limits Recurring adversarial scans with per-attack findings and severity ratings are vulnerability monitoring of the AI systems, and the finding lifecycle records the dates each was opened and resolved -- which is what the remediation-window requirement is measured against. RedLens does not scan the agency's network, hosts, or applications; a conventional vulnerability scanner is still required for the rest of RA-5's scope.
RA-7 Risk Response	Risk Assessment	Zero-cycle to 30 September 2027 [Priority 2]	§5.19 RA-7	Finding lifecycle (owner, status, dates) Why it is relevant, and its limits The finding remediation workflow records the decision taken on each assessment finding -- assignment, due date, resolution note, and open/resolved status -- which is the documented response RA-7 asks for. It covers only findings this platform produced; responses to findings from the agency's other assessments, monitoring, and audits are not recorded here.
SI-2 Flaw Remediation	System and Information Integrity	Sanctionable now [Existing] [Priority 1]	§5.15 SI-2	Finding lifecycle (owner, status, dates) Why it is relevant, and its limits Findings are identified flaws in the AI system's behavior, and the remediation workflow records that each was reported to an owner and tracked to correction with dates. SI-2's software and firmware patching obligation is not evidenced here -- RedLens neither distributes nor installs updates.
SI-4 System Monitoring	System and Information Integrity	Sanctionable now [Priority 1]	§5.15 SI-4	Flagged AI traffic and agent tool-call alerts Why it is relevant, and its limits Recorded AI traffic events with anomaly flagging, plus AI-ransomware pattern alerts, are attack-indicator monitoring of the AI interface. SI-4 as written also covers intrusion detection, malicious-code protection, network and firewall monitoring across the whole system -- none of which this platform performs.
SI-5 Security Alerts, Advisories, and Directives	System and Information Integrity	Sanctionable now [Existing] [Priority 2]	§5.15 SI-5	Critical-alert deliveries Why it is relevant, and its limits The critical-alert dispatcher generates internal security alerts from detected AI-security events and records each delivery to a named recipient -- evidence of SI-5(b) generation and SI-5(c) dissemination for the AI slice, with a per-delivery audit trail. SI-5(a) ingestion from CISA / MS-ISAC / US-CERT and SI-5(d) directive implementation are the agency's, not RedLens's.
SI-7 Software, Firmware, and Information Integrity	System and Information Integrity	Sanctionable now [Priority 1]	§5.15 SI-7	Integrity hash baselines Why it is relevant, and its limits Hash-based integrity checks of model weights, system prompts, and training data against recorded baselines are exactly the cryptographic-hash integrity mechanism SI-7's discussion names, applied to the AI components. Scope is the registered AI assets only -- operating systems, drivers, and firmware are outside it.
SI-10 Information Input Validation	System and Information Integrity	Sanctionable now [Priority 1]	§5.15 SI-10	Adversarial red-team scans Why it is relevant, and its limits Prompt-injection, indirect-injection, and retrieval-poisoning attacks test precisely whether the AI system accepts attacker-supplied input as instruction -- the failure mode SI-10 exists to prevent, in the one place a conventional input validator does not look. Findings evidence that the AI input path was tested and what it did; they do not evidence validation of the agency's other application inputs.
CM-8 System Component Inventory	Configuration Management	Sanctionable now [Priority 1]	§5.7 CM-8	AI asset inventory Why it is relevant, and its limits The AI asset inventory records each registered AI system's type, vendor, model, owning department, and monitoring status -- a maintained component record for the AI systems, which are the components most likely to be missing from a conventional IT inventory. It is a subset of, not a substitute for, the agency's CM-8 inventory: no hardware, serial numbers, licences, or physical locations are recorded.
AC-6 Least Privilege	Access Control	Sanctionable now [Existing] [Priority 1]	§5.5 AC-6	Adversarial red-team scans Why it is relevant, and its limits AC-6 explicitly reaches processes acting on behalf of users, which is what an AI agent is. Excessive-agency, tool-chain-hijack, and containment-escape attacks test whether the deployed agent can be made to act beyond its assigned privilege, and findings record where it did. This evidences testing of the AI agent's privilege boundary, not the agency's account provisioning or privileged-user review.
SC-7 Boundary Protection	System and Communications Protection	Sanctionable now [Existing] [Priority 1]	§5.10 SC-7	Adversarial red-team scans Why it is relevant, and its limits Data-exfiltration and sensitive-disclosure attacks test whether the AI system can be induced to emit protected data across its own interface -- an egress-boundary test of a channel that firewalls and gateways do not inspect, because the traffic is well-formed application output. Deliberately framed as egress evidence, not encryption: RedLens validates no cryptographic module and no network boundary device.
CA-5 Plan of Action and Milestones	Assessment, Authorization, and Monitoring	Zero-cycle to 30 September 2027 [Priority 4]	Not in v5.9.5	Finding lifecycle (owner, status, dates) Why it is relevant, and its limits The finding remediation workflow is a POA&M in substance for the AI findings: each weakness carries an owner, a due date, a status, and a resolution note, and the record updates as findings close. It covers only weaknesses this platform found; the agency's POA&M must consolidate every assessment source.
CA-7 Continuous Monitoring	Assessment, Authorization, and Monitoring	Sanctionable now [Priority 1]	Not in v5.9.5	Scheduled assessments and drift, Flagged AI traffic and agent tool-call alerts Why it is relevant, and its limits Scheduled recurring assessments run on a recorded cadence with per-run results, and drift events record scored regressions between consecutive runs -- an ongoing frequency and an ongoing assessment, with the comparison already done rather than left to the reader. Combined with recorded traffic monitoring this is continuous monitoring of the AI systems. The twenty CA-7(a) metrics the policy enumerates are agency-wide (account management, physical access, environmental controls, maintenance tools...); this platform speaks to the AI portion of SI-4 and nothing else on that list.
SA-9 External System Services	System and Services Acquisition	Sanctionable now [Existing] [Priority 2]	Not in v5.9.5	Vendor-assessment authorization ledger Why it is relevant, and its limits The vendor-assessment ledger records who authorized security testing of which third-party AI system, under which engagement and for how long -- documented due diligence on external AI service providers. It evidences that diligence happened; it is not a management control agreement, an MCA, or any of the contractual instruments SA-9 requires.
SA-11 Developer Testing and Evaluation	System and Services Acquisition	Zero-cycle to 30 September 2027 [Priority 2]	Not in v5.9.5	Adversarial red-team scans, Finding lifecycle (owner, status, dates) Why it is relevant, and its limits For an agency that builds or fine-tunes its own AI system, scan records are the produced evidence of executed testing (SA-11(b),(c)) and the remediation workflow is the verifiable flaw-remediation process with flaws tracked to correction (SA-11(d),(e)). Where the AI is bought rather than built, this is evidence the agency independently tested a supplied component, which is not the same thing as the developer having done so.
SR-5 Acquisition Strategies, Tools, and Methods	Supply Chain Risk Management	Zero-cycle to 30 September 2027 [Priority 2]	Not in v5.9.5	Model-provenance disclosures and lineage probes, Vendor-assessment authorization ledger Why it is relevant, and its limits Model-provenance disclosures capture, per AI target, what the supplier states the model is built from -- base model, fine-tuning, declared data-source categories, adapters, RAG corpus -- and the vendor ledger records the authorization under which that supplier's system was assessed. Together they are a recorded supplier-attestation trail for the AI supply chain. Critically, RedLens does not verify a disclosure: it is the supplier's attestation, captured, exactly as SR-5's text contemplates.
SR-10 Inspection of Systems or Components	Supply Chain Risk Management	Zero-cycle to 30 September 2027 [Priority 3]	Not in v5.9.5	Model-provenance disclosures and lineage probes, Integrity hash baselines Why it is relevant, and its limits Behavioral lineage probes re-observe a third-party AI endpoint over time and flag when its self-identification or refusal posture changes from the prior capture, and hash-based integrity checks detect alteration of a self-hosted model's weights or prompts against a baseline. Both are periodic tamper-detection inspections of AI components. A behavioral probe observes behavior, never composition -- it is a signal for investigation, not proof of tampering, and it cannot identify a backdoor or its cause.

What this mapping does not cover, and why

These are limits of what an AI security platform can observe, not items on a backlog. A CJIS Systems Officer should read them first: they are why the rest of this page can be trusted.

Personnel Security (PS)
RedLens holds no personnel screening, fingerprinting, or background-check data whatsoever. This is the family CJIS agencies are audited on most closely and the one this platform can say least about. New as a control family in v6.x; mapping to it would be pure overclaim.
SC-8, SC-12, SC-13, SC-28 -- transmission, key management, cryptographic protection, protection at rest (SC (crypto controls))
CJIS crypto requirements turn on FIPS 140-validated modules and on protecting CJI in transit and at rest. RedLens tests an AI system's behavior; it validates no cryptographic module and inspects no key management. Only SC-7 is defensible, and only as egress-boundary evidence -- see SC-7.
AU-2 Event Logging, AU-6 Audit Record Review, AU-9 Protection of Audit Information, AU-11 Audit Record Retention (AU)
AU-2 was a candidate and was dropped on reading it: it enumerates the agency's own audit function -- log-on attempts, permission use on accounts and files, NCIC/III operational transactions. Recorded AI traffic events are not audit records of CJI access, and mapping them invites the reading 'RedLens gives you CJIS audit logging'. RedLens also neither reviews the agency's audit records (AU-6) nor stores or protects them (AU-9, AU-11).
CA-2 Control Assessments (CA)
A candidate in the original scoping, dropped on reading CA-2(d): it requires assessing the controls in the system for correct implementation and intended operation. A red-team scan assesses an AI system's behavior under attack, which is an input to that assessment, not the assessment. CA-7 continuous monitoring is the honest home for this evidence.
IR-4 Incident Handling, IR-5 Incident Monitoring, IR-6 Incident Reporting (IR)
RedLens detects and notifies; the agency handles, tracks, and reports. IR-6 in particular requires reporting to the CSO / SIB Chief / IA Official and the FBI CJIS ISO within one hour -- a chain this platform is not part of. SI-5 is the honest mapping for alert generation and dissemination.
Awareness and Training, Contingency Planning, Maintenance, Media Protection, Physical and Environmental Protection, Planning, Identification and Authentication (AT / CP / MA / MP / PE / PL / IA)
No record on this platform bears on any of them. Included here only so the omission reads as deliberate.
Information Exchange Agreements; Mobile Devices (Policy Areas 1 and 20)
The two policy areas v6.1 still numbers, and the two with no 800-53 equivalent. RedLens observes neither the agency's exchange agreements nor its mobile fleet.

Questions to take to your CSO

Which AI systems touch CJI? Start with an inventory (CM-8). Shadow AI and vendor features you did not switch on count.
What do those systems take as input? Anything a model reads, including uploaded documents and retrieved records, is input under SI-10. Test it for injection.
What can each agent do? List its tools and data access and test whether it can be steered past them (AC-6).
How often is it tested? A schedule with recorded results is what CA-7 asks for; RA-5 sets 15, 30, 60 and 90-day remediation windows by severity.
Who supplies the model? External services and supply-chain controls (SA-9, SR-5) apply to the model vendor as much as to any other provider.

The claim nobody can make

This is the language the RedLens evidence package carries, word for word:

Regarding the FBI CJIS Security Policy specifically: the FBI does not certify products, services, or vendors as CJIS compliant, and no vendor -- RedLens included -- can be 'CJIS certified'. RedLens holds no CJIS authorization or compliance determination of any kind. The agency's CJIS Systems Officer, CJIS Systems Agency, State Identification Bureau, or Interface Agency Official is the authority on that agency's compliance, and the agency remains solely accountable for it. The mappings below cover only the artificial-intelligence portion of an environment that processes, stores, or transmits Criminal Justice Information, and cite CJISSECPOL v6.1 (25 June 2026) cross-referenced to v5.9.5 (9 July 2024); several controls mapped here exist only in v6.x and have no v5.9.5 counterpart. Sanction status shown for each control is transcribed from the policy's own priority markings, under which requirements marked [Existing] or [Priority 1] have been sanctionable since 1 October 2024 and [Priority 2] through [Priority 4] requirements sit in a zero-cycle that ends 30 September 2027. Confirm current sanction status with your CSA before relying on it.

Sources

Every control id, title, marking and section number above was read from the policy PDFs, not reconstructed from secondary summaries.

CJIS Security Policy Version 6.1, dated 25 June 2026, 473 pages. Primary source for all v6.1 control ids, titles, and markings. SHA-256 0e0f0f53db17f2b6408b2ce486fafb84acb0f628f68a794372ef4eb0c87ff4f8, fetched 25 August 2026.
CJIS Security Policy Version 5.9.5, dated 9 July 2024, 451 pages. Last pre-v6 release. Primary source for all v5.9.5 section numbers and for which controls are absent from it. SHA-256 5e780b5217c5b650de0c58bb409118fae53a6cf25c356232616bb0be24e826c1, fetched 25 August 2026.
Requirements Companion Document to the FBI CJIS Security Policy Version 6.1, dated 25 June 2026, 86 pages. Corroboration only -- the Priority / Audit-Sanction columns. Fetched from the Texas DPS public mirror because le.fbi.gov 404s on every RCD filename tried. No entry in this table rests on it alone. SHA-256 09e05733e591a7e6a6ad7ac05cd26a4b5989913eb371697e50872102afb762aa, fetched 25 August 2026.

RedLens for law enforcement See a sample evidence package