# Usurpation de demandes d’approbation sur macOS lors de l’évaluation d’agents IA

Les demandes d’approbation sont une cible privilégiée, car elles transforment une attaque technique difficile en simple réflexe humain. Un attaquant n’a pas besoin de voler un identifiant s’il peut amener un évaluateur à approuver une demande qui paraît ordinaire, urgente et familière.

Le problème devient plus marqué lorsque des agents de programmation autonomes peuvent appeler des API ou exécuter des commandes SSH. Un évaluateur peut regarder en même temps une pull request, un terminal, une fenêtre de discussion et une série de notifications. Si l’interface d’approbation ne rend pas clairement visibles son origine et sa portée, l’évaluateur fait un travail de sécurité depuis une miniature.

La solution ne consiste pas à apprendre par cœur chaque boîte de dialogue macOS. La mémoire visuelle ne résiste pas à une fenêtre imitée par quelqu’un qui a étudié les mêmes captures d’écran. Les évaluateurs ont besoin d’une méthode répétable pour relier une approbation à trois faits : le processus qui la demande, l’action sur le point de se produire et l’endroit fiable où l’approbation est recueillie.

## Une fenêtre familière ne prouve pas à qui elle appartient

Une fenêtre qui ressemble à une demande système n’est qu’un ensemble de pixels tant que vous ne l’avez pas reliée à un processus en cours et à une demande précise. Des coins arrondis, un ordre de boutons familier, une icône dans la barre des menus, une mention de Touch ID ou une phrase qui évoque Apple ne prouvent pas son origine. Ils prouvent seulement que quelqu’un sait à quoi ressemble macOS.

La distinction paraît évidente lorsqu’on l’énonce, mais les habitudes d’évaluation la gomment souvent. Les gens demandent : « Est-ce que cela ressemble à la demande que j’ai vue la semaine dernière ? » La meilleure question est : « Quel processus a déclenché cette demande et où puis-je examiner ce processus sans me fier à cette fenêtre ? »

macOS fournit des contrôles utiles sur la provenance des logiciels. Apple explique, dans sa documentation sur le processus de signature des applications sous macOS, qu’une signature Developer ID permet de vérifier qu’un logiciel n’a pas été modifié depuis sa signature par son développeur. Apple distingue aussi cette garantie de la notarisation, qui vérifie que le logiciel soumis ne contient pas de contenu malveillant connu. Ces contrôles comptent, mais aucun ne transforme chaque phrase affichée par une application signée en demande d’autorisation fiable.

Un programme malveillant peut ne pas être signé, mais il peut aussi l’être. Un programme légitime peut être compromis. Il peut également demander une action qui n’a aucun sens pour la tâche en cours. Le design visuel de la boîte de dialogue ne peut répondre à aucune de ces questions.

Traitez toute interface d’approbation comme l’un des quatre éléments suivants jusqu’à preuve du contraire :

- Une interface macOS de consentement ou d’authentification contrôlée par macOS.
- Une fenêtre appartenant à l’application que vous vouliez utiliser.
- Une notification indiquant qu’une application demande votre attention.
- Une page web ou une surcouche conçue pour ressembler à l’un des trois premiers éléments.

La première catégorie peut utiliser des contrôles système, mais ne prenez pas de décision d’approbation sur la seule apparence. Les autres catégories relèvent du contenu applicatif. Elles peuvent être utiles, mais elles nécessitent un parcours de vérification plus solide que « je reconnais la forme de ce bouton ».

## Chaque approbation doit relier un acteur, une action et un canal

Un évaluateur ne peut prendre une décision fiable que si l’approbation relie l’acteur, l’action et le canal. La plupart des demandes faibles en identifient un seul et demandent à l’humain de deviner le reste.

L’acteur est le processus local qui effectue la demande. Dans un flux agent, ce n’est pas simplement « l’assistant de programmation ». C’est le processus concret lancé pour cette exécution, avec une autorité de signature identifiable lorsque le flux peut la fournir. Si une demande dit seulement « l’assistant IA demande une approbation », elle dissimule à l’évaluateur le fait le plus utile.

