Bishop Fox a release AIMap en open-source — un scanner style Nmap pour l'infrastructure AI qui fait discovery, fingerprinting, risk scoring, vulnerability testing et visualization à travers la surface AI. La couverture inclut serveurs MCP, Ollama, vLLM, LiteLLM, LocalAI, LangServe, LangChain, Open WebUI, LibreChat, Gradio, Streamlit, ComfyUI, Stable Diffusion, Hugging Face TGI et APIs d'inférence génériques. Le chiffre qui atterrit dans la couverture du lancement et qui devrait probablement faire les builders auditer leurs stacks : 175 000+ instances Ollama reachable sur l'internet public, **environ 91 % sans authentification configurée**. Ce n'est pas une vulnérabilité dans Ollama — Ollama fait ce que tu lui as demandé de faire — ce sont les opérateurs qui déploient des serveurs local-LLM sans reconnaître qu'ils les shippent à internet.

L'architecture est directe : Discovery via Shodan avec 32 signatures AI-spécifiques, Fingerprinting via Nuclei templates et probes HTTP (identifiants positifs comme la string « Ollama is running » d'Ollama à la racine ou le `/version` endpoint de vLLM), risk scoring 0-10, suites d'attaques protocol-spécifiques (prompt injection, tool abuse, model extraction), et une visualization style Shodan avec vue globe 3D. La distinction exposed-vs-accessible est le détail opérationnellement important : HTTP 200 veut dire pas d'auth (n'importe qui peut hit le modèle), 401/403 veut dire que l'auth est configurée, et les headers WWW-Authenticate te disent le scheme (Bearer, Basic, API key). Pour les builders qui font tourner de l'infra LLM self-hosted, l'asset inventory pratique prend environ dix minutes — pointe AIMap sur ton propre ASN, récupère une liste de ce qui est exposé et comment c'est protégé. Le burden de compliance légale (CFAA, GDPR) est sur les opérateurs qui utilisent l'outil pour quoi que ce soit au-delà de leur propre infrastructure ; Bishop Fox le publie comme outil, pas comme service.

La lecture ecosystem se paire naturellement avec les pieces antérieurs sur la sécurité des serveurs MCP et l'architecture Claude Code Auto Mode. Le pattern à travers les trois : l'infrastructure AI est déployée plus vite que l'hygiène de déploiement ne rattrape. Serveurs MCP sans authentification, instances Ollama sur l'internet public, endpoints vLLM exposés à n'importe qui qui les trouve — la surface d'attaque est large et visible. AIMap n'introduit pas le problème ; il le rend mesurable. Le chiffre 91 % Ollama-no-auth est frappant mais consistent avec le pattern plus large de « infra AI déployée pour usage personnel, puis oubliée sur une IP publique ». Pour les équipes sécurité chez les compagnies AI-builder, c'est la question d'asset inventory qui n'avait pas eu d'outil jusqu'à maintenant. Pour les builders solo qui font tourner Ollama sur un serveur home, la question pertinente, c'est si tu voulais vraiment exposer le port 11434 à internet, et la réponse est presque toujours non.

Move pratique : si tu fais tourner n'importe laquelle des infras AI listées en production ou pour usage personnel, scan ton propre périmètre avec AIMap ou équivalent. La configuration Ollama par défaut bind à 0.0.0.0 dans certains setups — check l'interface qui listen, puis check si le firewall bloque vraiment le trafic externe. Pour les opérateurs de serveurs MCP (la story récente sur la surface d'attaque a montré que les agents sont exploitables à travers les outputs d'outils prompt-injected), la question auth + isolation network est maintenant tool-discoverable. Pour les orgs qui déploient des capacités AI sur l'infra interne, fais tourner le scanner contre tes propres IPs au moins trimestriellement — le pattern deployment-without-auth se reproduit plus vite que la security awareness ne se propage. Le signal plus large : le tooling de sécurité AI rattrape le reste de l'industrie de la sécurité, et le gap entre « on a déployé un LLM » et « on a déployé un LLM de façon sécurisée » a été plus large que la plupart des builders ne le réalisaient.