CodeBlu Security and Privacy Reference

A factual reference for the information-security and IT staff who must sign off on CodeBlu before it is deployed in an agency.

This document describes CodeBlu's architecture, data handling, and compliance position as built. It is written for the person whose job is to find the problems, not to be reassured. Where CodeBlu does not meet a standard an agency may expect, that is stated directly. Items that should be confirmed in writing with the vendor before a contract is signed are flagged.

---

1. What CodeBlu is, in security terms

CodeBlu is a hosted, multi-tenant web application. Officers sign in through a browser and hold a spoken conversation with an AI agent that plays a person in crisis. After the conversation, a transcript is processed by an AI model to generate an after-action review with performance scores. The application also stores training records, issues completion certificates, and produces training-hour summaries.

From an IT perspective, three properties define the risk picture. First, CodeBlu is software-as-a-service: the agency does not host it, and the agency's data lives on infrastructure CodeBlu controls. Second, it is multi-tenant: multiple agencies share the same database, and tenant segregation is enforced in software, not by physical separation. Third, it depends on third-party AI services that receive training content, including session transcripts. Each of these is examined below.

CodeBlu is operated by Yunto Group LLC, doing business as CodeBlu, a Colorado company. CodeBlu is a new product. An IT decision-maker should weigh that the way Section 7 describes.

---

2. Architectural overview

CodeBlu is a modern web application. The major components and the third-party service categories it depends on are described below by function. The current, named subprocessor list is available to agencies under a non-disclosure agreement; email privacy@codeblu.co to request it.

Application hosting. The web application is hosted on a managed application-hosting platform. All routes are served over HTTPS.

Database, authentication, and storage. CodeBlu uses a managed PostgreSQL platform for its database, user authentication, and file storage. Agency and training data are stored in this managed database. CodeBlu states that platform data is stored in United States infrastructure.

Voice AI. The spoken training conversations are delivered by a third-party conversational voice AI provider. The audio of the scenario and the conversation content pass through that provider.

After-action review AI. After a session, the conversation transcript is sent to a third-party large language model provider to generate the after-action review: the scores, strengths, areas to improve, and suggested alternative phrasings.

Transactional email. Where enabled, CodeBlu uses a managed transactional email provider to deliver transactional email such as sign-in links and notifications.

Sign-in protection. CodeBlu uses a managed bot-protection mechanism on the sign-in flow.

Internal operations. CodeBlu uses a managed productivity suite for its own internal email and productivity.

The practical takeaway: a single CodeBlu training session touches the application host, the database platform, the voice provider, and the AI model provider. An agency's security review is therefore a review of CodeBlu plus those subprocessors. Section 4 addresses the subprocessor question directly. The full, current named subprocessor list, with each subprocessor's function, is available to agencies on request to privacy@codeblu.co and should be attached to the contract.

---

3. Data handling and storage

3.1 What CodeBlu collects

Account information. When an officer or administrator is added, CodeBlu collects an email address and may collect a display name, badge number, state peace-officer certification number, agency affiliation, role, and hire date.

Authentication. Sign-in uses an email magic-link. CodeBlu does not store user passwords. This removes one common breach vector, the password database, and shifts the security boundary to the officer's email account and the magic-link delivery path.

Training data. CodeBlu stores records of training activities, voice-scenario sessions, session transcripts, performance scores and after-action review results, officer self-ratings, certificates issued, and per-year training-hour summaries.

Voice and transcript data. Each scenario is a voice conversation. A text transcript of each conversation is created and stored, and is used to generate the after-action review. Whether scenario audio, as distinct from the text transcript, is retained anywhere by the voice provider is a question CodeBlu's own privacy draft flags as needing confirmation.

Inquiry and technical data. Public contact-form submissions and standard technical data such as IP address and user-agent string are also collected.

CodeBlu states it does not intentionally collect special categories of personal data. Note a residual risk specific to this product: because scenarios are open-ended voice conversations, an officer could speak sensitive information into a session that then becomes part of a stored transcript. The agency's own user guidance should tell officers not to introduce real personal or case information into training scenarios.

3.2 Where data is stored and how it is protected

