L'application n'a jamais été ouverte

Pourquoi les agentic harnesses deviennent indispensables pour de vrais tests de sécurité mobile

Donnez une application mobile à un modèle de langage et demandez-lui d'en tester la sécurité.

La réponse peut sembler familière : stockage non sécurisé, cryptographie faible, secrets exposés, permissions excessives, SDK vulnérables, failles côté backend, défauts d'authentification, risques pour la vie privée.

Elle peut être structurée comme un rapport. Elle peut citer les bonnes catégories. Elle peut ressembler à un document qu'une équipe sécurité pourrait faire circuler.

Pourtant, l'application n'a toujours pas été ouverte.

Aucun paquet n'a été inspecté. Aucune permission n'a été confrontée au comportement à l'exécution. Aucun trafic de SDK n'a été observé. Aucun emplacement de stockage n'a été examiné. Aucun appel backend n'a été suivi. Aucun état de crash n'a été capturé. Aucune preuve n'a changé de mains.

Le rapport existait. La cible, elle, n'avait pas changé d'état.

Un moteur de raisonnement sans mains

La plupart des discussions sur l'IA en sécurité commencent encore par le modèle : lequel est le plus intelligent, lequel raisonne le mieux, lequel a la fenêtre de contexte la plus longue, lequel obtient les meilleurs résultats aux benchmarks.

Dans un vrai workflow de sécurité, le modèle n'est qu'un élément du système.

Un modèle brut peut comprendre des instructions, formuler des hypothèses, décrire des chemins d'attaque et décider de la suite. Mais tester une cible exige d'entrer en contact avec elle. Il faut décompresser l'application. Il faut examiner les permissions. Il faut identifier les SDK. Il faut inspecter le stockage. Il faut observer le trafic. Il faut tester les flux d'authentification. Il faut suivre les appels backend. Il faut écarter les pistes bruyantes. Les vulnérabilités qui subsistent doivent s'appuyer sur quelque chose de plus solide qu'un paragraphe.

Autour du modèle se trouvent les outils, le contexte, les prompts, les skills, la mémoire, les boucles d'exécution et les retours d'information qui rendent ces étapes possibles.

Quand le modèle peut toucher l'application

Un modèle lit « stockage de données sensibles » et peut décrire ce qu'il faut vérifier : préférences partagées, bases de données locales, fichiers de cache, usage du keychain, chiffrement, journaux. Les mots sont justes. L'application reste une boîte noire.

Dans un workflow doté d'un harness, l'application est décompressée. Les emplacements de stockage sont inspectés. Les fichiers de configuration sont ouverts. Le comportement à l'exécution est observé. Une valeur apparaît ou non sur le disque. Une inquiétude se nourrit de preuves ou s'estompe.

Il en va de même pour les SDK.

Un modèle peut avertir que des SDK tiers risquent d'exposer des données personnelles. L'avertissement est assez familier pour paraître utile. Mais le SDK n'a pas été identifié. Ses destinations réseau n'ont pas été observées. Ses permissions n'ont pas été comparées au trafic réel. Aucun payload n'a été inspecté.

La question change alors. Elle n'est plus « cela pourrait-il être risqué ? ». Elle devient : qu'est-ce qui est présent, qu'est-ce qui s'exécute, qu'est-ce qui sort de l'application, et quelle preuve y est associée ?

Anthropic a montré le même schéma dans le travail d'agents de longue durée : le modèle ne s'est pas amélioré de façon isolée. Le workflow autour de lui a lui aussi changé : prompts, outils, gestion du contexte, boucles de retour d'information. Les écrits d'OpenAI sur le harness engineering pointent vers le même type de travail autour des agents : critères d'acceptation, validation, outils manquants, garde-fous, documentation.

Ces exemples concernent l'ingénierie logicielle. En sécurité mobile, le même schéma apparaît autour de l'artefact, du runtime, de la sortie des outils et du prochain test que le modèle est capable de lancer.

Une réponse soignée peut tout de même laisser l'application intacte.

Une boîte à outils n'est pas un harness

Il existe une version paresseuse de la sécurité agentique : donner au modèle un tas d'outils et appeler cela un agent.

Trop de sorties brutes entrent dans le contexte. Trop d'outils sont disponibles trop tôt. Les résultats des scanners arrivent sans interprétation suffisante. Des signaux faibles deviennent des vulnérabilités affirmées avec assurance. Une chaîne suspecte devient un secret. Une permission devient une atteinte à la vie privée. Un endpoint inhabituel devient une faille backend exploitable.

Un harness utile est plus discret. Il décide de ce que le modèle voit en premier, des outils qui appartiennent à l'étape suivante, de ce qu'il faut retenir et du niveau de preuve exigé avant qu'un élément devienne une vulnérabilité.

En sécurité mobile, presque tous les signaux ont besoin de ce contexte. Une permission n'est pas automatiquement un problème de vie privée. Un SDK tiers n'est pas automatiquement malveillant. Une valeur stockée n'est pas automatiquement sensible. Une requête suspecte n'est pas automatiquement exploitable.

Une permission n'est pas une vulnérabilité

Prenons l'accès à la localisation.

Un modèle peut expliquer pourquoi l'accès à la localisation peut créer un risque pour la vie privée. C'est un contexte utile. Ce n'est pas une vulnérabilité.

