Trust center · Production platform

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.
Production scope

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.

Discovery & Leads
Production

Public-source discovery, enrichment and lead qualification

Public post and comment text, discovered contact details, intent scores

Contacts & Lists
Production

Master contact records, lists, folders and opt-in or opt-out status

Names, phone numbers, email addresses, tags, consent flags

Campaign Engine
Production

Drip sequences, batch event campaigns, schedules and send limits

Campaign definitions, message templates, per-contact enrollment state

SMS & Email Outreach
Production

Message delivery through Twilio, RingCentral and Instantly

Phone numbers, message bodies, delivery and reply status

Live Q&A & Live Coach
Production

In-call answers, objection handling and coaching cues

Live transcript excerpts sent to the selected model provider

BOB Training
Production · module

Sales training simulator, scenario console and encrypted knowledge vault

Ciphertext vault, sealed recordings, coaching reports

Analytics & Reporting
Production

Delivery, engagement and campaign performance reporting

Aggregated metrics; message bodies are not copied into reporting

Billing & Seats
Production

Plans, seat assignment and subscriptions

Billing email, plan, seat count, Stripe identifiers

Admin, Roles & Audit
Restricted

Roles, visibility rules, feature flags, queue and worker consoles

Account roles, configuration, metadata-only audit records

Environments, honestly labelled

Production

This platform. The public site, customer portals, outreach, campaigns and the BOB module. Every control described on this page applies here.

Beta

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.

Internal only

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.

Contract

Business records

Contacts, leads, lists, campaigns and message templates that your team creates.

Contract

Communications

Message bodies, delivery and reply status, call audio, transcript excerpts.

Contract

Knowledge vault

Encrypted documents, scripts, workflows, coaching reports and sealed recordings.

Contract · ciphertext at rest

Billing

Plan, seats, invoice metadata and Stripe identifiers. Card details never reach our systems.

Contract

Telemetry

Error traces, queue health, worker status and administrative audit metadata. No message content, no vault content.

Legitimate interest
The distinction that matters

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 saysWhat it actually demonstratesWhat 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.
Collection and storage

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.

01

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 metadata
02

Key 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.
03

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 only
04

Transport

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 transit
05

Storage

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 storage
06

Use

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 only
07

Deletion 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 key

Never 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.

Keys · tenancy · access

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.

01

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.

02

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.

03

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.

04

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.

05

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.

Standards and assurance

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.

ControlStandard or methodStatus
Symmetric encryptionAES-256-GCM · NIST SP 800-38DImplemented
Key derivationPBKDF2-HMAC-SHA-256, 310,000 iterations · NIST SP 800-132Implemented
RandomnessCryptographically secure IV and salt generation · NIST SP 800-90AImplemented
TransportTLS 1.2+ with HSTS on the published domainPlatform-provided
AuthenticationPassword plus optional Google or Microsoft sign-in, verified email required before any vault callPlatform-provided
Tenant isolationOrganization id as authenticated data plus server-side membership scopingImplemented
AuditabilityMetadata-only administrative audit recordsImplemented

Organizational assurance

ItemCurrent positionStatus
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 27001Not 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 testA 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 agreementBOB 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 positionData 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 itemWhat is providedStatus
Encryption in transit and at restTLS on the published domain; AES-256-GCM ciphertext for all customer contentAvailable
Customer-controlled key custodyPassphrase-derived, non-extractable key; no escrow or recovery pathAvailable
Least-privilege tenant isolationMembership-scoped gateway, role gates, object-level ownership checks, org-bound ciphertextAvailable
Multi-factor authenticationFederated Google or Microsoft sign-in, or emailed verification codes, on the platform account layerPlatform
Logging and monitoringMetadata-only administrative audit trail; worker and queue health monitorsAvailable
Subprocessor registerPublished on this page, with the data each provider receivesAvailable
Written incident response planRunbook with notification timelines and customer communication templatesIn progress
Backup and restore testingRetention and restore evidence from the hosting platform, documented per environmentIn progress
Periodic access reviewQuarterly review of seat assignments, admin roles and API credentialsIn progress
Third-party attestationPenetration test report or SOC 2 Type II reportNot yet available
Systems that touch data

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.

ProviderRoleData it receivesHandling
Base44Application hosting, authentication, database and private file storageAccount identity, organization records, ciphertext, sealed recording blobsCiphertext at rest
StripeSubscriptions and per-seat billingBilling email, organization and plan metadata. Card details go directly to Stripe and are never handled by BOBNo card data stored
DeepgramLive speech-to-text for training callsCall audio stream and the decrypted script context selected for the active turnTransient · own key supported
LiveKitReal-time audio transport for the training consoleCall audio between the trainee and BOBTransient
OpenAILanguage model for Q&A, coaching and intent detectionDecrypted transcript and script excerpts for the active turn onlyProvider retention terms apply
AnthropicAlternative language model for the same assistant surfacesDecrypted transcript and script excerpts for the active turn onlyProvider retention terms apply
Google GeminiLanguage model with optional web context for research-style answersDecrypted transcript and question text for the active turnProvider retention terms apply
TwilioSMS and voice for the Rosie AI outreach productPhone numbers and message bodies on the outreach platform, not BOB vault contentPlatform record
RingCentralAlternative SMS and voice provider for outreachPhone numbers and message bodies on the outreach platformPlatform record
InstantlyCold email sequencing for the outreach productProspect name, email address and campaign copyPlatform record
SendGridTransactional email deliveryRecipient address and the message body sentTransient
ResendAlternative transactional email deliveryRecipient address and the message body sentTransient
ApifyPublic social platform scraping for lead discoveryPublic post and comment text, public handlesPublic sources only
SerperSearch results for discovery queriesSearch queries and returned public resultsTransient
ExaNeural search for discovery queriesSearch queries and returned public resultsTransient
Google CalendarMeeting scheduling and calendar syncAttendee email and meeting time, under the calendar grant you approveScoped OAuth grant
Monday.comBoard handoff for qualified leadsContact fields explicitly selected for the handoffPlatform record
SlackOperational alerts for system eventsAlert text and system status. Customer knowledge is not sentTransient
RenderIsolated worker compute for geospatial and batch analysisJob payloads for scraping and analysis workersTransient

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.

Inspect the implementation

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.

src/lib/bobKnowledgeCrypto.jsReal source from this build
/**
 * 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.