Database records are held in the managed Postgres database described in Section 2. CodeBlu's stated controls are: row-level security so users can access only the records they are permitted to see, access controls, encryption in transit, and provider-side encryption at rest.

The most security-relevant control is row-level security (RLS). CodeBlu's database enforces tenant segregation through RLS policies keyed to agency membership: an officer can read only their own training records, and a trainer or administrator can read records only for officers within their own agency. System-level writes, such as the after-action review generation, run with a separate privileged credential. This is a sound design pattern for multi-tenant data. Its weakness is that segregation is enforced entirely in software, so a misconfigured or missing policy on any one table is a potential cross-tenant exposure. An agency should ask CodeBlu whether RLS policy coverage is verified by an automated test, and whether any independent party has reviewed it.

CodeBlu's own privacy draft flags that all security representations should be confirmed before publication, because overstated security claims create liability. An agency should treat the security claims above as the vendor's representations to be confirmed in the contract, not as audited facts.

3.3 Data retention

By default, training session data, transcripts, and after-action review results are retained for 90 days. An agency administrator may configure a longer retention period. Account records and issued certificates are retained for the duration of the agency relationship.

A 90-day default is short. For an agency using CodeBlu toward a state in-service requirement, the underlying records may need to be retained far longer than 90 days to satisfy training-records or public-records retention law. CodeBlu's own privacy draft flags this conflict. This is an agency action item, not only a vendor question: the agency owns the records obligation.

3.4 Access

Four categories of party can access agency data: the officer, for their own records; the agency's administrators and trainers, for officers within their agency; a limited number of CodeBlu personnel, to operate and support the service; and the third-party subprocessors, to perform their specific functions. An agency should ask CodeBlu how staff access is controlled and logged, and whether administrative access to production data is restricted and audited.

---

4. The AI subprocessor question

This is the single most important section for an IT reviewer, because it is the part of CodeBlu's design that has no equivalent in conventional courseware.

To deliver the product, CodeBlu sends training content to two AI subprocessors: a conversational voice AI provider and a large language model provider. The voice conversation runs through the voice provider; the resulting transcript is sent to the model provider to generate the after-action review. This means session transcripts, which can contain an officer's spoken performance in a sensitive scenario, leave CodeBlu's database and are processed by two external companies. The named identities of those two providers are disclosed under NDA on request to privacy@codeblu.co and are written into the contract.

The questions an agency must get answered, in writing, before contracting:

1. What exactly does each AI subprocessor receive: audio, text transcript, or both?
2. Does either subprocessor retain that data, and for how long?
3. Can either subprocessor use that data to train or improve its own models?
4. Is there a data processing agreement in place between CodeBlu and each subprocessor that contractually restricts retention and model training?

CodeBlu's own privacy and legal review drafts identify this exact issue as an open item: the company notes that the data-residency, retention, and model-training terms of both AI subprocessors must be confirmed and disclosed, and that a data processing agreement is needed with each subprocessor.

The major commercial AI providers generally offer business and enterprise terms under which customer data submitted through the API is not used to train their models, but the terms that apply are the terms in CodeBlu's specific agreements, and those are what the agency must see. Do not accept a general statement that "providers do not train on customer data." Ask for the specific contractual commitment.

---

5. Compliance positioning

5.1 SOC 2

SOC 2 is an attestation, performed by an independent auditor, that a service organization's controls for security and related criteria are designed and operating effectively. It is published by the AICPA and is the most common security attestation a SaaS vendor presents to a cautious buyer (AICPA, SOC 2 overview).

CodeBlu does not currently hold a SOC 2 attestation. CodeBlu describes a SOC 2 compliance path as a future roadmap item. An agency should treat CodeBlu as a vendor without a current third-party security attestation and weigh that accordingly. The absence is not unusual for an early-stage vendor, but it does mean the agency cannot rely on an independent auditor's work and must do its own diligence using this document and the RFP questions in the companion materials. If a SOC 2 timeline matters to the agency, get the vendor's target date in writing and treat slippage as expected.

5.2 CJIS considerations