L’action est l’opération réelle. « Autoriser l’accès réseau » ne décrit pas l’action lorsque l’opération consiste à créer un utilisateur de production sur un point d’accès API précis. « Approuver SSH » ne suffit pas lorsque la commande peut être une vérification d’état en lecture seule ou un déploiement distant destructeur. L’évaluateur a besoin du verbe, de la destination et des conséquences que l’outil peut décrire honnêtement.

Le canal est l’endroit où la décision est transmise. Une notification de bureau est un moyen de livraison. Une page de navigateur peut être une interface applicative. Une fenêtre native peut être le bon plan de contrôle. Aucun de ces termes ne garantit à lui seul la sécurité. L’évaluateur a besoin d’un canal attendu qu’il peut rouvrir indépendamment.

Voici la différence en pratique.

Une demande faible dit :

> L’assistant de déploiement a besoin d’une autorisation. Autoriser ?

Une demande évaluable dit :

> Processus : exécution d’un agent local signé depuis Terminal
>
> Action : POST `/v1/releases` vers `api.example.internal`
>
> Autorité : identifiant de déploiement en production
>
> Portée : cette seule demande
>
> Canal de décision : l’application d’approbation en cours d’exécution

La seconde demande peut toujours mériter un refus. Ce n’est pas un problème. Son rôle n’est pas de rendre l’approbation rassurante. Son rôle est de rendre l’autorité demandée assez lisible pour qu’un humain puisse décider.

Cela met aussi en évidence une erreur fréquente des équipes avec les « agents de confiance ». Faire confiance à un acteur ne donne pas l’autorisation pour chaque action. Un processus peut être familier alors que sa destination est incorrecte. La destination peut être attendue alors que la portée de l’identifiant est excessive. Un flux de vérification sécurisé place ces faits côte à côte au lieu de transformer l’approbation en soutien général.

## Les notifications doivent déclencher la vérification, pas recueillir le consentement

Une notification est un mécanisme d’interruption, pas une interface d’autorisation fiable. Elle dispose de peu d’espace, entre en concurrence avec toutes les autres alertes du bureau et peut contenir un texte conçu pour provoquer un clic rapide. Si une notification dit « Urgent : approuvez avant l’expiration du déploiement », elle exerce déjà une pression avant que vous sachiez qui a créé le message ou si un déploiement existe réellement.

Les réglages Notifications d’Apple permettent de contrôler les aperçus, l’affichage des notifications sur l’écran verrouillé et leur affichage lorsque l’écran est partagé ou recopié. Apple permet également de gérer les autorisations et le mode de présentation pour chaque application. Ces réglages réduisent l’exposition indésirable, mais ils ne transforment pas le texte d’une notification en relevé de transaction fiable.

Les évaluateurs doivent utiliser une notification comme simple indicateur. Lisez le nom de l’application, notez l’heure, puis ouvrez l’application attendue depuis un emplacement connu. Si la demande est réelle, l’application doit afficher la même action en attente, avec suffisamment de contexte pour l’évaluer. Si la notification ouvre une page web, une autre application auxiliaire ou une fenêtre sans demande en attente correspondante, arrêtez-vous.

N’apprenez pas aux évaluateurs à approuver parce que l’icône de notification semble correcte. Les icônes sont petites, peuvent être inconnues et peuvent être confondues avec des noms similaires. La question importante est de savoir si la notification renvoie au plan de contrôle que vous vous attendez déjà à utiliser pour ce flux.

Désactivez les aperçus pour les outils susceptibles d’exposer sur un écran verrouillé des destinations sensibles, des noms de comptes ou des détails de demandes. Désactivez les notifications pendant le partage d’écran lorsque les participants ne doivent pas les voir. Il s’agit de réglages de confidentialité, pas de contrôles anti-usurpation, mais ils suppriment une source utile de pression et de fuite.

