Internal Data Security

Updated November 2, 2026 — Le Chat is now Vibe. As of May 28, 2026, Le Chat has been rebranded as Vibe (still at chat.mistral.ai): a single agent for work and code, carrying over your conversations, settings, and subscriptions. The legacy Le Chat experience remains accessible in Chat mode; in Work mode, agents are now skills (invoked with @), memories form the knowledge base, and deep search is the Deep Research skill. Plans are now called Mistral Free, Pro, Team, and Enterprise. This lesson uses the name Vibe; note that some menus described here may have changed names or locations.

Three questions that always arise in the same order

Giving an AI search engine access to your internal data raises legitimate concerns, which invariably appear in this order: How do you guarantee data confidentiality? How are existing permissions respected? How do you ensure that no one, not even Mistral, accesses unauthorized information? Below is the Enterprise Search security architecture and the controls your security team can audit.

Isolation and encryption

Every organization gets a completely isolated environment: your company’s semantic index is separate from those of other Mistral customers. This isolation is enforced at the infrastructure level through separate databases, distinct encryption keys, and no sharing of compute resources for indexing. In short, there is no technical path by which another customer’s query could reach your documents.

Data is encrypted at every stage. In transit, TLS 1.3 protects communications between your connectors and Enterprise Search. At rest, the semantic index and metadata are encrypted with AES-256. In memory, data is decrypted only for the duration of query processing. Keys are managed by a FIPS 140-2 certified HSM. On request, you can supply your own keys under the BYOK (Bring Your Own Key) model—an option required by organizations that must be able to revoke access without relying on a third party.

Permission control

Enterprise Search does not create its own permission system; it replicates the permissions of each connected source. A Drive document shared with ten people appears only to those ten people. A Confluence space restricted to the engineering team remains invisible to sales, even when they ask a question whose answer lies there. A private Slack channel is accessible only to its members, even if its content has been indexed. This mechanism runs continuously: a permission change in the source is reflected in the next synchronization cycle, which takes anywhere from a few minutes to an hour depending on configuration.

Three situations deserve special attention because they reflect the actual state of your sources, not a product defect. Files shared as “Anyone with the link” in Google Drive become visible to all Enterprise Search users, since that is exactly the permission applied: audit these shares, which are often leftovers from one-off exchanges with contractors. Permission inheritance requires the same vigilance: a subfolder inheriting rights from its parent can expose a moved folder more broadly than intended. Finally, the connector’s service account must have only the minimum necessary permissions, and its scope must be reviewed every time you add a source.

Traceability

Every interaction is logged: who asked the question (with their user ID and timestamp), which documents were viewed in the results, what response was generated, plus response time and the model used. These logs are exportable in standard JSON and CSV formats and integrate with your SIEM, whether that’s Splunk, Elastic, or QRadar. The value isn’t just regulatory: this log is what lets you reconstruct precisely what a user saw in case of suspicion.

The admin console also lets you configure alerts. An abnormal volume of queries from a single user signals possible data exfiltration and warrants quick review; attempts to access out-of-scope documents, repeated authentication failures, and connector configuration changes round out the setup. These alerts must route to a named owner, or they will pile up unaddressed.

Queries and responses follow the same retention policy as Mistral Enterprise: processed in real time and then deleted under zero retention, or kept for a defined period for audit purposes under configurable retention. Usage metadata—volume and timestamp—is retained independently for billing.

External audits

Mistral AI subjects Enterprise Search to quarterly penetration tests conducted by independent firms and an annual SOC 2 Type II audit, and maintains a bug bounty program that rewards security researchers. Pentest reports and certifications are available on request for your security teams. Request them early: reviewing them takes time and often determines whether your CISO gives approval.

Before enabling the service

Your CISO has six checks to run before go-live. First, review enabled connectors and granted permissions, then audit files shared via “public link” in your sources—that’s where surprises hide. Next, set the query retention policy and integrate audit logs into your SIEM so monitoring is operational from day one. Finally, test permission separation by confirming that a test user cannot see another team’s documents, and document the security architecture for your GDPR record of processing activities.

Of these six checks, the permission separation test is the one teams most often skip, even though it’s the only one that produces direct evidence. Create a test account tied to a team, ask it questions whose answers live elsewhere, and keep a record of the result: that’s what you’ll present at your next internal audit.

Key takeaways

• Data is isolated by organization, encrypted at rest and in transit, with dedicated keys
• Permissions from your source tools are replicated automatically—no bypass possible via Enterprise Search
• The complete audit trail is exportable to your SIEM
• Auditing “public link” shares and service accounts is mandatory before deployment