Skip to main content
Browse docs
By Audience
Getting Started
Configuration
Use Cases
IDE Integration
Third-Party Integrations
Engineering Cache
Console
API Reference
Gateway
Workflow Guides
Templates
Providers and SDKs
Industry Guides
Advanced Guides
Browse by Role
Deployment Guides
In-Depth Guides
Tutorials
CLI Reference
Policy Reference
OverviewDeclarative Config Reference
Config Deep Dives
Config ProvidersConfig Rate LimitsConfig Routes And ConsumersConfig Quality AssertionsConfig ObservabilityConfig Security NetworkConfig RuntimeConfig TestingConfig Conditional ChainsConfig ScenariosConfig Pack MetadataConfig Execution TargetsConfig Cloud ProvidersConfig Escalation RoutingConfig Data PoliciesConfig Per Policy CatalogConfig Env VariablesConfig Advanced ProviderConfig Compliance PoliciesConfig Single Policy DocsConfig Flagged Review
Policy Controls Catalog
Input Policies
Output Policies
Agent Policies
Audit & Compliance
Audit LoggerData Routing PolicyItar Ear FilterEntity List FilterCjis ModeMnpi Filter
Privacy & Legal
Content & Document Processing
FAQ

CJIS Mode

The cjis-mode policy enforces Criminal Justice Information Services (CJIS) Security Policy requirements for AI systems that access, process, or transmit Criminal Justice Information (CJI). It ensures that every interaction with an LLM provider meets the authentication and audit-logging mandates defined by the FBI CJIS Division, protecting sensitive law enforcement data from unauthorized access and providing a defensible audit trail.

Use this page when​

  • You need the exact command, config, API, or integration details for CJIS Mode.
  • You are wiring automation or AI retrieval and need canonical names, examples, and constraints.
  • If you want a guided rollout instead of a reference page, use the linked workflow pages in Next steps.

Primary audience​

  • Primary: AI Agents, Technical Engineers
  • Secondary: Technical Leaders

Configuration​

policy:
  cjis-mode:
    require_auth: true
    access_logging: true
pack:
  name: cjis-mode-example-1
  version: 1.0.0
  enabled: true
policies:
  chain:
  - cjis-mode

Fields​

FieldTypeDescriptionDefault
require_authbooleanReject unauthenticated requests. The CJIS Security Policy mandates that all access to CJI must be performed by authenticated, authorized users. When enabled, the gateway verifies that every inbound request carries a valid authentication credential (API key or JWT) before forwarding to the upstream LLM provider.true
access_loggingbooleanEnable structured CJIS audit trail. When enabled, the gateway emits a detailed access log entry for every request and response that includes the authenticated user identity, timestamp, data categories detected in the payload, the upstream provider contacted, and the policy decision outcome. These entries are formatted for ingestion by SIEM and compliance-reporting systems.true

Use Cases​

Law Enforcement AI Assistant​

A police department deploys an AI assistant that officers use to draft incident reports and query procedural guidance. Because the assistant may receive details about active investigations, CJIS Mode ensures every request is authenticated and every interaction is logged for internal-affairs review.

policy:
  cjis-mode:
    require_auth: true
    access_logging: true
pack:
  name: cjis-mode-example-2
  version: 1.0.0
  enabled: true
policies:
  chain:
  - cjis-mode

Justice System Case Analysis​

A district attorney's office uses an LLM to summarize case files and identify relevant precedents. Criminal history records and witness statements flow through the gateway, so authentication is mandatory and the audit log captures which attorney accessed which case data and when.

policy:
  cjis-mode:
    require_auth: true
    access_logging: true
pack:
  name: cjis-mode-example-3
  version: 1.0.0
  enabled: true
policies:
  chain:
  - cjis-mode

CJIS-Compliant CJI Query System​

A federal agency integrates an AI-powered search interface over a CJI database. The system pairs CJIS Mode with PII detection and audit logging to form a full compliance stack — authentication gates every query, PII detection prevents accidental CJI leakage to the LLM, and access logging creates the immutable record required by CJIS auditors.

policy:
  cjis-mode:
    require_auth: true
    access_logging: true
  pii-detector:
    action: redact
  audit-logger:
    immutable: true
    retention_days: 365
    log_all_access: true
pack:
  name: cjis-mode-example-4
  version: 1.0.0
  enabled: true
policies:
  chain:
  - cjis-mode
  - pii-detector
  - audit-logger

