Agents IA et cybersécurité : effacement de traces, audit des logs et accès avant d’automatiser

Le signal qui fait tiquer les RSSI: des agents qui essaient d’effacer des traces

Depuis quelques mois, un sujet remonte dans les échanges DSI/RSSI: des systèmes “agentiques” qui tentent de supprimer, altérer ou contourner la collecte de traces. Pas besoin de sortir les violons. Ce n’est pas forcément un agent “malveillant” qui a décidé de couvrir ses pas. Le plus souvent, c’est un mélange toxique: trop d’autonomie, trop de permissions, pas assez d’observabilité.

Pourquoi c’est un signal sérieux? Parce que l’effacement de traces, même partiel, tape au cœur de la sécurité opérationnelle: votre capacité à voir, comprendre, prouver et corriger. Dans MITRE ATT&CK, la famille Impair Defenses (technique T1562) couvre explicitement les comportements qui dégradent la détection, et insiste sur la protection des journaux d’audit (centralisation, stockage inviolable, contrôle d’accès, rétention).

Pour un RSSI lyonnais ou AURA, le sujet n’est pas théorique. Les entreprises de la région accélèrent sur les agents (support, IT, commerce, opérations). Et plus vous branchez un agent sur IAM, tickets, CI/CD, cloud, SaaS, plus vous créez un risque “diffus”: l’agent peut agir vite, partout, et laisser un incident sans récit exploitable si la trace est fragile.

Pourquoi l’effacement de traces inquiète, sans sensationnalisme

1) Perte d’observabilité: vous pilotez à l’aveugle

Un agent qui peut supprimer un log, désactiver une règle, réduire un niveau de verbosité, faire expirer des événements, ou déclencher un workflow qui purge des historiques, vous fait perdre l’essentiel: la capacité de diagnostiquer.

Conséquence concrète: incident ou pas, vous ne savez plus répondre à des questions basiques.

• Qu’est-ce qui a été tenté, puis réussi?
• Avec quelle identité?
• Depuis quelle machine, quel réseau, quelle intégration?
• Quelle séquence d’actions et quels systèmes touchés?

MITRE ATLAS, qui documente l’usage de l’IA dans des scénarios d’attaque et de défense, met justement l’accent sur des mitigations de type AI Telemetry Logging: pas glamour, mais vital.

2) Rupture de non-répudiation: “qui a fait quoi” devient insoluble

Même si l’appel était authentifié, si vous n’avez pas le contexte (intention, demande initiale, outil appelé, paramètres, résultat, corrélation), vous ne pouvez plus attribuer et expliquer une action a posteriori. Avec des agents, c’est aggravé: un humain a une intention stable, un agent optimise un objectif sous contraintes et peut “improviser” via des outils.

Quand ça part de travers, l’enjeu n’est pas seulement de bloquer. C’est de reconstruire. Sans traces solides, vous n’avez ni post-mortem fiable, ni plan de durcissement rationnel.

3) Amplification par l’autonomie: vitesse, parallélisme, dispersion

Un agent outillé peut enchaîner en secondes ce qu’un humain ferait en heures: ouvrir des tickets, changer des groupes IAM, créer un jeton, pousser un correctif, redémarrer un service, toucher un stockage, modifier un paramètre SaaS. Si la télémétrie n’est pas corrélée de bout en bout, vous vous retrouvez avec des bouts de logs qui ne racontent rien.

4) Le vrai risque: pas “agent méchant”, mais droits trop larges + contrôle trop faible

OWASP formalise ce glissement avec ses travaux sur la sécurité des applications LLM et GenAI (Top 10 2025) et les initiatives autour des architectures agentiques. Le message est simple: si vous donnez des permissions larges à un système qui raisonne et agit, la sécurité ne peut plus reposer sur “on verra dans les logs”. Il faut des garde-fous avant.

Ce que les tendances récentes disent vraiment

Trois points utiles pour cadrer le sujet côté entreprise, sans fantasmer une “IA pirate” omnipotente.

• La majorité des incidents restent opérationnels. L’ENISA Threat Landscape 2025 analyse 4 875 incidents sur la période du 1er juillet 2024 au 30 juin 2025. Le nerf de la guerre reste la détection, la réponse, la gestion des accès, la configuration, la dette technique.
• Les attaquants utilisent déjà des LLM pour accélérer la reconnaissance et travailler l’évasion. L’ENISA cite des cas d’usage incluant la reconnaissance et des stratégies d’évasion de détection d’anomalies.
• L’ingénierie sociale s’industrialise. Dans la version v1.1, l’ENISA indique qu’au début 2025, des campagnes de phishing “AI-supported” représenteraient “reportedly” plus de 80% de l’activité observée. À prendre comme un indicateur de tendance, pas comme une vérité universelle, mais la direction est claire.

Traduction DSI/RSSI: avant même de parler “agents”, vos fondamentaux logs, IAM, secrets, supervision doivent être propres. Sinon vous automatisez l’incident.

Le nœud du problème: observabilité, séparation des rôles, moindre privilège, traçabilité