Il faut vérifier la permission à l'exécution. Il faut identifier les SDK. Il faut observer le trafic. Il faut examiner les domaines de destination. Il faut inspecter les payloads. Il faut comparer la finalité déclarée de l'application avec ce qu'elle envoie réellement.

C'est seulement alors que la question devient utile.

Quand la localisation est-elle collectée ? Quel composant la collecte ? Où va-t-elle ? Est-elle envoyée avec des identifiants ? Est-elle liée à un SDK d'analytique, à un SDK publicitaire, à un endpoint backend ou à une fonctionnalité que l'utilisateur a réellement déclenchée ?

De l'extérieur, l'application ressemblait à une seule chose. Une fois inspectée, elle se révèle faite de couches : code, permissions, SDK, stockage, trafic, appels backend et comportement de la plateforme.

La catégorie était visible dès le départ. La vulnérabilité n'apparaît que lorsque les preuves circulent.

GEF rend le harness concret

Le même schéma se voit plus facilement dans l'exploitation native.

Un LLM généraliste peut décrire les étapes : rétro-ingénierie de la bibliothèque native, inspection de l'arithmétique non sécurisée, construction d'un déclencheur de crash, examen des registres, affinage d'une primitive. La méthodologie peut être correcte alors que la cible reste intacte.

Dans un cas Android JNI, le modèle était connecté à GEF, un outil d'exploitation construit autour de GDB.

L'agent a fait la rétro-ingénierie de la bibliothèque native et a trouvé une troncature d'entier de 64 bits vers 32 bits dans un calcul de taille d'image. La valeur tronquée contrôlait la taille de l'allocation sur le tas. La valeur d'origine sur 64 bits contrôlait la longueur de la copie.

L'allocation était plus petite que la copie.

Une entrée a été forgée. Le crash a été reproduit. Un pointeur de fonction indirect a été écrasé par un marqueur reconnaissable sur 64 bits. Le marqueur est apparu dans l'état du crash.

La primitive a été affinée en un appel de fonction native contrôlé, avec un premier argument contrôlé par l'attaquant. L'exécution a été redirigée vers le chargeur de bibliothèques natives d'Android. Une bibliothèque partagée conçue pour l'occasion s'est exécutée dans le processus de l'application.

Les journaux ont montré l'exécution. La routine d'initialisation de la bibliothèque a créé des artefacts de preuve.

Le parcours ne s'est pas arrêté à « dépassement de tas possible ». Il a traversé la cible : calcul, allocation, crash, contrôle, primitive d'appel, chargeur, exécution, preuve.

Le modèle a fourni le raisonnement. GEF a gardé ce raisonnement rattaché au processus en cours d'exécution.

Le travail doit pouvoir être relu

Dès qu'un agent peut agir, une autre question se pose.

Qu'a-t-il inspecté ? Quelle sortie d'outil a modifié la conclusion ? Quelles preuves ont été collectées ? Quelles hypothèses ont été posées ? Où l'investigation s'est-elle arrêtée ?

En sécurité offensive et en tests mobiles, une vulnérabilité n'est utile que si quelqu'un peut comprendre comment le système y est parvenu. Si un agent signale une exposition de données sensibles, le relecteur a besoin du chemin : le comportement de l'application, l'emplacement de stockage ou la requête, le payload, les données concernées et le raisonnement qui relie les preuves à la vulnérabilité.

Si l'agent décide de ne pas signaler un élément, cette décision a elle aussi besoin d'un chemin. Peut-être que la permission était déclarée mais jamais utilisée. Peut-être que le SDK était présent mais inactif. Peut-être que l'endpoint paraissait inhabituel mais n'exposait aucun comportement sensible.

Il en va de même pour l'exploitation. Si l'agent affirme avoir obtenu une exécution de code, le relecteur ne doit pas se retrouver avec une simple phrase indiquant que « l'exploitation a réussi ». La chaîne de preuves doit être visible, du calcul vulnérable jusqu'à la preuve à l'exécution.

Sans cette visibilité, le résultat devient difficile à défendre. Il peut être correct, mais l'équipe n'a aucune piste à suivre. Il peut être erroné, tout en arrivant avec assez d'aisance pour paraître convaincant.

Un harness consigne ce qui s'est passé : permissions, limites des outils, points d'approbation, journaux de preuves, étapes reproductibles et conditions d'arrêt.

L'agent enquête. L'équipe doit toujours pouvoir voir l'enquête.

D'un texte en forme de rapport à des tests défendables

Le modèle ne se contente plus de lister ce qu'il faudrait vérifier. Il travaille à partir de preuves issues de l'application, de sorties d'outils, du comportement à l'exécution, du trafic, de signaux sur les dépendances, de traces d'exploitation et d'étapes reproductibles. Le résultat d'une étape modifie la suivante.

Le résultat change aussi de forme. Au lieu d'une checklist plus propre, on obtient un parcours à travers la cible. Au lieu d'un paragraphe plausible, on obtient des artefacts qu'un relecteur peut inspecter. Au lieu de « cela peut être risqué », on obtient une chaîne qui peut être contestée.

Une équipe sécurité peut ouvrir l'artefact. Suivre la trace. Rejouer les étapes. Inspecter la preuve à l'exécution.

Pas un modèle qui parle comme un pentesteur.

Une trace capable de résister à un pentesteur.