Security Disclosure

Flash AI Security Whitepaper

Technical reference for security, privacy, and trust practices.

Version 1.3 · April 2026

This document describes how Flash AI designs, builds, and operates its platform with a security-first posture suitable for criminal justice and other sensitive environments. It reflects practices implemented across our application services, infrastructure-as-code, and supporting systems. Specific scale metrics (for example counts of buckets or clusters) change over time; underlying controls remain consistent.

1. Executive summary

Flash AI delivers investigative software (including Flash PD, Flash Signal / Chat, and related capabilities) with:

  • AWS GovCloud (US) as the primary cloud boundary for production workloads aligned to stringent customer requirements.
  • Strong authentication via Amazon Cognito (password verification and MFA at the identity provider), combined with server-side application sessions, CSRF protection, and bounded session lifetime in the API tier.
  • Encryption in transit (customer paths negotiate TLS 1.3 when clients support it, with TLS 1.2 for compatibility; legacy TLS versions disabled on load balancers) and encryption at rest using AWS KMS and service-native encryption (object storage, managed databases, secrets, and others as deployed).
  • Least-privilege IAM for runtime workloads (for example ECS task roles scoped to named resources) and short-lived federation for automation (for example OIDC-based CI/CD to AWS roles in Terraform-managed infrastructure).
  • Defense in depth at the edge where deployed (for example AWS WAF in front of the primary API load balancer, with logging to protected storage).
  • Auditability through AWS CloudTrail and application-level audit patterns (including tamper-evident log chaining where implemented).
  • Ongoing compliance operations through Vanta for SOC 2 and CJIS Security Policy–aligned programs, with a public trust center on Vanta for published security and privacy materials.

Customer agencies remain responsible for their own governance, identity federation choices, endpoint management, and contractual subprocessors outside Flash’s direct control.

2. Trust principles and data handling

2.1 Customer data and AI

Flash’s commitments to customers include:

  • No use of customer content to train generalized AI models for unrelated purposes.
  • No cross-organization data sharing through the product.
  • No third-party exposure of customer evidence outside agreed processing boundaries.

Operational enforcement is backed by architecture (tenant-scoped application logic, access controls, and logging) and contractual terms with customers.

2.2 CJIS alignment

Flash aligns security controls with CJIS Security Policy themes that customers expect in this market: identification and authentication, access control, audit and accountability, encryption, configuration management, and incident response. Formal assessment artifacts are maintained separately from this whitepaper.

2.3 Vanta and automated compliance

Flash uses Vanta to run continuous compliance automation across the security and operational controls that matter for both SOC 2 (Trust Services Criteria) and CJIS-oriented assurance. The platform connects to our environment and workflows where configured, runs automated tests and evidence collection, tracks control ownership and remediation, and keeps compliance work aligned with how we actually ship software—rather than relying on point-in-time spreadsheets alone.

  • SOC 2: Vanta supports Flash’s SOC 2 program—mapping controls to criteria, gathering evidence for examinations or attestation as applicable, and maintaining visibility into readiness between audit cycles.
  • CJIS: The same operating model supports CJIS-aligned control areas (for example identity, access, encryption, logging, change management, and personnel practices) alongside internal policies and engineering artifacts, so control health is monitored continuously and issues can be addressed before they surface only in a periodic review.

Trust center: For published policies, subprocessors, and framework-related updates Flash chooses to share with customers and prospects, see the Flash AI Trust Center on Vanta.

3. Identity and access management

3.1 Amazon Cognito (production identity provider)

End-user authentication for Flash PD and Flash Signal flows through Amazon Cognito in GovCloud. Our core API documents that:

  • Passwords are verified through Cognito, not by storing reversible passwords in the application database.
  • MFA is enforced when the user’s Cognito profile requires it (SMS, authenticator apps / TOTP, and MFA setup flows).
  • Cognito remains the authoritative identity provider while the API maintains server-side session state for secure, cookie-based access.