Une notification est particulièrement mal adaptée aux actions à fort impact, car elle oblige l’évaluateur à décider avant d’avoir le contexte. Le bon comportement est volontairement plus lent : notification, ouverture de l’application attendue, examen de la demande, puis approbation ou refus. Ce mouvement supplémentaire n’est pas une contrainte gratuite. Il empêche l’attaquant de contrôler à la fois le message et le parcours du clic.

## Les surcouches exploitent l’attention, pas une faille de macOS

Une fausse fenêtre d’approbation n’a pas besoin de contourner les contrôles de sécurité de macOS pour être dangereuse. Une application ordinaire peut dessiner une fenêtre normale, la placer au-dessus d’une autre application, lui donner un titre similaire et la faire apparaître après un déclencheur crédible. L’attaque fonctionne parce que l’évaluateur fournit lui-même l’attribution manquante.

L’explication courante est trop simple : « Une fausse demande doit être un logiciel malveillant doté de pouvoirs spéciaux sur l’écran. » Il arrive qu’un logiciel malveillant cherche à obtenir de larges autorisations, mais une surcouche convaincante ne les exige pas toujours. Toute application peut afficher son propre contenu. Un onglet de navigateur peut afficher une page qui ressemble à un écran de consentement. Une session d’assistance à distance peut demander à l’utilisateur d’approuver une étape tandis qu’un opérateur contrôle le récit.

Ne confondez pas la capacité à voir un écran avec la capacité à créer une fenêtre. Apple traite l’enregistrement de l’écran et du son du système comme une autorisation de confidentialité et de sécurité que l’utilisateur peut accorder ou refuser à des applications et à des sites web individuels. Elle contrôle la capture du contenu de l’écran et du son. Elle ne certifie pas une demande et son accord ne permet pas d’identifier le propriétaire de la fenêtre qui se trouve devant vous.

Les autorisations d’accessibilité exigent la même rigueur. Elles existent parce que des logiciels légitimes peuvent avoir besoin d’interagir avec des éléments de l’interface, mais un évaluateur ne doit pas en déduire que chaque fenêtre d’une application disposant de l’accès à l’accessibilité appartient au système. L’historique des autorisations peut contribuer à une enquête. Il ne constitue pas une preuve au moment de l’approbation.

Une vérification utile d’une surcouche commence par le comportement, pas par la décoration :

- La demande est-elle apparue immédiatement après une action que vous avez initiée ?
- Le fait de changer d’application puis de rouvrir l’application attendue révèle-t-il la même demande ?
- La demande indique-t-elle la destination et la portée avec des termes correspondant à votre travail ?
- Demande-t-elle un mot de passe, une phrase de récupération ou un secret dont ce flux ne devrait jamais avoir besoin ?
- Essaie-t-elle de vous empêcher d’examiner la demande ailleurs ?

Le dernier point permet de repérer davantage de mauvaises demandes qu’on ne l’imagine. Un véritable flux de contrôle doit supporter quelques secondes de vérification. Un flux trompeur invente souvent un compte à rebours, affirme que la demande échouera si vous quittez la fenêtre ou vous donne l’impression que la moindre hésitation causera des dommages.

## Une usurpation crédible suit une séquence reconnaissable

Imaginez qu’un ingénieur demande à un agent de mettre à jour un environnement de préproduction. La sortie du terminal de l’agent indique qu’il a besoin d’une approbation pour un appel API. Presque au même moment, une notification apparaît : « Autorisation de déploiement requise. Ouvrir le Centre de sécurité. »

L’ingénieur clique dessus. Une fenêtre s’ouvre avec un titre qui ressemble à celui d’un panneau de sécurité macOS familier. Elle contient une courte description, une destination qui commence par le domaine de l’entreprise attendu et des boutons intitulés « Annuler » et « Autoriser ». Elle mentionne même Touch ID, alors que la fenêtre ne déclenche jamais de véritable vérification biométrique.

La tromperie réussit si l’ingénieur accepte le récit visuel. Plusieurs éléments peuvent être incorrects en même temps :

