โ†
AI for Public Safety & First Responders
Visionary ยท M12 ยท lesson 12 of 16 ยท queued
Preview โ€” browse every lesson free. Enroll to mark lessons complete, open partner links and save your progress. Login & enroll โ†’
Security and the Threat Landscape
๐Ÿ“–
now learning

Security and the Threat Landscape

15 min

At 3:47 a.m. on a Tuesday, the on-call IT supervisor for a county sheriff's department received an automated alert from the agency's intrusion-detection system. A vendor-managed cloud environment that processed body-worn camera (BWC, the recording devices worn on officers' uniforms) footage and hosted the AI report-drafting tool had detected unusual outbound data transfers totaling approximately 340 gigabytes over a six-hour window. The supervisor called the vendor's incident-response line. The line was answered in eleven minutes. By the time the vendor confirmed that the transfer was unauthorized, that it included BWC footage files, associated transcripts, and partially drafted officer reports, and that it had originated from a credential that had been compromised in a spear-phishing attack against one of the vendor's own administrators, four hours had passed. The agency's general counsel was on the phone before 8 a.m. asking one question before any other: were the transferred files criminal justice information as defined under the CJIS (Criminal Justice Information Services, the FBI division that sets federal security standards for criminal justice data) Security Policy? The answer was yes. The next question: did the vendor's environment meet CJIS Security Policy requirements? The answer, after twelve minutes of silence on the line, was that this would require review.

Why Public Safety AI Is a Target

The threat landscape for public-safety AI is not the abstract cybersecurity environment that applies to any enterprise software system. It is a specific, high-value target environment shaped by the nature of the data that public-safety AI processes and the actors who have reasons to seek it. Understanding why the target is valuable is the first step toward building a security posture that matches the threat.

BWC footage, CAD (computer-aided dispatch) entries, AI-drafted police reports, and the associated transcripts and audio files contain information that multiple categories of adversary actively seek. Criminal organizations under investigation have strong incentives to know what evidence exists, what witnesses have been identified, and what the investigative timeline looks like. Intelligence services targeting law enforcement personnel use law enforcement data to identify officers, build dossiers, and create leverage. Ransomware operators targeting government entities have found law enforcement agencies to be productive targets precisely because the operational pressure to restore access to records, dispatch, and evidence systems creates payment incentives that commercial targets often lack. Insider threats within agencies and vendors may seek access to case data for personal gain, for intimidation of witnesses or suspects, or for disclosure to parties with interests in ongoing cases.

The introduction of AI tools adds a new attack surface to each of these existing threats. The AI system itself, the cloud environment in which it operates, the API connections between the AI tool and the BWC platform, the RMS (records management system), and the CAD are all potential entry points. The AI model's training data, if it includes actual case data, is a target. The AI outputs, including drafted reports and summaries, are targets. The credentials that access the AI system are targets. The vendor's own security environment, which may be less hardened than the agency's internal environment, is a target. Each of these adds to the attack surface without being fully visible in the agency's own network monitoring.

The agency's CJIS obligations do not end at the agency's network perimeter. They follow the data. When criminal justice information enters a vendor's environment, the CJIS Security Policy obligations travel with it, and the agency remains accountable for whether those obligations are met.

CJIS Security Policy: What It Requires and Why the Agency Owns It

The CJIS Security Policy is the FBI's comprehensive set of security requirements governing the access, use, and protection of criminal justice information. It applies to any agency that accesses CJIS systems, including the National Crime Information Center (NCIC) and the Interstate Identification Index. It requires specific technical controls, personnel security standards, physical security measures, and audit requirements. What has become critically important in the AI era is the CJIS Security Policy's treatment of cloud computing and third-party vendors.

When an agency deploys an AI tool that processes criminal justice information, including BWC footage associated with arrests, CAD entries related to criminal investigations, or report drafts that incorporate arrest data, in a cloud environment operated by a vendor, the CJIS Security Policy obligations do not transfer to the vendor. They stay with the agency. The vendor may sign a CJIS Security Addendum, which obligates the vendor to comply with specific CJIS requirements in their handling of the data. But the agency's accountability for whether the vendor actually meets those requirements does not diminish. The agency must verify vendor CJIS compliance, must audit that compliance on an ongoing basis, and must be prepared to demonstrate compliance to the FBI's CJIS Systems Agency in the event of an audit or incident.

The Specific CJIS Requirements for AI Environments

Several specific CJIS Security Policy requirements deserve particular attention in the context of AI tool deployment. First, encryption: CJIS requires that criminal justice information be encrypted both in transit and at rest. An AI tool that transmits BWC audio or text transcripts to a vendor cloud environment without end-to-end encryption that meets CJIS standards is in violation of the Security Policy, regardless of what the vendor's general security documentation says. The agency must confirm, in writing, before deployment, that the AI tool's data transmission and storage meets CJIS encryption requirements.

Second, access control: CJIS requires that access to criminal justice information be limited to authorized personnel, with role-based access controls, multi-factor authentication for remote access, and a documented least-privilege standard. An AI tool that allows vendor administrators to access criminal justice information without individual authorization, background clearance, and multi-factor authentication is in violation of the Security Policy. The vendor's own administrative access to the environment that processes criminal justice information must meet CJIS personnel security requirements, including the relevant background check standards.

Third, incident reporting: CJIS requires that security incidents involving criminal justice information be reported to the CJIS Systems Agency within a defined timeframe. An agency that learns of a breach in a vendor environment involving criminal justice information must report that breach within the required window, regardless of whether the agency or the vendor was the primary victim of the attack. The agency cannot delegate the reporting obligation to the vendor. The agency must know, before deployment, that its vendor contracts require immediate notification of any security incident, and that the agency's own incident response plan covers the vendor-environment scenario.

Fourth, audit logs: CJIS requires that access to criminal justice information be logged and that those logs be retained for a defined period and be available for audit. An AI tool that does not produce granular access logs, or that produces logs that are retained only in the vendor environment and not available to the agency, does not meet the CJIS audit-log requirement. The agency must have access to the logs from its own systems, including the AI systems it deploys, without having to request them from the vendor after the fact.

The Threat Landscape: Actors and Attack Vectors

Effective security design requires a realistic picture of the specific threats the agency faces. This is not a generic enterprise cybersecurity threat landscape. Public-safety agencies face a specific set of actors with specific motivations and specific capabilities that shape which attack vectors are most likely to be exploited.

Ransomware and Criminal Operators

Ransomware attacks against law enforcement agencies have increased substantially in recent years, and AI tool deployment has expanded the attack surface available to ransomware operators. The most effective ransomware attacks against law enforcement agencies have targeted the systems with the highest operational urgency: dispatch systems, evidence management platforms, and report systems. When those systems are unavailable, the agency faces immediate operational pressure to restore access. The introduction of AI tools that integrate with those systems, often through vendor-managed cloud environments with broader network connectivity than the agency's own hardened internal systems, creates new entry points for ransomware operators.

The defense against ransomware in an AI-integrated environment requires several specific measures. Network segmentation: the AI tool's data pathway should be isolated from the agency's core operational systems so that a compromise of the AI environment cannot cascade into dispatch or CAD system outages. Offline backup: criminal justice information and case data that is processed by AI tools must have air-gapped backup copies that cannot be encrypted by ransomware. Vendor incident response: the agency's contract with the AI tool vendor must specify that the vendor has a tested ransomware incident-response plan and that the agency has access to the vendor's incident response team within a defined timeframe. The scenario described in the opening of this lesson, an eleven-minute response to an automated alert and a four-hour investigation, may be acceptable for some business environments but is not acceptable for a law enforcement agency facing a potential CJIS breach.

Spear-Phishing and Credential Compromise

The attack described in the opening of this lesson, a spear-phishing attack against a vendor administrator that compromised credentials with access to the AI tool's environment, is the most common initial access vector in targeted attacks against law enforcement data. Vendor administrators who have access to environments processing criminal justice information are high-value targets for spear-phishing campaigns, because compromising a single vendor administrator credential can provide access to data from multiple agencies simultaneously.

Defense against credential compromise in AI environments requires multi-factor authentication for all administrative access, with hardware tokens or equivalents rather than SMS-based authentication (which is vulnerable to SIM-swapping attacks). It requires privileged access management: vendor administrators should not have persistent access to criminal justice information environments but should access them through a just-in-time provisioning system that requires a specific authorization for each access session. It requires monitoring of administrative access sessions, with automated alerts for access outside business hours, access from unusual locations, and data transfers above baseline volumes.

Insider Threats: Vendor and Agency

Insider threats in AI-integrated environments take two forms. The agency insider is a staff member who uses their legitimate access to the AI system to access data beyond their authorized scope, to exfiltrate data for personal gain or to benefit a party with an interest in a case, or to manipulate AI outputs in a case they have an interest in. The vendor insider is a vendor employee who uses their access to the vendor's environment, which includes data from multiple agency clients, for similar purposes or for competitive intelligence.

Defense against insider threats requires behavioral monitoring of data access: access to cases the employee is not assigned to, bulk downloads of case data, access outside normal working hours, and other behavioral indicators of unusual activity. It requires audit logs that are maintained outside the agency's own network, so that an insider who can access the internal system cannot also delete the logs. And it requires a clear separation between the staff who operate the AI tools on a day-to-day basis and the staff who audit the AI system's outputs and access logs, so that operational staff cannot self-clear an audit finding.

Adversarial Inputs and Model Attacks

AI systems face a category of attack that has no analog in traditional enterprise software: adversarial inputs. An adversarial input is data specifically crafted to cause an AI model to produce an incorrect or desired output. In the public-safety context, a sophisticated adversary might craft audio input that is designed to cause the AI report-drafting tool to omit a specific detail from its output, include a specific inaccurate detail, or classify a specific event differently than the audio actually recorded. This is not a widely deployed attack vector in 2026, but it is a documented capability in the AI security research literature, and an agency whose AI tools will be used in high-stakes criminal proceedings should be aware that its AI systems are potential attack surfaces in ways that its word processors are not.

Defense against adversarial inputs requires the footage-grounded verification pass that the agency's AI use policy mandates: an officer who actively checks every factual claim in the AI draft against the BWC footage and the CAD entry will catch an adversarial manipulation of the AI output in the same way they would catch a hallucination or a gap-fill. The verification standard is both an accuracy control and a security control. This convergence is not accidental: the same discipline that protects evidentiary integrity also protects against a specific class of security attack.

Vendor Security: The Questions to Ask Before You Sign

The multi-year, bundled contracts that are being signed in the public-safety AI market, contracts in the range of 45 million dollars for packages combining BWC hardware, cloud storage, AI report drafting, drone integration, and analytics, are not reversible decisions. An agency that signs a 10-year contract with a vendor that does not meet CJIS security requirements has committed to a decade of non-compliance, or to the cost and disruption of early termination. The security questions must be answered before the contract is signed.

The CJIS Compliance Questions

Every vendor that will process criminal justice information must provide, before contract signature, written documentation that their environment meets the current CJIS Security Policy requirements. Specific questions: Has the vendor completed a CJIS Security Policy compliance assessment? Can the vendor provide the assessment documentation? Has the vendor signed a CJIS Security Addendum acceptable to the agency's CJIS Systems Agency? Is the vendor's compliance assessment current (within the past 12 months)? Does the vendor maintain separate environments for CJIS-subject data versus other data? Does the vendor have a documented process for notifying the agency of CJIS breaches within the required timeframe?

A vendor that cannot answer these questions with documentation before contract signature is not a vendor that can meet the agency's CJIS obligations. "We are in the process of completing our CJIS assessment" is not an acceptable answer when the agency's data is already in the vendor's environment. The agency's legal counsel must review the CJIS Security Addendum before signature, confirm that its terms are consistent with the current CJIS Security Policy, and confirm that the agency's auditors will have access to the vendor's compliance records for the duration of the contract.

The Incident Response Questions

The vendor's incident response capability is as important as their security controls. Security controls fail. The question is not whether the vendor will ever have a security incident but whether, when an incident occurs, the agency's data is protected as effectively as possible and the agency is notified within the timeframe required by the CJIS Security Policy. Specific questions: What is the vendor's maximum response time for a security incident alert? What constitutes a reportable incident under the vendor's contract, and does the definition align with the CJIS Security Policy's incident definition? What is the vendor's forensic capability, and will they provide the agency with a complete forensic report after any incident? Does the vendor carry cyber insurance that covers incidents involving criminal justice information, and does the coverage include the agency's costs associated with the incident?

The Data Governance Questions

The agency's data governance requirements must be spelled out in the contract, not assumed from vendor representations. Specific questions: Who owns the data processed by the AI tool, and is that ownership unambiguous in the contract? Can the vendor use agency data to train or improve the AI model, and if so, under what conditions and with what agency consent? What is the retention period for agency data in the vendor's environment, and who controls the deletion process? In the event of contract termination, what is the process for data return or deletion, and is the process documented in the contract? Does the vendor's contract include a right of audit, allowing the agency to verify data handling practices independently?

Data governance questions are particularly important for AI tool vendors because AI systems, unlike traditional software systems, may improve their models using data from operational deployments. A vendor whose contract allows them to use BWC audio, officer reports, or case data from the agency's operational deployment to train a general model that is then licensed to other agencies has created a data-governance problem that implicates both CJIS (if the data is criminal justice information) and privacy law (if the data includes information about community members). The contract must foreclose this possibility explicitly, not implicitly.

Building the Agency's Security Posture for AI

A security posture for AI-integrated public-safety operations is not a separate security program. It is an extension of the agency's existing security program, adapted for the specific attack surface and threat landscape that AI tool deployment creates. The adaptations required are specific and implementable, and they do not require a security budget that is separate from the agency's existing IT security allocation. They require the existing security program to be updated for the new environment.

The five adaptations the agency's security posture must make for AI tool deployment are: adding the AI tool's vendor environment to the network monitoring scope, even if the vendor environment is not on the agency's internal network; adding AI administrative credentials to the privileged access management program, with the same multi-factor authentication and just-in-time provisioning requirements that apply to other high-privilege credentials; adding the AI tool's data pathways to the encryption audit, confirming that CJIS encryption requirements are met end-to-end; adding AI-related incidents (including adversarial-input attempts and vendor-environment anomalies) to the incident response plan; and adding vendor CJIS compliance to the annual security audit, not just the initial deployment assessment.

The security posture update must be documented. The agency's security documentation, including its policies, procedures, and audit records, must reflect the AI tool deployment. An agency whose security documentation was written before AI tool deployment and has not been updated to reflect the new environment does not have an accurate security posture documented, which means that neither the agency's internal auditors nor the FBI's CJIS auditors can accurately assess compliance.

Key Takeaways

  • Public-safety AI systems are high-value targets because the data they process, BWC footage, CAD entries, arrest records, and AI-drafted reports, is sought by criminal organizations, intelligence services, ransomware operators, and insider threats with interests in specific cases.
  • CJIS Security Policy obligations do not transfer to the vendor when the agency deploys AI tools in a vendor cloud environment. The obligations stay with the agency. The agency must verify vendor CJIS compliance before deployment, audit it on an ongoing basis, and report CJIS incidents on the required timeline regardless of whether the breach originated in the vendor's environment.
  • The four specific CJIS requirements that most commonly create gaps in AI tool deployments are encryption (in transit and at rest), access control (role-based, multi-factor, least-privilege), incident reporting (within required timelines, by the agency, not just the vendor), and audit logs (granular, retained, and available to the agency without requiring a vendor request).
  • The four primary threat actors in the public-safety AI threat landscape are ransomware operators exploiting vendor cloud environments as entry points, spear-phishing campaigns targeting vendor administrators with access to multi-agency data, insider threats at both the agency and vendor level, and adversarial-input attacks designed to manipulate AI output in high-stakes cases.
  • The footage-grounded verification pass is both an accuracy control and a security control. An officer who actively checks every factual claim in the AI draft against the BWC footage and the CAD entry will catch an adversarial manipulation of the AI output by the same process that catches a hallucination or gap-fill.
  • Multi-year, bundled vendor contracts on the order of 45 million dollars for 10-year terms require full security due diligence, including documented CJIS compliance assessment, incident response time guarantees, data-ownership and data-use restrictions, and a right of audit, before signature. A contract that does not embed these requirements commits the agency to a decade of exposure.
  • Vendor data-use provisions that would allow the vendor to use agency BWC audio, case data, or officer reports to train a general AI model are a CJIS compliance problem if the data is criminal justice information and a privacy problem if it includes community-member information. Those provisions must be foreclosed explicitly in the contract, not assumed to be absent.
  • The agency's security documentation, including policies, procedures, and audit records, must be updated to reflect AI tool deployment. An agency whose security documentation predates its AI tool deployment and has not been updated does not have an accurate security posture, and cannot demonstrate CJIS compliance to an auditor or oversight body.