Stronger protection for your connected workspace

Authentication and session controls

Account protection combines identity verification, company policy and controls over active sessions.

• Authenticator-based MFA. Time-based one-time passwords (TOTP) add a second verification step at sign-in, with recovery codes for account recovery.
• Server-enforced company policy. Administrators can require MFA for their company. Protected actions check the required authentication level on the server, not just in the interface.
• Stronger password validation. Password checks require at least 12 characters with uppercase, lowercase, numeric and special characters.

MFA is available and company-configurable. It is not automatically enabled for every workspace.

Authorisation and company-data isolation

Being signed in is not enough to access company resources. The reviewed paths also check the caller’s permissions for the relevant workspace.

• Verified caller identity. Protected application operations authenticate the caller before checking company membership and resource access.
• Company-scoped permissions. Server-side and database-level access controls restrict the reviewed resources to authorised users in the relevant company.
• Private file access. Task attachments are tied to task and company permissions. Temporary agent uploads are private to their uploader.
• Restricted internal operations. Background operations have dedicated access requirements rather than relying on ordinary anonymous or end-user access.

These changes strengthen the reviewed controls. The assessment sampled selected paths; it was not an exhaustive test of every platform operation.

Credential encryption and integration safeguards

Connected services need credentials to work. These releases strengthen how those credentials are stored, exposed and used.

• Authenticated encryption at rest. AES-256-GCM protects stored integration credentials covered by this release, including Google Ads, Google Analytics, Meta, LinkedIn and Notion.
• Reduced browser exposure. Sensitive connection credentials are kept out of normal browser-facing responses. Webhook secrets use protected secret storage.
• Administrative destination control. CRM webhook destinations are managed through administrator-only controls.
• Outbound address validation. Destination checks validate resolved addresses before webhook delivery, helping restrict requests to permitted external destinations.

Retention, deletion and AI response storage

Scheduled retention and deletion checks make the lifecycle of operational records more explicit.

• Scheduled log clean-up. A recurring deletion process applies the retention periods below to the covered operational records.
• Identity removal on account deletion. Identifying account details are removed from retained activity logs when an account is deleted.
• Company-deletion evidence. Company deletion includes verification checks, a confirmation email and a Checkgrow-generated PDF certificate describing what was removed.
• Provider response-state control. OpenAI Responses requests are configured not to store response state with the provider.

These periods do not describe every category of customer data. The provider setting is not a claim of zero retention across every AI service; provider policies and applicable agreements still govern their processing. Our Privacy Policy and Terms have also been updated to describe our practices more accurately.

Application hardening and security verification

Preventive checks in the development workflow complement targeted testing and release verification.

• Dependency monitoring and audit gates. Automated checks identify known package advisories and help prevent dependency-security regressions during development.
• Static security analysis. Source-code checks look for security-relevant patterns before changes are released.
• Browser security headers. HSTS, frame restrictions, MIME-sniffing protection, Referrer-Policy and Permissions-Policy strengthen browser-side handling of application responses.
• Role and company-boundary testing. The staging assessment used source review, automated analysis and targeted tests across different user roles and workspaces. Findings informed follow-up changes and regression checks.
• Production release verification. Release records confirm that the changes described here were shipped. Deployment success is not equivalent to an independent penetration test of every production path.