Detailed session and endpoint behavior is documented internally for security reviews and customer due diligence.

3.2 Application sessions, cookies, and CSRF

The API issues HttpOnly session cookies and a separate CSRF cookie. In production, session cookies are marked Secure. Cookie SameSite policy is tuned for development vs production cross-site needs.

State-changing requests (for example POST, PUT, PATCH, DELETE) require a CSRF token in a dedicated header matching the CSRF cookie, reducing cross-site request forgery risk for cookie-authenticated clients.

3.3 Session lifetime and inactivity controls

Documented product behavior includes:

  • A hard maximum session window (for example twelve hours from initial sign-in), after which refresh and protected calls require full re-authentication.
  • Server-side token refresh without returning raw identity tokens to the browser.
  • Inactivity unlock as a separate path that requires MFA and does not reset the hard session cutoff.
  • Encrypted storage at rest for recoverable session material tied to the identity provider, using secrets from managed secrets storage.

3.4 Role-based access control (RBAC)

Authorization is role- and permission-based inside the application: users belong to facilities, roles map to named permissions (for example case access and facility user administration), and platform administrators are explicitly identified. Administrative actions (for example user provisioning) are checked in the API layer.

3.5 Chat and real-time services

Our chat backend mirrors Cognito-based sign-in, MFA challenges, HttpOnly session cookies, and audit logging patterns consistent with the rest of the platform, including optional loading of configuration from AWS Secrets Manager at startup.

4. Encryption and cryptography

4.1 Data in transit

Customer-facing HTTPS is terminated on Application Load Balancers using AWS Certificate Manager (ACM) certificates with automatic renewal.

  • Protocol baseline: Browsers and integrations negotiate TLS 1.3 when supported; TLS 1.2 remains available where needed for client compatibility. TLS 1.0 and TLS 1.1 are disabled on these listeners.
  • Cipher suites: Load balancers use AWS TLS security policies that restrict algorithms to modern, forward-secret options (for example AEAD ciphers with TLS 1.3). AWS policy identifiers sometimes include a catalog date in the name (for example …-2021-06); that suffix marks an AWS policy bundle revision, not the TLS protocol era in use.
  • HTTPS-only patterns: HTTP is not used for production customer traffic; listeners redirect or reject cleartext as configured per service.
  • Certificates: Production hostnames are covered by ACM-issued certificates. Public-key algorithms and key sizes follow current ACM issuance practices and align with common criminal-justice and enterprise security reviews.

Listener-level policy names, certificate inventories, and auditor-facing mappings (for example control AC-17(2) evidence in Flash’s compliance library) are updated on a configuration cadence; they are not duplicated in this whitepaper so the public document stays accurate as AWS catalogs evolve.

Service-to-service traffic to AWS APIs uses TLS. Where policy requires it, workloads use FIPS-capable AWS endpoints (for example for selected batch and integration jobs).

4.2 Data at rest

Flash uses AWS-managed and customer-managed KMS keys across the estate. Typical patterns include:

  • Object storage (S3) with server-side encryption (managed keys or KMS).
  • Relational databases (RDS / Aurora) with storage encryption via KMS.
  • DynamoDB with encryption at rest (default or KMS-backed where configured).
  • Secrets Manager secrets encrypted with KMS.
  • Block storage (EBS) encrypted where provisioned.
  • Kubernetes (EKS) envelope encryption for cluster secrets where enabled.
  • CloudTrail log encryption and integrity validation.

Exact resource counts evolve with infrastructure changes; encryption defaults are enforced in Terraform modules.

4.3 Application-level cryptography

Beyond AWS-managed encryption:

  • Strong password hashing is used for non-Cognito flows such as export verification material.
  • Audit hash chains in chat services use a server-side secret to detect tampering with user-visible audit exports.

5. Network security and edge protection

5.1 AWS WAF

