One production platform.
Verifiable controls, not adjectives.
InsureIQ is Rosie AI's first production-designated industry platform, while BOB Training is a module within the Rosie AI ecosystem rather than a separate production platform. This page states what the build actually does about encryption, key custody, tenant isolation, data handling and third-party exposure, and what still has to be proven by someone other than us.
Limits of this model, stated up front
- This is not an independently audited, operator-proof zero-knowledge product. The operator controls which JavaScript is delivered and could change future builds.
- An administrator must share the vault passphrase with authorized colleagues. Anyone holding it can decrypt that organization's content, and support cannot recover a lost passphrase.
- During a live call, selected decrypted text is sent to the configured speech and language providers so the assistant can answer. That leg is not end-to-end encrypted to the customer device.
- Do not place regulated records such as PHI in the vault until provider agreements, retention terms and an independent security test are complete.
InsureIQ is Rosie AI's first production-designated platform. BOB is a training module.
BOB Training is a module rather than a standalone production platform. Its access controls and data boundaries must be verified in each deployment. InsureIQ is the first platform targeted for production; other Rosie AI applications remain beta until individually validated.
Public-source discovery, enrichment and lead qualification
Public post and comment text, discovered contact details, intent scores
Master contact records, lists, folders and opt-in or opt-out status
Names, phone numbers, email addresses, tags, consent flags
Drip sequences, batch event campaigns, schedules and send limits
Campaign definitions, message templates, per-contact enrollment state
Message delivery through Twilio, RingCentral and Instantly
Phone numbers, message bodies, delivery and reply status
In-call answers, objection handling and coaching cues
Live transcript excerpts sent to the selected model provider
Sales training simulator, scenario console and encrypted knowledge vault
Ciphertext vault, sealed recordings, coaching reports
Delivery, engagement and campaign performance reporting
Aggregated metrics; message bodies are not copied into reporting
Plans, seat assignment and subscriptions
Billing email, plan, seat count, Stripe identifiers
Roles, visibility rules, feature flags, queue and worker consoles
Account roles, configuration, metadata-only audit records
Environments, honestly labelled
This platform. The public site, customer portals, outreach, campaigns and the BOB module. Every control described on this page applies here.
Features explicitly labelled beta in the product, such as new discovery workers and experimental tooling. Same tenant isolation and encryption, but schemas, limits and interfaces can change without notice. Do not treat beta output as production record.
Admin, queue, operator and diagnostics consoles. Restricted by role, marked noindex, and never exposed as customer surfaces.
Data the platform processes
Identity
Work email, name, role, organization membership and seat assignment.
Business records
Contacts, leads, lists, campaigns and message templates that your team creates.
Communications
Message bodies, delivery and reply status, call audio, transcript excerpts.
Knowledge vault
Encrypted documents, scripts, workflows, coaching reports and sealed recordings.
Billing
Plan, seats, invoice metadata and Stripe identifiers. Card details never reach our systems.
Telemetry
Error traces, queue health, worker status and administrative audit metadata. No message content, no vault content.
An open-source encryption library is not, by itself, a privacy guarantee.
Anyone can import a well-audited crypto library and still upload your plaintext. What actually limits access is where the key lives, what the server is willing to accept, and which checks run before a record is returned. Here is what each common claim really demonstrates.
| What a vendor says | What it actually demonstrates | What would prove organization-only access |
|---|---|---|
| “We use an open-source encryption library.” | The algorithm is public and reviewable. It says nothing about where the key lives, who can call the API, or what the server does with your data. | Source you can read, plus a key that never reaches the server. |
| “Encryption happens in your browser.” | Only that some encryption call ran on the client. It is meaningless if a plaintext copy is also uploaded or accepted. | A server that refuses anything that is not ciphertext. |
| “The backend cannot read your knowledge.” | True only if the key never reaches the backend and the backend has no plaintext path. Otherwise it is a policy statement, not a property. | Passphrase-derived, non-extractable key that is never transmitted. |
| “Only your organization can access its data.” | Nothing by itself. Access is enforced by server-side checks, not by the cipher. | Verified identity, active membership of that organization, role gates, object-level ownership checks, and ciphertext bound to the organization. |
| “Zero knowledge.” | Requires that the operator cannot change the JavaScript it serves. No browser-delivered web app can promise this. | A signed, version-pinned client or a local app. BOB does not claim zero knowledge. |
What this build implements
- AES-256-GCM with a fresh 96-bit random IV per record and the organization id as additional authenticated data, so ciphertext from one organization fails to decrypt under another.
- PBKDF2-HMAC-SHA-256 at 310,000 iterations over a random 16-byte per-organization salt, deriving a non-extractable CryptoKey that is never written to storage.
- The tenant gateway validates every incoming payload as an AES-GCM envelope and rejects anything that is not ciphertext, so no plaintext write path exists.
- Every knowledge, script, workflow and session call requires a signed-in, email-verified identity with active membership of the selected organization.
- Delete operations verify the row belongs to the caller's organization before removal, and cross-organization ids return not found.
- Administrative actions write a metadata-only audit record: actor email, action, organization, timestamp. No keys, knowledge or call content are logged.
What stays unproven until an audit
- No independent penetration test or SOC 2 report exists yet, so none of the above has been confirmed by a third party.
- The operator controls the delivered JavaScript and could change future builds. Today's code is not a guarantee about tomorrow's.
- Anyone holding the organization passphrase can decrypt the organization's content. BOB support cannot recover or rotate it without re-encrypting.
- During a live call, selected decrypted text is sent to the configured speech and language-model providers. That leg is not end-to-end encrypted to the customer device.
Exactly what is collected, where it is encrypted, and what is kept.
This is the encrypted vault path specifically, used for knowledge documents, transcripts, scripts and coaching reports: the plaintext exists in your browser, becomes ciphertext before the request is sent, and is stored only in that form. Recordings follow the same rule as sealed binary blobs. Contact records, campaign configuration and billing metadata are tenant-scoped database records rather than vault items, and are covered by the access layers below.
Collection
An administrator creates the organization and uploads knowledge: scripts, objection handling, policy documents, workflows. Seats are invited by email. Live training transcripts, coaching reports and optional recordings are produced when a trainee runs a session.
Account identity and seat role · document set · session metadataKey derivation, on your device
The organization passphrase is stretched with PBKDF2 (310,000 SHA-256 iterations) against the organization's random salt, producing an AES-256-GCM key. The key is non-extractable and lives in browser memory only.
Nothing. The passphrase and the derived key are never transmitted or persisted.Encryption before the request leaves
Each document, transcript, script and coaching report is serialized, sealed with a fresh IV and the organization id as authenticated data, and wrapped as a versioned envelope of version, IV and ciphertext.
Ciphertext envelope onlyTransport
The envelope travels over HTTPS to the tenant gateway. The gateway checks the shape of the envelope and rejects any payload that is not a valid AES-GCM record, so a plaintext body cannot be stored even by mistake.
Envelope in transitStorage
Ciphertext is written to organization-scoped records. Session recordings are sealed to a binary blob and stored in private file storage, with the IV kept alongside the record. No bucket, table or log contains the plaintext.
Ciphertext in org-scoped rows · sealed recording blobs in private storageUse
A member with the passphrase opens the portal, the browser unlocks the key, and content is decrypted in memory for that tab. Closing the tab discards it. Nothing is written to local storage, cookies or the cache.
In-memory plaintext for the active tab onlyDeletion and rotation
Deleting a document removes its ciphertext row. Rotating the passphrase generates a new salt and key verifier and re-encrypts the vault. Because the key is not escrowed, data cannot be recovered without the passphrase.
Removed, or re-encrypted under the new keyNever stored anywhere
- The organization passphrase
- The derived AES key
- Unencrypted knowledge documents
- Unencrypted session recordings
- Card numbers or payment credentials
Where the boundary stops
Encryption at rest protects stored content. It cannot protect a screen someone is looking at, a passphrase written on a sticky note, or the excerpt a live call legitimately sends to a speech and language provider so the assistant can answer. Those are access and vendor questions, and they are handled by the tenant checks below and the provider list on this page, not by the cipher.
Five layers separate your organization from every other one.
Each layer is independent. Breaking one does not unlock the vault, and a buyer's reviewer can check each of them separately instead of trusting a single marketing claim.
1 · Key custody is yours
The passphrase is chosen by your administrator and never submitted to the platform API. It is stretched on your device into a non-extractable key, so even the browser cannot export it. A verifier blob, itself ciphertext, lets the portal reject a wrong passphrase without ever comparing the passphrase itself.
2 · Ciphertext is bound to your organization
The organization id is passed as additional authenticated data on every encrypt and decrypt. A record copied into another organization's storage fails authentication immediately, so ciphertext cannot be replayed across tenants.
3 · The server enforces the tenant boundary
Every request resolves the caller from the session, requires a verified email, and requires an active membership row for the organization named in the request. Roles gate administrative actions. Reads and deletes are filtered by organization id, and a mismatched id returns not found rather than leaking existence.
4 · Access is recorded, not assumed
Administrative and configuration actions write an audit record containing the actor's email, the action, the organization and the timestamp. The record is metadata only, so the audit trail itself never becomes a second copy of your knowledge.
5 · Operators are outside the content path
The knowledge endpoint requires a customer membership. Platform operators can manage organizations, seats and billing metadata; they are not given a membership and the gateway returns ciphertext to any caller that has one.
How you check it yourself
Five tests a technical buyer can run before signing, in the order that costs the least effort.
Read the module
The browser encryption module and the private data gateway are shown below, bundled from the files this build actually ships. Look for the KDF parameters, the IV generation, the additional authenticated data and the membership check.
Test key custody
Open the portal in a second browser without the passphrase. The vault stays locked: no endpoint returns a decrypted document, and no recovery flow exists to bypass it.
Test the tenant boundary
Ask for a second organization with its own passphrase. Its key cannot open the first organization's records, because the organization id is authenticated into every ciphertext.
Inspect what your account receives
The knowledge response contains identifiers, timestamps and encrypted payloads only. There is no field in the response that carries readable content.
Commission the independent test
The remaining step that BOB cannot self-certify is third-party verification. A scoped penetration test of the vault and gateway is the artifact a buyer's security review or cyber-insurance underwriter will ask for.
What is built to a published standard, and what is still paperwork.
Cryptographic practice can be checked against NIST publications today. Organizational assurance cannot be self-declared: SOC 2, ISO 27001 and a penetration test each require an outside party, and none of the three exists yet. Both registers are below, with the honest status of every row.
| Control | Standard or method | Status |
|---|---|---|
| Symmetric encryption | AES-256-GCM · NIST SP 800-38D | Implemented |
| Key derivation | PBKDF2-HMAC-SHA-256, 310,000 iterations · NIST SP 800-132 | Implemented |
| Randomness | Cryptographically secure IV and salt generation · NIST SP 800-90A | Implemented |
| Transport | TLS 1.2+ with HSTS on the published domain | Platform-provided |
| Authentication | Password plus optional Google or Microsoft sign-in, verified email required before any vault call | Platform-provided |
| Tenant isolation | Organization id as authenticated data plus server-side membership scoping | Implemented |
| Auditability | Metadata-only administrative audit records | Implemented |
Organizational assurance
| Item | Current position | Status |
|---|---|---|
| SOC 2 Type II (Security, Confidentiality, Availability) | The control set is being built toward the Trust Services Criteria. No report exists yet, so no SOC 2 claim is made. | In progress |
| ISO/IEC 27001 | Not certified and not in an active certification programme. The controls above map to several Annex A areas but do not constitute certification. | Not held |
| Independent penetration test | A scoped test of the vault, the tenant gateway and the recording pipeline is the next assurance step. Results will be published as a summary letter. | Planned |
| HIPAA business associate agreement | BOB does not offer a BAA. Do not place PHI or other regulated records in the vault until provider agreements and retention terms are agreed in writing. | Not offered |
| GDPR / CCPA position | Data processing terms, a subprocessor register and a deletion procedure are available for review before signature. Deletion is unrecoverable by design once ciphertext is removed. | On request |
Cyber-insurance and procurement evidence pack
Underwriters and enterprise security reviewers ask for the same ten artifacts. These are the ones that can be produced today and the ones still being written, so a review can start without waiting for a certification that does not exist yet.
| Evidence item | What is provided | Status |
|---|---|---|
| Encryption in transit and at rest | TLS on the published domain; AES-256-GCM ciphertext for all customer content | Available |
| Customer-controlled key custody | Passphrase-derived, non-extractable key; no escrow or recovery path | Available |
| Least-privilege tenant isolation | Membership-scoped gateway, role gates, object-level ownership checks, org-bound ciphertext | Available |
| Multi-factor authentication | Federated Google or Microsoft sign-in, or emailed verification codes, on the platform account layer | Platform |
| Logging and monitoring | Metadata-only administrative audit trail; worker and queue health monitors | Available |
| Subprocessor register | Published on this page, with the data each provider receives | Available |
| Written incident response plan | Runbook with notification timelines and customer communication templates | In progress |
| Backup and restore testing | Retention and restore evidence from the hosting platform, documented per environment | In progress |
| Periodic access review | Quarterly review of seat assignments, admin roles and API credentials | In progress |
| Third-party attestation | Penetration test report or SOC 2 Type II report | Not yet available |
Every integration, and what it is allowed to receive.
Encryption means little if a vendor list is vague. This is the complete set of external systems this build talks to, what each one is given, and whether that data is at rest, transient, or absent entirely. Nothing here receives the organization passphrase or the derived key.
| Provider | Role | Data it receives | Handling |
|---|---|---|---|
| Base44 | Application hosting, authentication, database and private file storage | Account identity, organization records, ciphertext, sealed recording blobs | Ciphertext at rest |
| Stripe | Subscriptions and per-seat billing | Billing email, organization and plan metadata. Card details go directly to Stripe and are never handled by BOB | No card data stored |
| Deepgram | Live speech-to-text for training calls | Call audio stream and the decrypted script context selected for the active turn | Transient · own key supported |
| LiveKit | Real-time audio transport for the training console | Call audio between the trainee and BOB | Transient |
| OpenAI | Language model for Q&A, coaching and intent detection | Decrypted transcript and script excerpts for the active turn only | Provider retention terms apply |
| Anthropic | Alternative language model for the same assistant surfaces | Decrypted transcript and script excerpts for the active turn only | Provider retention terms apply |
| Google Gemini | Language model with optional web context for research-style answers | Decrypted transcript and question text for the active turn | Provider retention terms apply |
| Twilio | SMS and voice for the Rosie AI outreach product | Phone numbers and message bodies on the outreach platform, not BOB vault content | Platform record |
| RingCentral | Alternative SMS and voice provider for outreach | Phone numbers and message bodies on the outreach platform | Platform record |
| Instantly | Cold email sequencing for the outreach product | Prospect name, email address and campaign copy | Platform record |
| SendGrid | Transactional email delivery | Recipient address and the message body sent | Transient |
| Resend | Alternative transactional email delivery | Recipient address and the message body sent | Transient |
| Apify | Public social platform scraping for lead discovery | Public post and comment text, public handles | Public sources only |
| Serper | Search results for discovery queries | Search queries and returned public results | Transient |
| Exa | Neural search for discovery queries | Search queries and returned public results | Transient |
| Google Calendar | Meeting scheduling and calendar sync | Attendee email and meeting time, under the calendar grant you approve | Scoped OAuth grant |
| Monday.com | Board handoff for qualified leads | Contact fields explicitly selected for the handoff | Platform record |
| Slack | Operational alerts for system events | Alert text and system status. Customer knowledge is not sent | Transient |
| Render | Isolated worker compute for geospatial and batch analysis | Job payloads for scraping and analysis workers | Transient |
What BOB commits to
- BOB does not sell, license or rent customer knowledge to third parties.
- Customer knowledge is never used to train a model owned by BOB.
- The vault is not readable by support. There is no recovery back door, so a lost passphrase means lost access.
- Content leaves the vault only as ciphertext, or as the specific excerpt a trainee's live call needs in that moment.
Bring-your-own providers
A speech and language-model account can be supplied by your organization instead of using the BOB defaults. The credential is encrypted before it is stored and is used only server-side for your organization's calls. This keeps retention and processing terms on your own provider agreements rather than the operator's, and it is the recommended setup for regulated buyers.
Not just a security promise. Read the code.
These excerpts are bundled from the actual source files this build ships. They show the design, but displaying code does not independently prove what a server executes or that future builds are unchanged.
/**
* BOB commercial content encryption, performed in the customer's browser.
*
* Implementation: PBKDF2(SHA-256, 310000 iterations, random per-org salt)
* derives a NON-EXTRACTABLE AES-256-GCM key from the organization's passphrase.
* A fresh 96-bit random IV is generated for every encrypted document/session.
*
* The passphrase and derived CryptoKey are NEVER sent to the BOB backend or
* persisted to localStorage, sessionStorage, cookies or IndexedDB.
*
* SECURITY BOUNDARY: This protects content in persistent storage against
* backend users without the passphrase. It cannot protect against malicious
* JavaScript shipped later by the application operator, compromised customer
* devices, passphrase sharing, or third-party AI vendors processing plaintext
* sent for a live simulation. It does NOT constitute verified zero-knowledge.
*/
const te = new TextEncoder();
const td = new TextDecoder();
const b64 = bytes => btoa(String.fromCharCode(...bytes));
const unb64 = input => Uint8Array.from(atob(input),c=>c.charCodeAt(0));
export const BOB_CRYPTO_VERSION = 1;
export const BOB_KDF_ITERATIONS = 310000;
export async function unlockOrganizationKey(passphrase, organizationSalt) {
if (typeof passphrase !== 'string' || passphrase.length < 14) throw new Error('Use a passphrase at least 14 characters long.');
if (!organizationSalt) throw new Error('This organization has not been initialized for encrypted storage.');
const material = await crypto.subtle.importKey('raw', te.encode(passphrase), 'PBKDF2', false, ['deriveKey']);
return crypto.subtle.deriveKey(
{name:'PBKDF2',salt:unb64(organizationSalt),iterations:BOB_KDF_ITERATIONS,hash:'SHA-256'},
material,{name:'AES-GCM',length:256},false,['encrypt','decrypt']
);
}
export function newOrganizationSalt(){
const salt = crypto.getRandomValues(new Uint8Array(16));
return b64(salt);
}
export async function encryptCustomerContent(key, value, organizationId){
const iv=crypto.getRandomValues(new Uint8Array(12));
const json=JSON.stringify(value);
const encrypted=await crypto.subtle.encrypt({name:'AES-GCM',iv,additionalData:te.encode(organizationId)},
key,te.encode(json));
return JSON.stringify({v:BOB_CRYPTO_VERSION,iv:b64(iv),ct:b64(new Uint8Array(encrypted))});
}
export async function decryptCustomerContent(key, payload, organizationId){
const data=typeof payload==='string'?JSON.parse(payload):payload;
if(data.v!==BOB_CRYPTO_VERSION || !data.iv || !data.ct)throw new Error('Unsupported encrypted data format.');
try{
const plain=await crypto.subtle.decrypt({name:'AES-GCM',iv:unb64(data.iv),additionalData:te.encode(organizationId)},
key,unb64(data.ct));
return JSON.parse(td.decode(plain));
}catch{
throw new Error('Cannot unlock this data. Check the organization passphrase and selected workspace.');
}
}
export async function createKeyVerifier(key, organizationId){
return encryptCustomerContent(key,{verification:'BOB-E2EE-V1'},organizationId);
}
export async function verifyOrganizationKey(key, verifier, organizationId){
const result=await decryptCustomerContent(key,verifier,organizationId);
if(result.verification!=='BOB-E2EE-V1')throw new Error('Incorrect organization passphrase.');
return true;
}Cryptographic API: Web Crypto PBKDF2 (310,000 SHA-256 iterations) with a per-organization salt, non-extractable AES-256-GCM key, random 96-bit per-record IV and organization-bound additional authenticated data. The browser key is deliberately not stored in localStorage.
Want the evidence pack for your review?
The architecture summary, subprocessor register, data processing terms and the current assurance status can be sent before you sign.