Security Whitepaper

Overview

Coach-In-The-Pocket™ is built for contractors whose procedures, safety records and people data must stay private. This page summarizes the security controls of the hosting platform we run on and the protections we have built into the product.

Hosting platform

Coach-In-The-Pocket runs on the Base44 platform, which is SOC 2 Type II and ISO 27001 certified and GDPR compliant. A Data Processing Agreement is available on request, and the SOC 2 report is available from the Base44 Trust Center.

The app is delivered through the Cloudflare content delivery network (CDN), which serves it from servers close to each user.

Data is encrypted in transit (HTTPS/TLS) and at rest. Data is not end-to-end encrypted, so authorized platform administrators can access it when operationally required.

The platform undergoes regular penetration testing by internal and outside teams and runs a bug bounty program. All public endpoints are rate-limited by default.

API keys and other credentials are kept in an encrypted vault protected by AWS Key Management Service. Only the app's server side can read them; they are never sent to users' browsers.

Platform servers and default data storage are located in the United States.

Shared responsibility

Base44 secures the underlying infrastructure. Coach-In-The-Pocket controls app visibility, the access rules that decide who can see or edit each type of data, sign-in methods, and which sites may display the app in a frame. Browser security settings also stop content from other sites from using the camera, microphone or location.

We run the platform's security scan, which checks for data that is too open, exposed keys, server functions that skip sign-in checks, and known issues in third-party libraries. We remediate the findings.

Company data separation

Every company's content and records are stored separately and tagged to that company. Access is checked on the server for every request: the person must be signed in, hold an active membership in that company, and have the right role.

Company, role and permission values sent from a browser are never trusted. Company workspace data cannot be read or written directly from the browser; it goes only through protected server checks.

Server-side data protection and access rules

Database access rules (row-level security) are enforced by the platform on every sensitive record type. For company content, personal records, invitations, branding, support requests and operational logs, the rules deny direct browser reads and writes for every role, including administrators. All access goes through protected server functions that verify the signed-in person before returning or changing anything.

Shared company libraries, including procedures (SOPs), toolbox talks, safety incidents, labor agreements, announcements, training, core values and notes, are served only by server functions that confirm the person's company access first. Only authorized administrators can add or change content.

Personal records such as chat history, wellness check-ins and trivia streaks are tied to the verified signed-in account on the server. A person can only see their own records, and ownership is never taken from a value sent by the browser.

Daily trivia questions, answer checking, scoring and streaks are handled entirely on the server. Correct answers are not sent to the browser before a person answers, and scores cannot be changed from the browser.

Protected fields such as company, role, membership status, approval and audit stamps can only be set by server code after authorization. They cannot be edited directly, even by the record's owner.

Sign-in and multi-factor authentication

Users sign in with email and password (with email verification codes on registration) or with Google or Microsoft accounts.

Enterprise single sign-on with Microsoft Entra ID is supported by the platform and is being prepared for enterprise customers. With SSO, the customer's own identity provider enforces its MFA and Conditional Access policies.

Signing in never grants access by itself: a user must also be invited to, or approved for, a specific company.

Roles and least privilege

Access is role-based (company administrator, manager, supervisor, employee). Only company administrators can manage content, people and settings for their own company. Platform-level administration is limited to a small, separately controlled owner role.

AI assistant safeguards

The assistant answers only from content that a company administrator has explicitly approved for AI use. Nothing is AI-readable by default.

Wellness check-ins, safety incident reports and other sensitive records are never used as AI knowledge, and company content is not used to train public AI models.

Main assistant chat requests run on the server. The server checks the person's access before every request, and the assistant's instructions, model choice and reference data are kept there instead of in the browser.

The standalone AI assistant has no direct access to company databases, so it cannot look up company records on its own.

Per-person usage limits are enforced on the server and shared across the assistant's chat features, protecting against abuse and runaway use.

Privacy by design

Wellness data is shown to administrators only as privacy-minimized summaries. Operational logs are short-retention and exclude passwords, tokens, AI conversations, documents and other private content. Documents are stored privately and opened only through short-lived, permission-checked links.

Audit and monitoring

Important administrative, access and configuration changes are recorded in an append-only audit trail. Operational health is monitored, and automated security scans are run on the platform.

Invitations

Invitations are tied to the invited email address, expire automatically, and can be cancelled at any time. The signed-in account must match the invited email before access is granted.

Reporting a concern

To ask a security question or report a potential issue, please contact us through the Support page. Enterprise customers may request additional security documentation during onboarding.