MistralAI-Index

• Search indexing for Vibe: Mistral says this crawler indexes web content for Mistral search, which helps answer questions in Vibe.
• Source discovery: Indexed content may show up in search results or assistant answers. Allowing the crawler doesn’t guarantee a page is indexed, ranked, surfaced, or cited.
• Separate indexing and training choices: Separate tokens let you set different robots.txt preferences for indexing and training.
• An extra verification signal: Mistral publishes an IP list for this crawler, so you can compare observed source addresses against it.

A published IP list gives you a second way to check a request. The user-agent string can still be copied, so a request claiming to be MistralAI-Index shouldn’t be trusted on that claim alone.

• Spoofing: An unrelated scraper can send the MistralAI-Index string and look like Mistral.
• Allowlists: Trusting the user-agent without other checks can let unrelated traffic reach resources meant for verified crawlers.
• Unusual paths: Requests to restricted paths deserve a look, but they don’t prove spoofing on their own.
• Mixed-up agents: Mistral’s three agents have different purposes. Set rules for each token, and watch for wildcard and overlapping robots.txt groups.
• Stale IP data: A copied IP list goes out of date. Depending on your setup, that can reject legitimate requests or let unverified ones through.

A spoofed user-agent doesn’t change Mistral’s search index or give anyone access to Mistral’s systems. The impact on your site comes from the requests and how your infrastructure handles them, such as added load, noisy logs, or misapplied access rules.

If MistralAI-Index shows up in your logs, the user-agent claims to be Mistral’s indexing crawler. That alone doesn’t prove the request came from Mistral or that the page was indexed.

• Automated crawling: Mistral documents MistralAI-Index as an automated crawler for indexing. It doesn’t describe how the crawler finds pages.
• Indexing, not training: Mistral says content crawled by MistralAI-Index isn’t used for generative AI training. This applies to the Index agent only.
• Crawl volume and schedule: Mistral gives no crawl rate or schedule. Use your server, CDN, analytics, and bot management logs to see what reaches you.
• Visibility in Vibe: MistralAI-Index supports Mistral search, so blocking it may limit what the crawler can retrieve for that index. Allowing it doesn’t guarantee indexing, ranking, or citations.
• Registration: Mistral’s page doesn’t say whether registration or another relationship with Mistral is required.

• Check the user-agent. The documented value is Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; MistralAI-Index/1.0; +https://docs.mistral.ai/robots). Match on the MistralAI-Index token rather than the full string. Treat it as a claim, not proof.
• Check the source IP. Compare the request’s IP with Mistral’s published MistralAI-Index list. If it doesn’t match, treat the traffic as unverified unless you have another reliable way to validate it.
• Keep the IP list current. Fetch the list on a schedule and compare it with your copy. If you automate this, add monitoring and a fallback for failed or malformed responses and unexpected changes. Don’t allow or block traffic based on an old copy.
• Use the right list. MistralAI-User has its own IP list. Don’t swap one for the other. Mistral’s crawler documentation links to both.
• Look at behavior. Review requested paths, request rates, and response patterns. Requests to login, API, or other restricted paths deserve a look, but they don’t prove spoofing. Normal-looking requests don’t prove a genuine crawler either.
• Compare against robots.txt. If requests continue after you disallow the token, check the rule’s syntax and placement, your deployed file, caching, and the exact user-agent match. Also check where the requests come from. Continued requests don’t show that the crawler is genuine or that it’s ignoring your rules.

It depends on whether you want your content available to Mistral’s search crawler, and on your content and security policies.

A robots.txt rule for MistralAI-Index states a preference for that crawler only. It doesn’t block other search engines or control access. Check your full robots.txt for wildcard and overlapping rules, and use authentication and authorization for restricted resources.

Consider restricting or blocking the crawler when:

• Requests with this identity fail your verification checks
• Your content is subscription-based, licensed, or commercially sensitive
• Your policy doesn’t allow your content to be crawled for this purpose
• Request volume measurably affects performance or data transfer costs
• Certain paths, such as account or checkout areas, shouldn’t be open to crawlers

If you want your content available to Mistral search, allowing MistralAI-Index may help people discover it. It doesn’t guarantee indexing or citations. If you also want to decline training data collection, set that preference separately for MistralAI-Training.

Use the dedicated robots.txt token. Mistral documents MistralAI-Index as a crawler for search indexing.

Block the whole site:
User-agent: MistralAI-Index
Disallow: /

Block selected paths:
User-agent: MistralAI-Index
Disallow: /account/
Disallow: /checkout/


These rules state your preferences. As RFC 9309 explains, robots.txt isn’t access authorization and relies on the crawler to comply.

Other controls:

• Keep rules separate: Write agent-specific groups and check wildcard and overlapping rules so the full file matches your policy.
• Verify before allowlisting: Combine the user-agent with a check against the current IP list and other signals. A user-agent-only allowlist is easy to bypass.
• Protect restricted resources: Use authentication and authorization for private content. Robots.txt and an IP allowlist aren’t a complete security boundary.
• Monitor after changes: Review server, CDN, and bot management data to see whether request patterns change, and look into unexpected traffic.

MistralAI-Index is a documented AI search crawler with a published IP list. For requests claiming this identity, check the user-agent token, the current IP list, and other available signals together.

Our advice: allow it if you want your pages to be discoverable and cited in Mistral’s answers, and block it if you don’t. Verify the user-agent against Mistral’s published IPs before trusting a request, because the string alone can be copied.

This is where we can help. With DataDome Bot Protect, you can check claimed Mistral crawler traffic against its expected behavior and apply intent-based detection to anything that doesn’t match. You choose which paths it can reach, with rules separate from Mistral’s training and user-triggered agents.

Whatever you decide, recheck Mistral’s documentation for IP list updates, and protect sensitive paths with authentication and authorization.