1. La notification peut provenir d’une autre application que l’application d’approbation.
2. La notification sélectionnée peut avoir ouvert une page de navigateur ou un outil auxiliaire plutôt que le véritable contrôle d’approbation.
3. La destination affichée peut être un domaine ressemblant au bon, une redirection ou une autorisation de compte générale au lieu de la demande de déploiement concernée.
4. Le processus qui a lancé l’agent peut être différent de celui qui demande l’approbation.
5. L’action peut ne laisser aucune trace durable après le clic, empêchant l’évaluateur de reconstituer ce qu’il a autorisé.

C’est pourquoi un protocole de vérification doit résister à une imitation visuellement parfaite. L’ingénieur doit laisser la fenêtre ouverte sans appuyer sur l’un ou l’autre bouton, mettre au premier plan l’application d’approbation attendue depuis la barre des menus ou le dossier Applications, puis chercher une demande en attente générée par l’exécution actuelle de l’agent. En l’absence de demande correspondante, la fenêtre ne devient pas plus fiable parce qu’elle est bien réalisée.

Si une demande correspondante existe, comparez les deux descriptions. Une demande légitime doit indiquer la même action, le même point d’accès et la même autorité. Si l’application attendue affiche une commande SSH alors que la fenêtre décrit une approbation de déploiement générique, refusez les deux demandes jusqu’à ce que vous compreniez le décalage. Les attaquants profitent du fait que les évaluateurs prennent une correspondance partielle pour une confirmation.

La difficulté vient souvent du fait qu’une usurpation utilise des informations exactes. Elle peut connaître le nom du projet, celui de l’environnement et l’heure d’un véritable déploiement. Ces détails prouvent que l’attaquant dispose d’un contexte. Ils ne prouvent pas que l’action demandée appartient au processus attendu.

## Vérifiez l’application installée avant d’avoir besoin d’une approbation

Vous ne pouvez pas examiner sérieusement une identité lorsqu’une fenêtre affirme qu’une action expirera dans dix secondes. Définissez l’identité de l’application attendue lors de la configuration, consignez-la dans la documentation de l’équipe et testez le parcours de vérification pendant une journée de travail ordinaire.

Pour une application installée à un emplacement connu, cette commande affiche les informations de signature que macOS voit :

```sh
codesign -dvvv "/Applications/Expected Approval App.app" 2>&1 | grep -E 'Identifier=|TeamIdentifier=|Authority='
```

La sortie a généralement cette forme :

```text
Identifier=com.example.approvals
TeamIdentifier=ABCDE12345
Authority=Developer ID Application: Example Software, Inc. (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
```

Ne recopiez pas ces valeurs d’exemple dans une liste de contrôle. Notez l’identifiant et l’identifiant d’équipe du logiciel approuvé par votre équipe, après l’avoir obtenu par votre processus logiciel habituel. Un nom affiché constitue une preuve faible, car plusieurs applications peuvent utiliser le même nom. L’identifiant de bundle et l’équipe signataire vous donnent des faits qu’un titre de fenêtre ne peut pas fournir.

Utilisez une seconde vérification pour connaître l’état d’évaluation du bundle installé :

```sh
spctl -a -vv "/Applications/Expected Approval App.app"
```

La sortie contient généralement une évaluation telle que `accepted`, ainsi que la source et l’origine. La formulation peut varier selon les versions de macOS et les méthodes de distribution. Ne construisez donc pas un script qui échoue parce qu’il attend une phrase exacte. Utilisez cette commande comme aide à l’enquête : un refus, une origine, un chemin ou une identité de signature inattendus sont des raisons de vous arrêter et d’examiner la situation.

La documentation Gatekeeper d’Apple explique que macOS vérifie, avec ses réglages par défaut, que les logiciels téléchargés proviennent d’un développeur identifié, sont notarisés et n’ont pas été modifiés. Cela protège le parcours de lancement, ce qui est nécessaire. Cela ne remplace pas la vérification de la pertinence de l’action demandée par l’application.

Les équipes devraient conserver un relevé succinct comprenant le nom de l’application, son emplacement d’installation habituel, son identifiant de bundle, son équipe signataire et le responsable des mises à jour. Placez-le au même endroit interne que les noms d’environnements et les contacts d’incident. Lorsqu’une mise à jour modifie l’un de ces éléments, examinez ce changement dans le cadre de la mise à jour au lieu de le redécouvrir pendant une demande d’approbation.