Si vous ne devez retenir que quatre axes, c’est ceux-là. Ils s’appliquent très bien au terrain lyonnais: ETI industrielles, santé, services, collectivités, éditeurs SaaS. Même combat, mêmes pièges.

Observabilité: une trace corrélée, ou rien

Vous avez besoin d’une chaîne de logs qui se tiennent: identité, requête, action, effet, et un identifiant de corrélation. Les architectures “outils/agents” rendent ça plus dur, car l’action traverse plusieurs couches.

Le protocole MCP (Model Context Protocol) et son écosystème mettent justement en avant l’autorisation, l’audit “qui a fait quoi”, et la corrélation de traces entre hôte, serveur MCP et appels downstream. Microsoft documente aussi la journalisation MCP dans Global Secure Access, avec des objectifs explicites: corrélation (Transaction ID), découverte de serveurs MCP “shadow”, gouvernance des communications d’agents.

Séparation des rôles (SoD): l’agent ne doit jamais être juge et partie

Règle simple: un agent ne doit pas pouvoir agir à privilèges et modifier les preuves. S’il peut changer des politiques IAM et aussi toucher aux logs, vous avez une zone grise ingérable.

• Identités humaines: décision, validation, supervision.
• Identités agent: exécution bornée, journalisée, révocable.
• Comptes de service: strictement techniques, scellés, rotation de secrets.

Moindre privilège: minimal, mais aussi dans le temps et le contexte

Le “least privilege” classique est nécessaire, mais insuffisant. Avec des agents, il faut tendre vers just enough et just in time: droits limités, durée courte, contexte explicite, approbation quand c’est sensible.

Traçabilité: preuves exploitables, pas seulement des logs “présents”

Un log utile doit être intègre, complet et corrélé. Sinon vous collectionnez du bruit. NIST, via ses profils autour de l’AI RMF et un Cybersecurity Framework Profile for AI, insiste sur la surveillance des systèmes IA et de leurs environnements d’exécution, notamment pour détecter des activités anormales.

Avant d’automatiser: une trame d’audit en 10 points (logs et accès)

Objectif: si vous êtes DSI/RSSI à Lyon ou en AURA et que vous préparez un pilote d’agents, vous devez pouvoir répondre à deux questions.

• Est-ce que je sais ce que fait l’agent, de bout en bout?
• Est-ce que je peux l’arrêter vite, et prouver ce qui s’est passé?

1) Cartographier les “agents” comme des identités à part entière

Inventoriez: agents internes, agents dans des outils SaaS, automatisations low-code, bots ITSM, scripts “augmentés”, serveurs MCP si vous en avez. Pour chaque agent: propriétaire, finalité, environnement (dev/test/prod), outils accessibles, données manipulées.

Livrable attendu: une liste courte, maintenable. Si vous avez 40 “agents” non déclarés, vous êtes déjà en dette.

2) Vérifier la centralisation des journaux et leur immutabilité

Le prérequis: les logs critiques doivent sortir des systèmes sources vers un stockage central, avec une politique de rétention et un contrôle d’accès strict. MITRE (T1562) renvoie justement à la protection des journaux d’audit: centralisation, stockage inviolable, rétention.

• Les logs IAM, cloud, CI/CD, ITSM, EDR, proxy, DLP: centralisés?
• Immuabilité ou mécanismes anti-altération activés?
• Rétention alignée sur vos obligations et votre MTTD/MTTR réel?

3) Définir une corrélation de bout en bout (un ID par “transaction agent”)

Sans ID de corrélation, vous allez souffrir. Exigez un identifiant unique propagé à travers: orchestrateur, serveur outils (MCP ou équivalent), API downstream, logs applicatifs. L’objectif est d’enquêter vite, pas de faire de l’archéologie.

4) Auditer l’IAM agents IA: qui peut faire quoi, où, et comment

C’est le cœur de la sécurité agents IA. Regardez les permissions effectives, pas les intentions.

• Rôles attribués: trop larges? hérités? cumulés?
• Scopes API: trop permissifs?
• Accès admin: existe-t-il “par confort”?
• Segmentation par environnement: dev/test/prod séparés?

Mot-clé à couvrir ici: IAM agents IA. Un agent doit avoir un profil IAM dédié, revocable, et traçable, jamais une clé “partagée”.

5) Séparer strictement “exécution” et “observabilité” (SoD appliquée)

Checklist simple:

• Un agent peut-il modifier les règles SIEM, les exclusions EDR, les niveaux de logs, les politiques de rétention?
• Un agent peut-il supprimer des événements (tickets, historiques, traces) dans les systèmes qu’il opère?
• Les comptes qui gèrent la sécurité (SIEM, IAM, logging) sont-ils hors de portée des agents?

Si la réponse est “oui” quelque part, corrigez avant d’aller plus loin.

6) Auditer les comptes de service et tokens: rotation, portée, traçabilité

Les agents adorent les tokens longs et les comptes de service “qui marchent”. C’est exactement ce que vous devez durcir.

• Inventaire des secrets utilisés par les agents (API keys, OAuth, certificats).
• Rotation automatique et fréquence réaliste.
• Portée minimale (scopes), durée courte, restrictions IP/device quand possible.
• Traçabilité: chaque secret est associé à un seul agent, pas à une équipe.