Minimal Authentication-Only Mode​

An agency that already has a separate audit-logging infrastructure only needs the authentication gate from CJIS Mode. Disabling access_logging avoids duplicate log entries while still enforcing the authentication mandate.

policy:
  cjis-mode:
    require_auth: true
    access_logging: true
pack:
  name: cjis-mode-example-5
  version: 1.0.0
  enabled: true
policies:
  chain:
  - cjis-mode

How It Works​

When a request arrives at the gateway with cjis-mode enabled:

  1. Authentication check — If require_auth is true, the gateway inspects the inbound request for a valid credential (Bearer token or API key header). Requests without a credential, or with an expired or invalid credential, are immediately rejected with a 401 Unauthorized response. The request never reaches the upstream LLM provider.

  2. Identity extraction — For authenticated requests, the gateway extracts the user identity (subject, issuer, and any CJIS-relevant claims) from the credential. This identity is attached to the request context so downstream policies and audit entries can reference it.

  3. Access log emission — If access_logging is true, the gateway emits a structured log entry at both the request and response stages. Each entry includes the authenticated user identity, a UTC timestamp, the upstream provider endpoint, the detected data categories in the payload (e.g., criminal history, biometric data), and the final policy decision (allow, block, redact). These entries are written to the configured event sink (API event ingest, local file, or OTLP exporter).

  4. Pass-through — After authentication and logging, the request continues through any remaining policy checks (PII detection, content filters, etc.) before being forwarded to the upstream provider.

Combining With Other Policies​

CJIS Mode is designed to be the authentication and audit foundation of a broader compliance stack:

  • pii-detector — Detects and redacts CJI categories (SSNs, criminal history records, biometric identifiers) before they reach the LLM provider. CJIS Mode ensures the request is authenticated; PII detection ensures sensitive data is not exfiltrated.
  • audit-logger — Provides additional audit-trail destinations (S3, external SIEM webhook) beyond the built-in access logging. Use both when compliance requires redundant log sinks.
  • content-filter — Blocks prompts or responses that contain categories of content inappropriate for law enforcement use (e.g., instructions for illegal activity). Pairs naturally with CJIS Mode's authentication gate.
  • rate-limiter — Enforces per-user request quotas to prevent credential abuse. Combined with require_auth, this ensures that even authenticated users cannot perform bulk data extraction.

Best Practices​

  • Always enable both require_auth and access_logging in production. The CJIS Security Policy requires both authentication and audit logging for CJI access. Disabling either weakens your compliance posture.
  • Pair with pii-detector to prevent CJI leakage. Authentication alone does not prevent an authorized user from inadvertently sending CJI to an external LLM. PII detection provides a data-loss-prevention layer.
  • Route access logs to an immutable, append-only store. CJIS auditors expect audit records that cannot be tampered with. Configure your event sink to write to a WORM-compliant storage backend or a SIEM with tamper-evident logging.
  • Use short-lived credentials. Prefer JWTs with short expiration windows over long-lived API keys. This limits the blast radius of a compromised credential and aligns with the CJIS least-privilege principle.
  • Review access logs regularly. Automated alerting on anomalous access patterns (unusual hours, high volume, new user identities) helps detect credential misuse before it becomes a compliance incident.
  • Test your policy stack in a staging environment with synthetic CJI data. Validate that authentication failures are correctly rejected, that PII detection catches all relevant categories, and that audit log entries contain the fields your compliance team requires.

For AI systems​

For engineers​

  • Always enable both require_auth: true and access_logging: true in production to satisfy CJIS Security Policy mandates.
  • Pair with pii-detector to prevent CJI categories (SSNs, criminal history, biometric data) from leaking to the LLM provider.
  • Route access logs to an immutable, append-only store (WORM-compliant or SIEM with tamper-evident logging).
  • Prefer short-lived JWTs over long-lived API keys to limit blast radius of compromised credentials.
  • Test with synthetic CJI data in a staging environment to validate authentication rejections and audit log completeness.

For leaders​

  • CJIS Mode enforces the FBI CJIS Security Policy’s authentication and audit-logging mandates for any AI system handling Criminal Justice Information.
  • Combined with PII detection and case-privacy policies, it creates a complete compliance stack for law enforcement AI deployments.
  • Access logging creates a defensible audit trail for CJIS auditors, recording who accessed what data, when, and through which provider.
  • Short-lived credential policy aligns with CJIS least-privilege principles and limits credential-misuse exposure.

Next steps​