Évitez le raccourci paresseux : « Elle se trouve dans Applications, donc c’est forcément la bonne. » Applications est un emplacement, pas une preuve d’identité. Un bundle copié ou portant un nom similaire peut aussi s’y trouver. Le chemin vous donne un objet stable à examiner. La signature fournit une déclaration d’identité. Votre processus d’équipe détermine si cette identité est attendue.

## Examinez la demande depuis un parcours indépendant

Lorsqu’une approbation apparaît, appliquez chaque fois la même courte routine. Elle doit prendre moins d’une minute pour les demandes ordinaires et fonctionner même si la première fenêtre est entièrement fausse.

1. Arrêtez-vous devant la première demande. Ne cliquez pas sur Autoriser, Fermer et ne suivez aucun lien intégré avant de savoir ce qui l’a ouverte.
2. Énoncez l’action attendue en termes simples. Par exemple : « J’ai demandé à l’agent de préproduction de lire l’état du déploiement. » Si la demande décrit une écriture en production, une session SSH ou un accès large au compte, vous avez déjà identifié une divergence.
3. Ouvrez l’application d’approbation indépendamment depuis son élément attendu dans la barre des menus, son emplacement dans Applications ou un lanceur connu. N’utilisez pas la fenêtre suspecte comme outil de navigation.
4. Trouvez la demande en attente et comparez le processus initiateur, l’action, la destination, l’autorité et la portée. Un nom de processus correspondant ne suffit pas.
5. N’approuvez que la demande la plus limitée qui permette d’accomplir la tâche actuelle. Refusez une demande peu claire, plus large que nécessaire ou incohérente avec le travail que vous avez initié.

Cette routine écarte une recommandation populaire mais mauvaise : « Approuvez une fois un agent familier afin qu’il cesse de vous interrompre. » Elle est populaire parce que les demandes répétées irritent les utilisateurs et que les agents ont souvent besoin de plusieurs appels liés. Elle est erronée, car le volume des demandes relève de la conception, et non d’une raison pour supprimer la limite de vérification.

Une meilleure conception peut autoriser un seul processus connu pendant la durée de son exécution actuelle, tout en soumettant les autorités sensibles à une confirmation distincte. L’évaluateur prend moins de décisions répétitives sans accorder une autorisation permanente à une catégorie de tâches vague.

Sallyport applique directement cette séparation : un nouveau processus agent reçoit une demande d’autorisation de session qui identifie l’autorité de signature du processus, tandis qu’un identifiant peut être configuré pour exiger une approbation à chaque utilisation. L’agent ne reçoit jamais le secret lui-même. L’approbation décide donc si l’application exécute l’action, au lieu de transmettre les identifiants à l’agent.

Cette distinction compte lors d’un véritable incident. Si une exécution agent commence à se comporter de manière étrange, révoquez sa session. N’attendez pas que l’agent atteigne le point d’approbation suivant. Une limite de session donne à l’évaluateur un moyen d’empêcher les actions futures de ce processus sans supposer que toutes les capacités précédemment approuvées restent appropriées.

## Le texte de l’approbation doit montrer la portée avant l’urgence

Les équipes passent souvent trop de temps à peaufiner le langage d’avertissement et pas assez à décider quels faits la demande doit contenir. Une meilleure phrase dans une mauvaise demande reste insuffisante. Une phrase un peu simple qui contient les faits nécessaires est plus sûre.

Mettez l’action en premier. « Créer une version en production » indique à l’évaluateur ce qui va se produire. « Autoriser le flux de déploiement » dissimule l’opération derrière un libellé interne.

Indiquez ensuite la destination. Un nom d’hôte, un dépôt, un compte ou un hôte distant indique où l’autorité sera utilisée. Si le système ne peut pas nommer la destination parce qu’il ne la connaît pas, il doit le dire. Il ne doit pas remplacer le contexte manquant par une formule rassurante comme « service de confiance ».