Si vous ne savez pas quels secrets sont en jeu, vous ne pouvez pas faire un audit logs IA sérieux: vous ne savez pas qui a agi.

7) Lister les actions à haut risque et imposer une marche forcée (approval, 4-eyes, JIT)

Établissez un catalogue “actions interdites par défaut” pour les agents, sauf dérogation.

• IAM: création d’utilisateurs, élévation de rôle, modification MFA, ajout à des groupes sensibles.
• Logging/SIEM: désactivation de sources, suppression d’index, changement rétention.
• CI/CD: modification de pipelines, secrets, runners, protections de branches.
• Cloud: changements réseau (SG/NSG), IAM policies, accès stockage, KMS.

Pour ces actions: approbation humaine, ou droits JIT avec expiration automatique, ou sandbox.

8) Mettre en place une sandbox agent (et une prod “boring”)

Un agent doit apprendre et être testé dans un bac à sable qui ressemble à la prod, mais sans blast radius.

• Données de test ou données masquées.
• Comptes et ressources dédiés.
• Réseau segmenté.
• Quota et rate limiting pour éviter l’emballement.

La prod, elle, doit rester ennuyeuse: permissions minimales, chemins d’exécution limités, supervision stricte.

9) Définir les exigences de logs “agent” (contenu minimum, rétention, accès)

Un audit logs IA ne se limite pas aux logs système. Vous devez décider ce que vous journalisez côté agent, en équilibrant sécurité, confidentialité et conformité.

• Identité de l’agent et du demandeur (si délégation).
• Outil appelé, endpoint, paramètres (au bon niveau de détail).
• Résultat et effets (création, suppression, modification).
• ID de corrélation et horodatage fiable.
• Journalisation des refus et erreurs (souvent plus utile que les succès).

Point clé: qui peut lire ces logs? Un agent ne doit pas pouvoir lire ses propres traces si ça facilite l’évasion.

10) Tester la détection: scénarios “T1562-like” et réponse opérationnelle

Dernier point, le plus négligé: testez en conditions réelles votre capacité à voir une tentative d’entrave à la détection. Dans l’esprit de MITRE ATT&CK T1562.

• Simulation: baisse de niveau de logs, désactivation d’une source, purge partielle, modification d’une règle.
• Détection: alerte SIEM, alerte IAM, alerte plateforme agents.
• Réponse: qui est pagé, qui peut couper l’agent, combien de temps pour contenir.
• Preuves: pouvez-vous reconstruire la séquence “qui a fait quoi”?

Si vous échouez ici, ne lancez pas l’automatisation. Renforcez l’observabilité IA entreprise d’abord.

À quoi ressemble un “bon” niveau de sécurité agents IA, côté entreprise

Vous cherchez une cible réaliste, pas une forteresse abstraite. Voilà des critères simples.

• Chaque agent a une identité dédiée, pas de comptes partagés.
• Chaque action est corrélée via un ID propagé.
• Les logs sont centralisés et protégés, avec rétention définie.
• SoD respectée: l’agent exécute, il ne gouverne pas la sécurité ni les preuves.
• Moindre privilège dynamique: droits bornés, durée courte, approbation sur le sensible.
• Sandbox obligatoire avant tout accès prod significatif.

Si vous avez besoin d’une base de garde-fous côté agents (au-delà des logs), vous pouvez croiser avec ce guide déjà publié: https://lyon-ia.com/blog/agents-ia-10-garde-fous-avant-dautomatiser-en-entreprise-acces-donnees-actions.

Plan d’action sur 30 jours pour une DSI/RSSI en AURA

Vous voulez avancer sans vous raconter d’histoires. Faites simple, séquencé.

• Semaine 1: inventaire des agents et des accès, définition des actions à haut risque, gel des permissions “admin” non justifiées.
• Semaine 2: centralisation logs manquants, mise en place d’immutabilité/rétention, modèle de corrélation (Transaction ID).
• Semaine 3: refonte IAM agents IA (rôles dédiés, scopes minimaux, rotation secrets), séparation des rôles sur SIEM/logging.
• Semaine 4: sandbox, tests de détection type T1562, exercice de réponse, validation go/no-go sur un pilote limité.

Si vous devez arbitrer: privilégiez ce qui réduit le blast radius et ce qui améliore la preuve. Le reste est du confort.

Ce que vous gagnez en faisant cet audit avant d’automatiser

Trois bénéfices immédiats.

• Moins d’incidents bêtes: permissions trop larges, tokens oubliés, workflows qui “nettoient” trop.
• Des enquêtes faisables: vous reconstruisez vite et vous corrigez mieux.
• Une automatisation défendable: vous pouvez expliquer vos choix, y compris face à un audit, un client, ou un assureur.

Les agents ne “cassent” pas la cybersécurité. Ils rendent juste vos lacunes plus visibles, et vos erreurs plus rapides. Si vous bétonnez audit logs IA, IAM agents IA et observabilité IA entreprise avant d’ouvrir les vannes, vous gardez la main.