The FBI's Criminal Justice Information Services (CJIS) Security Policy sets the security requirements for systems that store, process, or transmit Criminal Justice Information (FBI CJIS Security Policy Resource Center). CJIS obligations attach to the data, specifically to Criminal Justice Information, not automatically to every vendor an agency uses.

CodeBlu describes CJIS alignment as planned, not implemented. The practical question for an agency is therefore whether CodeBlu, as the agency intends to use it, will hold Criminal Justice Information at all. CodeBlu is a training product. If officers train only on CodeBlu's built-in fictional scenarios and do not enter real case data, real subject information, or other Criminal Justice Information into the system, the agency may conclude that CJIS scope is not triggered. If the agency intends to use CodeBlu's document-upload feature to load real agency materials, or if officers might speak real case details into scenarios, the analysis changes. The conservative and recommended posture: instruct officers in writing not to enter real case or subject information into CodeBlu, and treat the system as holding training records and fictional-scenario content only.

5.3 Privacy law

CodeBlu's privacy policy is, by the company's own account, a draft pending attorney review. One open question in that draft is directly relevant to an agency: whether CodeBlu acts as a data controller or as a data processor for agency training records. For a government training deployment, CodeBlu is most plausibly a processor handling records on the agency's behalf, which makes the agency responsible for the records and for responding to certain data-subject requests.

---

6. Vendor risk assessment

CodeBlu is a new product from a small company. That carries specific risks an IT decision-maker should account for, independent of the product's technical quality.

Continuity risk. A small vendor may cease operations, be acquired, or change its product direction. Because CodeBlu would hold the agency's training-compliance records, the agency needs a defined way to get those records out and a defined outcome for its data if CodeBlu goes away. Require, in writing: a data-export commitment that works on the agency's timeline, and a data-deletion commitment on termination.

Concentration risk. CodeBlu depends on several third parties. An outage or a policy change at the voice provider, the AI model provider, or the hosting platform affects CodeBlu and therefore the agency. This is normal for SaaS, but it should be understood, not discovered later.

Maturity risk. CodeBlu's security representations, privacy policy, and contract terms are, by the company's own documentation, still being finalized and reviewed. An agency contracting now is contracting with a product whose formal documents are in motion. The mitigation is to pin the specifics into the contract: the subprocessor list, the retention setting, the security commitments, the breach-notification commitment, and the exit terms, so the agency relies on the contract rather than on draft documents.

None of this disqualifies CodeBlu. It argues for a structured pilot under a short initial term, with the protections above written into the agreement, rather than an open-ended enterprise commitment.

---

7. What to require before signing

An IT decision-maker should not approve CodeBlu until the following are in hand, in writing, as contract terms or attachments:

1. The current, complete subprocessor list, with each subprocessor's function.
2. The data processing agreements between CodeBlu and its AI subprocessors, and confirmation of whether agency transcripts can be retained or used for model training.
3. Confirmation of the data-storage location and a data-residency commitment.
4. The breach-notification commitment, with a stated timeframe.
5. A data-export-on-exit commitment and a data-deletion-on-termination commitment.
6. The data-retention configuration the agency will use, set to satisfy the agency's own records-retention obligations.
7. The vendor's SOC 2 timeline, if a SOC 2 attestation matters to the agency.
8. A written agency policy, issued to officers, that no real case data, subject information, or other Criminal Justice Information is to be entered into CodeBlu.

A deployment that satisfies these eight points is a defensible one for a pilot. A deployment that cannot is not ready.

---

Sources

• AICPA, SOC 2 reporting overview: https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2
• FBI Criminal Justice Information Services (CJIS) Security Policy Resource Center: https://le.fbi.gov/informational-tools/cjis/cjis-security-policy-resource-center
• National Institute of Standards and Technology, security and privacy controls reference (NIST SP 800-53): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• Cloud Security Alliance, Consensus Assessments Initiative Questionnaire (a vendor security questionnaire format): https://cloudsecurityalliance.org/research/caiq

This document describes CodeBlu's architecture and stated practices as understood at the time of writing. Security representations are the vendor's to confirm. This is not legal advice; route contract and compliance questions to agency counsel and to the agency's CJIS Systems Officer.