Exprimez la portée en termes compréhensibles. Une demande qui autorise une seule requête `GET` vers un point d’accès connu est très différente d’un identifiant disponible pour tous les appels d’une session. Une approbation SSH pour une seule commande ne correspond pas à un shell sans restriction. La demande doit décrire la limite réelle, pas une limite idéale.

Soyez honnête sur ce que l’évaluateur ne peut pas voir. Si un outil sait seulement qu’un agent va ouvrir une connexion SSH, il doit le dire au lieu de prétendre avoir inspecté chaque commande distante. Une fausse précision apprend aux utilisateurs à faire confiance à des libellés qui ne correspondent pas aux contrôles réellement appliqués.

Évitez les noms d’action vagues, en particulier ceux-ci :

- « Continuer »
- « Accorder l’accès »
- « Terminer la configuration »
- « Vérifier l’identité »
- « Autoriser l’activité de l’agent »

Chacune de ces expressions demande à l’évaluateur de déduire le sens à partir du contexte. Si ce contexte provient d’un message de terminal contrôlé par un attaquant, d’un message de discussion, d’une notification ou d’une fenêtre surgissante, l’évaluateur est devenu un élément de l’usurpation.

Un bon flux d’approbation donne aussi au refus une issue normale. « Refuser » ne doit pas sembler être une exception dangereuse. Le refus doit arrêter l’action, conserver suffisamment d’informations pour permettre un examen ultérieur et laisser l’utilisateur réessayer après avoir corrigé la demande. Lorsque le refus paraît catastrophique, les utilisateurs approuvent pour sortir d’une situation bloquée.

## Les journaux transforment le soupçon en enquête

Après une approbation douteuse, cessez de considérer l’écran comme une preuve. Les écrans disparaissent, les fenêtres peuvent mentir et la mémoire se modifie rapidement. Conservez une trace du processus exécuté, de l’action demandée, de la décision de l’évaluateur et de l’arrivée ou non de l’action à sa destination.

Commencez par consigner la période concernée. Enregistrez ensuite la transcription de l’agent, l’historique du terminal lié à l’exécution et l’historique des actions de l’outil d’approbation. Notez le chemin exact de l’application qui a affiché la demande. Si l’élément suspect est arrivé par une notification, indiquez le nom d’application affiché et précisez si son ouverture a mené vers un navigateur, un outil auxiliaire ou l’application attendue.

Ne commencez pas par supprimer l’application suspecte. Si vous devez conserver des preuves pour une enquête interne, notez d’abord son chemin et ses informations de signature. Si la machine peut être compromise, suivez le processus d’incident de votre équipe et isolez-la si nécessaire. Un événement d’usurpation de demande peut être une attaque sociale, une application locale indésirable, une compromission du navigateur ou le signe d’un défaut de conception dans un outil légitime. Les preuves vous permettront de déterminer le problème réel.

Pour les actions d’agents, le journal doit comporter deux niveaux. Un premier relevé doit décrire l’exécution et permettre à un opérateur de la révoquer. Un autre doit décrire les appels individuels, avec la destination et la décision. Sans le premier, vous ne pouvez pas arrêter proprement un acteur en cours d’activité. Sans le second, vous ne pouvez pas savoir ce que l’approbation a réellement permis.

Sallyport exporte les relevés de session et d’activité depuis un journal d’audit chiffré et chaîné par hachage, et `sp audit verify` peut vérifier la chaîne hors ligne sur le texte chiffré. Cela ne rend pas une mauvaise approbation inoffensive, mais fournit à l’évaluateur et à l’enquêteur une réponse durable à la question qui compte lorsque la fenêtre a disparu : quelle action ce processus a-t-il réellement exécutée ?

Le but n’est pas de faire de chaque évaluateur un spécialiste de la sécurité macOS. Il s’agit de rendre le comportement sûr ordinaire : quitter l’interface suspecte, rouvrir le plan de contrôle attendu, comparer les faits et approuver uniquement la demande qui correspond au travail en cours. Une demande qui ne résiste pas à cette vérification ne mérite pas un clic.