The primary API uses an AWS WAF Web ACL on its load balancer, managed as code. WAF logs can be written to dedicated, encrypted storage with lifecycle rules for long-term retention.

5.2 VPC and segmentation

Workloads run in VPCs with security groups and network controls defined in Terraform across services (API, chat, databases, and batch workers). Least exposure is the default: only load balancer and required management paths are open; database and cache endpoints are not exposed to the public internet.

5.3 Caching layer (ElastiCache)

Managed Redis clusters support at-rest encryption (KMS) and encryption in transit when enabled; chat and queue services are configured to use TLS-protected cache connections in production-style deployments.

6. Least privilege and IAM

6.1 ECS task roles

Terraform-managed task roles for container workloads are designed for CJIS-oriented, least-privilege access. They use scoped policies for:

  • Only the S3 buckets and prefixes required by the service.
  • Only the Secrets Manager secrets required by the task.
  • KMS decrypt/encrypt within key policies that allow the workload.
  • Optional access to queues, functions, media processing, and AI services—each gated so unused permissions are not attached.

AWS managed-policy attachment limits are respected; large resource lists use inline policies where needed to stay within IAM quotas.

6.2 Deny insecure transport

Task roles include deny rules for non-TLS AWS API usage where implemented, reducing accidental cleartext SDK calls.

6.3 CI/CD and OIDC

GitHub Actions (and similar automation) use OIDC to assume AWS IAM roles for infrastructure deployments—no long-lived AWS access keys in CI where this pattern is adopted. Trust policies restrict audience, organization, and repository context.

6.4 Kubernetes (EKS) and IRSA

Kubernetes deployments for inference and supporting services configure an OIDC provider for IAM Roles for Service Accounts (IRSA), allowing per-workload least privilege instead of sharing node-wide credentials.

7. Secrets and configuration management

7.1 AWS Secrets Manager

Production services load database connection information, API keys, and session secrets from AWS Secrets Manager (structured per environment). Application images do not embed long-lived secrets; tasks load secrets at runtime or via task definition integration.

7.2 Environment separation

Development and production are isolated AWS accounts and/or environments with distinct roles, storage, databases, and Cognito user pools, reducing cross-environment blast radius.

8. Logging, monitoring, and audit

8.1 CloudTrail and AWS logging

CloudTrail captures control-plane activity (IAM, KMS, Secrets Manager, and other APIs) for detective controls and compliance evidence. WAF, load balancer, and CloudWatch logs support incident response and security monitoring.

8.2 Application audit trails

  • The core API maintains structured auth and security-relevant events per internal documentation and product routes.
  • Chat services persist audit log entries with hash-chained integrity, with APIs to export and verify audit history for authorized users.

8.3 Vulnerability and configuration scanning

Infrastructure repositories use static analysis (for example Checkov) and review practices to document intentional design choices where automated rules do not match the architecture (for example WAF attached outside a default load-balancer module).

9. Secure development lifecycle

  • Infrastructure as code: Terraform modules; changes reviewed via pull requests.
  • Dependency management: Locked dependency manifests per language ecosystem.
  • Least-privilege defaults in IAM modules reduce the impact of a compromised task.
  • Documentation: Authentication and security behavior is written down so reviews do not depend solely on reading code.

10. Business continuity and availability

Flash operates multi-AZ patterns where services are stateless behind load balancers; databases and caches use AWS resilience features per module design. Customer-facing status and incident communication may be offered via dedicated pages or APIs depending on deployment—refer to current Flash AI communications for live status.

11. Personnel and access governance

Internal access to production systems follows onboarding and termination procedures documented in Flash’s compliance library (for example employee termination checklists covering cloud access, source control, collaboration tools, corporate identity, and managed devices including remote wipe). Operational detail is maintained in internal policy documents; this whitepaper summarizes the security outcomes those procedures support.

12. Contact

For security questions, third-party assessments, or disclosure coordination, use Security & Trust or Contact on this website, or reach your Flash account executive.