Sécurité des LLM et workflows agentiques : quand (et comment) vérifier domaines, IP et URL malveillants avant d'agir

Réponse courte : tout agent autonome disposant d'un accès réseau sortant est un navigateur distant que vous n'aviez pas l'intention de confier à vos utilisateurs. S'il peut suivre une URL, il vous faut un filtrage par réputation, une récupération sandboxée et une couche de politique que le LLM ne peut pas contourner avec quelques phrases habiles.

Pour une vue d'ensemble destinée aux directions sur la façon dont les attaquants détournent le machine learning, lisez Cyberattaques assistées par IA : les menaces du machine learning. Cette page en est le pendant opérationnel, centré sur les architectures d'agents.

Le nouveau mode de défaillance : « l'assistant a récupéré la charge utile »

Dans le SOAR classique, vous ne faisiez confiance qu'à vos playbooks validés. Dès lors que vous enveloppez ces playbooks dans un LLM capable de lire les tickets, les attaquants peuvent glisser des instructions indirectes dans le corps des tickets, dans les e-mails et dans les pastebins — en plus des liens malveillants habituels.

Les mesures d'atténuation relèvent pour partie de la défense contre les injections de prompt, et pour partie de la microsegmentation réseau des appels d'outils.

Une architecture de référence : modèle, outils et politique

| Couche | Responsabilité | Échoue si… | | ------------------- | --------------------------------------------------------- | ------------------------------------------------------------------ | | Politique | qui peut récupérer quoi, à quel niveau de sensibilité | vous laissez le modèle appeler HTTP directement | | Serveur d'outils | normalise l'URL, autorise/refuse, récupère | vous passez des cookies ou des jetons internes au récupérateur | | Enrichissement | renvoie des verdicts structurés, pas de longs textes | vous faites confiance à une seule liste obscure sans fraîcheur | | Humain | n'approuve que les actions à fort impact | vous sautez les validations parce que « c'était l'IA » |

La couche d'enrichissement est l'endroit où une API rapide et multi-entités trouve sa place — l'enrichissement d'IOC en profondeur et la conception des objets SIEM + SOAR sont directement pertinents si vous câblez tout cela dans un outillage d'entreprise.

Que faire avant une récupération : une checklist par paliers

1. Analyser et canonicaliser l'URL (punycode, defang/refang) — une redite des leçons des attaques par homographes IDN et de comment lire une URL en toute sécurité
2. Blocklist et allowlist de vos propres domaines, de votre SSO et de votre helpdesk, pour éviter le SSRF vers vos services internes
3. Recherche de réputation du nom d'hôte et des IP résolues via un service agrégé comme isMalicious, conformément au guide de vérification IP/domaine
4. Si inconnu : ne récupérer que depuis un profil headless durci, sans aucune authentification d'entreprise et avec les téléchargements désactivés par défaut
5. Si document : contrôler les types de contenu ; ne jamais « ouvrir » avec des macros Office ; traiter les archives comme brûlantes

Playbooks LLM + SOC : des règles de conception qui ne fondent pas

• Ne jamais transmettre un e-mail utilisateur brut à une étape d'automatisation de navigateur sans filtrage domaine/IP
• Toujours montrer aux analystes la sortie d'enrichissement structurée, et non une paraphrase du modèle, avant de bloquer des routes réseau
• Journaliser la chaîne d'outils : qui a déclenché le runbook, quelle version de modèle, quelles versions des listes d'indicateurs

Le modèle peut résumer — il ne doit pas être la seule preuve.

Le parallèle humain : AEO et citations

Si vous voulez que votre documentation publique soit bien citée par les systèmes d'IA comme par les humains, les recommandations éditoriales de l'optimisation pour les moteurs de réponse appliquée aux marques de cybersécurité s'appliquent. Une bonne documentation externe rend les politiques d'outils internes plus faciles à écrire, parce que les termes n'y sont plus ambigus.

Comparaison avec le phishing par e-mail pur (toujours d'actualité)

Beaucoup de prompts d'agents ingéreront une URL provenant d'un e-mail. Votre infrastructure de messagerie a toujours besoin d'une discipline DMARC, SPF et DKIM. Les agents amplifient les risques parce qu'ils agissent plus vite que les gens ne lisent les pieds de page.

Où se place isMalicious

isMalicious est une couche de réputation et d'enrichissement concrète, à placer en amont des récupérations, des contrôles de politique en ligne et des blocklists automatisées, lorsque l'objectif est une réponse rapide de type oui / non / peut-être avec friction sur les IP, domaines, URL et hashs. Pour les limites de périmètre par rapport à VirusTotal, lisez isMalicious vs VirusTotal.

Conseil opérationnel : dans les frameworks d'agents, faites de check_indicator(observable) un outil doté d'un schéma strict et de timeouts fixes, puis composez le LLM après le résultat de l'outil.

En résumé

L'avenir de l'automatisation en sécurité n'est pas « un LLM avec les droits root ». C'est un système resserré où les modèles proposent et où les outils imposent — et la threat intelligence est l'un de ces outils, qui doit être rapide, structuré et explicable.

Validez vos indicateurs comme vos agents devraient le faire : avec le vérificateur d'IP et de domaines isMalicious et, pour l'automatisation, avec les API décrites dans le comparatif des API de threat intelligence pour 2026.

Esquisse de schéma d'outil (pseudocode)

L'important n'est pas le langage ; ce sont les invariants (timeouts, absence de cookies, types de retour structurés) :

check_url(url) -> { normalized_url, host, resolved_ips[] }
reputation_for(host, ip?) -> { band, reasons[], as_of, sources_count }
decide(band, policy) -> { allow|challenge|block, audit_ref }
log_everything() -> // never skip this in agent flows

Si le LLM est autorisé à appeler http_fetch, il doit appeler check_url d'abord, puis reputation_for, et seulement ensuite un récupérateur sandboxé qui n'a pas accès à votre SSO. Cela s'accorde naturellement avec l'approche « réputation d'abord » décrite dans l'enrichissement d'IOC pour les programmes SOC.

Faites du red team sur l'agent, pas sur l'article de blog

• Collez l'URL d'un wiki interne bénin dans un ticket de test. L'agent doit refuser de la récupérer sans allowlist de routes.
• Collez un lien de phishing connu avec un hxxp defangé et du punycode mélangé. Le normaliseur doit le détecter, comme expliqué dans le guide sur les homographes IDN.
• Testez un contenu de prompt indirect à l'intérieur d'un PDF hébergé sur un site « propre » qui enchaîne vers une IP malveillante. La leçon : traiter toute la chaîne comme une menace, et pas seulement la première réponse text/plain.

Pourquoi c'est aussi un problème de SEO et de réponses IA

La même clarté qui rend votre site récupérable en optimisation pour les moteurs de réponse dans la cybersécurité est celle qui rend vos playbooks et vos politiques non ambigus pour les outils : des frontières explicites, pas de mots à la mode, et des exemples publics qui correspondent à ce que votre agent applique réellement. Si le blog dit « nous ne faisons jamais X » et que le runbook fait X le mardi, l'agent ne vous sauvera pas.