Traceability
Important claims keep their source trail.
MindLab is designed to preserve where important context came from so reviewers can inspect evidence, changes, conflicts, and open questions instead of relying on an orphaned AI answer.
Trust & Security
MindLab is built for information that investment teams cannot treat casually. Provenance, customer-authorized scope, human review, data handling, and deployment-specific commitments belong in the architecture, not in a footnote.
Operating principles
Security for an intelligence layer is also about provenance, information scope, and what the system is allowed to carry forward into future work.
Traceability
MindLab is designed to preserve where important context came from so reviewers can inspect evidence, changes, conflicts, and open questions instead of relying on an orphaned AI answer.
Access
Reusable context does not mean unrestricted context. Customer-authorized source scope, users, review rules, and workspace boundaries remain part of how information is handled.
Human review
MindLab can extract, connect, prepare, and propose updates. Review rules and approval states determine what should become durable institutional context for future work.
Public commitments today
These statements summarize commitments already reflected in MindLab's public Privacy Policy and Terms. They are intentionally narrower than a customer-specific security schedule.
Customers determine the materials, systems, and connections they authorize for a MindLab deployment and remain responsible for the rights and permissions to those sources.
Privacy Policy and Terms of Service
Customer communications, documents, data, notes, connected-system content, reviewer comments, approvals, and other workspace materials remain customer-owned, subject to the applicable agreement.
Terms of Service
MindLab's public policy states that customer confidential data is used to operate the customer workspace and agreed workflows. Third-party providers may process data only as needed to operate the service under applicable terms and controls.
Privacy Policy
The Privacy Policy states that MindLab does not sell customer confidential data and does not sell personal information in the ordinary meaning of selling data for money.
Privacy Policy
Before rollout
Enterprise requirements vary by firm. Provider, control, data, retention, residency, and assurance commitments should be verified for the actual deployment and documented in the applicable agreement.
Which communications, files, systems, records, or source categories are authorized for the deployment.
Authorized users, workspace boundaries, source access, reviewer rules, and external-sharing constraints that apply to the deployment.
Model providers, infrastructure boundaries, provider requirements, and any training-related or deployment-specific processing commitments.
What can be prepared or proposed automatically, what requires review, and what may become durable institutional context.
Retention, deletion, export, backup, termination, and related procedures that apply to the deployment.
Logging, monitoring, audit reporting, data residency, and other enterprise requirements when verified and agreed for the deployment.
Model & provider scope
MindLab's public Privacy Policy states that customer confidential data is used to operate the customer workspace and agreed workflows, and that customer documents, deal flow, proprietary outputs, and firm records are not used to train public models by default. Because provider and deployment terms can vary, the exact model-provider, retention, residency, and training-related commitments should be documented for the customer deployment rather than inferred from a generic marketing claim. Before rollout, the written deployment terms should also state whether any exception to that default exists and who, if anyone, can authorize it.
Read the current Privacy PolicyEvaluation checklist
The point of a security review is to turn ambiguous marketing language into a verified deployment boundary.
Which sources and users are in scope?
Which model and infrastructure providers process data?
What requires human review before it becomes trusted context?
What retention, deletion, export, and residency commitments apply?
Which security controls and enterprise features are verified for this deployment?
Certifications, integrations, residency options, and customer-specific controls are represented only when they are verified for the relevant deployment. Ask MindLab for the current security and architecture details during evaluation rather than inferring capabilities from a logo or generic trust badge.
Security review
We can walk through the live product, source and review architecture, data boundaries, AI-processing scope, and the requirements that need to be documented for your firm.