L'incident McKinsey de cette semaine devrait servir d'électrochoc à toutes les entreprises qui déploient l'IA à marche forcée.
Non pas parce que l'IA est intrinsèquement non sécurisée.
Mais parce que trop d'organisations se concentrent encore sur la sécurité de l'IA au niveau du modèle, alors que le véritable risque pour l'entreprise réside dans la couche d'action: les API, les serveurs MCP, les services internes et les intégrations fantômes que les agents IA peuvent atteindre, solliciter et manipuler.
C'est ce que la plupart des entreprises ne voient toujours pas.
Les détails techniques ont ici toute leur importance. Les rapports publics ont décrit une plateforme d'IA interne dotée d'une vaste empreinte API, incluant plus de 200 points de terminaison documentés et un ensemble d'API non authentifiées potentiellement accessibles de l'extérieur. Ces mêmes rapports ont souligné des vecteurs d'exposition menant à des dizaines de millions de messages de chat, des centaines de milliers de fichiers, des comptes utilisateurs et des instructions système. Que l'impact total ait été atteint ou non, la leçon pour les responsables de la sécurité est claire : lorsque les systèmes d'IA internes sont connectés à des API faiblement gouvernées, le rayon d'impact peut devenir colossal en un rien de temps.
Et ce n'est pas un cas isolé.
L'incident lié à l'IA de recrutement de McDonald's pointe vers le même problème structurel. Entreprises différentes. Flux de travail différents. Même erreur fondamentale. Les rapports sur ce cas ont fait état d'un accès administratif exposé, de pratiques d'authentification faibles et de l'exposition potentielle d'une base massive de dossiers de candidats. Là encore, le problème ne concernait pas seulement le chatbot, mais l'infrastructure applicative et les API qui l'entourent.
C'est la leçon que le marché doit retenir.
Le vrai risque n'est pas le LLM. C'est ce que l'agent est capable de faire.
Une grande partie du marché actuel de la sécurité de l'IA se concentre sur les prompts, le comportement des modèles, les jailbreaks et le contrôle des sorties.
C'est important.
Mais ce n'est qu'une couche parmi d'autres.
En entreprise, les agents IA ne créent pas de valeur en discutant. Ils créent de la valeur en agissant. Ils récupèrent des données, appellent des API, utilisent des outils, accèdent à des systèmes, déclenchent des flux de travail et opèrent de plus en plus via des serveurs MCP et des services connectés.
Cela signifie que le véritable rayon d'action de l'IA est déterminé par la couche d'exécution.
- Si une API interne est laissée exposée sans authentification, un agent peut la trouver.
- Si un service fantôme est accessible via Internet, un agent peut l'atteindre.
- Si un serveur MCP est mal configuré, un agent peut l'utiliser.
- Si une logique métier sensible se cache derrière des points de terminaison non documentés ou oubliés, un agent peut enchaîner ces appels à une vitesse fulgurante.
C'est pourquoi la définition actuelle de la « sécurité de l'IA » dans l'industrie est encore trop étroite. La surface d'attaque ne se limite plus au modèle. Elle englobe tout le système connecté qui l'entoure.
Les failles de sécurité chez McKinsey et McDonald’s relèvent de la même problématique.
À première vue, ces incidents semblent différents. McKinsey concernait une plateforme d'IA interne. McDonald’s concernait un flux de travail de recrutement piloté par l'IA.
Mais structurellement, ils sont identiques. Tous deux soulignent une réalité croissante en entreprise : les organisations connectent leurs systèmes d'IA à des infrastructures applicatives internes et externes plus rapidement qu'elles ne sécurisent ces mêmes infrastructures.
Et dans bien des cas, le maillon faible n'est pas une exploitation sophistiquée du modèle. Il s'agit d'une simple API exposée, d'une authentification faible, d'un point de terminaison oublié, d'un contrôle d'accès mal configuré ou d'une intégration tierce devenue accessible sur Internet sans que personne ne s'en aperçoive.
C'est précisément pour cette raison que je considère que l'une des catégories les plus dangereuses qui émerge actuellement est celle des API fantômes connectées aux agents.
Il s'agit d'API internes ou peu encadrées qui n'étaient pas destinées à faire partie d'une surface d'attaque externe, mais qui, une fois connectées à des copilotes, des flux de travail, des serveurs MCP, des agents de navigation, des agents de codage ou des applications d'IA, le deviennent de fait.
L'entreprise les considère toujours comme « internes ». L'attaquant, lui, ne le fait pas.
L'angle mort : les API fantômes combinées à la connectivité des agents
C'est la faille qui m'inquiète le plus pour les entreprises aujourd'hui. Chaque société possède des API dont elle a connaissance. Beaucoup possèdent également des API oubliées, jamais totalement documentées, ou dont elle ignore qu'elles sont accessibles de l'extérieur.
Ajoutez maintenant l'IA à l'équation. Dès qu'un agent est connecté à ces systèmes, ou qu'un serveur MCP y ayant accès est exposé, la surface d'attaque s'élargit considérablement.
Ce qui était autrefois obscur, peu fréquenté et semi-interne devient :
- Découvrable
- Appelable
- Enchaînable
- Exploitable à la vitesse de la machine
C'est là tout le changement. Dans le monde pré-agentique, une API cachée ou faiblement gouvernée pouvait rester tranquille pendant des mois, voire des années. Dans le monde agentique, il suffit qu'elle soit accessible une seule fois.
Le nouveau modèle de sécurité dont les entreprises ont besoin
Si vous déployez de l'IA, vous devez cesser de vous demander uniquement : Le modèle est-il sûr ? et commencer à vous demander :
- Qu'est-ce que cet agent peut atteindre ?
- Quelles API soutiennent ce flux de travail ?
- Quels points de terminaison sont exposés à l'extérieur ?
- Quels serveurs MCP existent dans toute l'entreprise ?
La prochaine génération d'incidents liés à l'IA proviendra d'agents reposant sur des couches d'action fragiles : API exposées, services non authentifiés, intégrations oubliées et serveurs MCP mal configurés.
C'est précisément pour cela que nous avons créé Salt Surface
Chez Salt, nous avons passé des années à aider les entreprises à découvrir et à sécuriser des API dont elles ignoraient l'exposition. Ce problème est désormais encore plus critique à l'ère de l'IA.
Avec Salt Surface, les entreprises peuvent cartographier leur empreinte API exposée, y compris les API liées à l'IA et les services accessibles depuis l'extérieur, sans déployer d'agent ni installer quoi que ce soit dans leur environnement.
Si vous développez des solutions basées sur l'IA, la première question ne devrait pas être de savoir si votre prompt est protégé, mais si votre couche d'action est exposée.
Le modèle ne constitue pas l'intégralité de la surface d'attaque. C'est la couche API qui l'est.
Obtenez votre scan d'exposition gratuit
Si vous souhaitez savoir si votre entreprise possède des API exposées, des points de terminaison connectés à l'IA ou des services accessibles via Internet, nous vous le montrerons. Aucune installation. Aucun effort complexe. Il suffit d'un nom de domaine pour obtenir une visibilité sur la surface d'attaque que vous devez comprendre dès maintenant.
Demandez votre scan Salt Surface gratuit dès aujourd'hui.
Roey Eliyahu est cofondateur et PDG de Salt Security, le leader de la sécurité des agents.