Secure Enclave et Touch ID pour les secrets des agents IA

Un agent de programmation IA doit pouvoir demander une action sans jamais recevoir l'identifiant qui l'autorise. C'est la propriété de sécurité autour de laquelle il faut construire le système. Secure Enclave et Touch ID peuvent appliquer une partie de cette propriété sur un Mac, mais uniquement si le secret reste derrière une frontière que l'agent ne peut pas lire.

Une invite Mac indiquant qu'un agent peut accéder à « GitHub » n'est pas une conception de sécurité. Un jeton ghp_... copié, une variable AWS_SESSION_TOKEN exportée ou une clé privée SSH collée dans un appel d'outil donnent à l'agent un pouvoir durable qu'aucune invite Touch ID ultérieure ne pourra retirer. La difficulté ne consiste pas à chiffrer la chaîne. Elle consiste à refuser de la transmettre à un logiciel qui relaiera du texte arbitraire.

J'ai vu cette erreur prendre plusieurs formes : un jeton placé dans .env, un assistant d'identifiants qui affiche un mot de passe, une clé privée montée dans un conteneur, puis un agent auquel on demande « d'utiliser tous les identifiants disponibles ». Chaque choix semble temporaire. Chacun fait du secret une partie de l'environnement de travail de l'agent.

Secure Enclave ne rend pas un jeton porteur inoffensif

Le Secure Enclave peut protéger des opérations cryptographiques, mais il ne peut pas rendre inoffensif un jeton porteur après sa lecture par un processus. Cette distinction détermine si Touch ID protège un secret de développeur ou ajoute simplement une invite symbolique avant la fuite.

Apple décrit le Secure Enclave comme un matériel isolé capable de créer et d'utiliser des clés privées sans exposer leur valeur en clair au processeur principal. Sa restriction documentée est importante : les clés privées du Secure Enclave y sont générées, ne peuvent pas importer de clés privées existantes en clair et prennent en charge certaines opérations de signature et d'accord de clés P-256. Un jeton API ne fait pas partie de ces clés privées. Il s'agit généralement d'une chaîne opaque qu'un service distant accepte de toute personne qui la présente. La documentation Apple Developer, « Protecting keys with the Secure Enclave », explique clairement à la fois l'isolation et ses limites.

Cela laisse trois objets distincts que l'on confond souvent :

• Une clé privée Secure Enclave est un matériau cryptographique non exportable destiné à des opérations limitées.
• Un élément du trousseau contient des données d'application chiffrées dont macOS peut restreindre l'accès.
• Un identifiant porteur est une valeur copiable qui accorde l'accès partout où un service l'accepte.

Les traiter comme des synonymes produit de mauvaises conceptions. Une clé Secure Enclave peut signer un défi sans se révéler. Un élément du trousseau peut exiger la présence de l'utilisateur avant que le système ne restitue ses données. Un jeton porteur devient un secret ordinaire dès qu'un processus reçoit ses octets.

C'est pourquoi « nous stockons le jeton dans le trousseau » ne suffit pas pour un agent. Cela répond à la question du stockage au repos. Cela ne dit pas qui peut demander le jeton, quel processus le reçoit, si ce processus peut le transmettre à un processus enfant ou s'il peut l'écrire dans stdout.

Les recommandations d'Apple sur le trousseau rendent cette frontière claire. Keychain Services peut exiger une authentification avant de restituer un élément, et le Secure Enclave ne fournit qu'un résultat de réussite ou d'échec pour la vérification biométrique. Ni l'application ni le système d'exploitation n'obtiennent les données d'empreinte. C'est une excellente protection du modèle biométrique. Cela ne dit rien de ce qu'une application autorisée fait ensuite des octets du mot de passe récupéré.

Ne demandez pas à Touch ID de résoudre un problème après avoir déjà donné un secret à l'agent.

Un meilleur modèle comporte deux couches. Le processus coffre peut récupérer ou utiliser un identifiant après la validation de la barrière par l'utilisateur. L'agent peut demander une action en indiquant un identifiant et une destination, mais il ne peut ni lire l'identifiant, ni le remplacer, ni demander à un autre outil de l'afficher. Le processus coffre effectue la requête HTTP ou l'authentification SSH et renvoie un résultat volontairement limité.

C'est une interface plus étroite. C'est aussi tout l'enjeu.

La frontière doit se trouver avant stdout et les variables d'environnement

Les secrets de développeur s'échappent par les mécanismes ordinaires bien avant qu'un attaquant ait besoin de casser le chiffrement. Les variables d'environnement, l'héritage des processus enfants, la trace du shell, les journaux de débogage, les rapports de plantage, les réponses des outils et les sorties de terminal copiées transforment tous un secret protégé en valeur portable.

Je suis direct sur ce point, car le mode d'échec est prévisible : si un agent peut exécuter printenv, lire .env, appeler un assistant d'identifiants ou obtenir une clé API comme résultat d'un outil MCP, il possède l'identifiant. Que le stockage initial utilise le trousseau, un gestionnaire de mots de passe ou un fichier chiffré ne change plus la menace.

Considérez ce flux courant :

Agent -> exécute une commande shell -> l'assistant lit le trousseau
      -> l'assistant affiche le jeton -> le shell capture stdout
      -> l'agent reçoit le jeton -> le jeton apparaît dans le contexte ou les journaux

L'invite du trousseau a peut-être fonctionné exactement comme prévu. Le système a authentifié l'utilisateur du Mac. L'assistant a ensuite transformé un élément protégé en texte, que l'agent a reçu par le même canal que les erreurs du compilateur et la sortie des tests.

C'est à ce moment que la conception échoue.

Un chemin d'accès sûr aux identifiants est très différent :

Agent -> demande « POST api.example.com/releases » avec l'identifiant « release-bot »
      -> la passerelle demande une autorisation si nécessaire
      -> la passerelle obtient ou utilise l'identifiant en interne
      -> la passerelle envoie la requête HTTPS avec l'en-tête Authorization
      -> l'agent reçoit le statut, certains en-têtes et le corps de la réponse

L'agent reçoit le résultat de l'action authentifiée, pas l'en-tête d'autorisation. Cela peut sembler être un simple choix d'API. C'est la frontière entre l'exécution déléguée et la distribution de secrets.

La même règle s'applique à SSH. Ne transmettez pas à un agent le chemin vers ~/.ssh/id_ed25519, un SSH_AUTH_SOCK capable de signer des défis arbitraires sans frontière visible, ni une commande pouvant extraire une clé d'un stockage sécurisé. Laissez un assistant à périmètre réduit établir la connexion SSH et exécuter la commande demandée. Renvoyez stdout, stderr, le code de sortie et les informations sur l'identité de l'hôte. Gardez la clé privée hors de l'arborescence des processus de l'agent.

Il y a un coût. Certains outils de développement supposent pouvoir lire directement les identifiants, et une passerelle implique des adaptateurs, des API d'outils plus étroites et parfois des frictions avec les flux d'authentification inhabituels. Je préfère payer ce coût d'ingénierie une fois plutôt que de renouveler un jeton de production après sa découverte dans la transcription d'un agent.

Ne confondez pas un disque chiffré avec un chemin d'exécution contrôlé.

Touch ID prouve la présence, pas l'intention

Touch ID peut prouver qu'une personne a validé une barrière à un instant donné. Il ne peut pas prouver que cette personne a compris la prochaine commande de l'agent, que la commande correspond à l'intention du dépôt ou que la destination est sûre.

Le framework LocalAuthentication d'Apple expose volontairement un résultat limité à l'application : le framework échange avec le Secure Enclave et renvoie une réussite ou un échec. L'application appelante fournit le texte explicatif et choisit une politique d'authentification. Cette séparation est correcte. Le système ne doit pas prétendre interpréter l'intention de l'application à partir d'un événement biométrique.

Pour le travail avec des agents, considérez Touch ID comme une barrière autour d'une capacité, pas comme l'approbation d'un texte. Une carte indiquant « Autoriser cet agent à utiliser les identifiants de production » donne trop peu d'informations à l'utilisateur. Une carte qui indique le processus signé, l'hôte cible, le libellé de l'identifiant et la durée de l'approbation, un appel ou une session, fournit des éléments concrets.

Je préfère trois moments d'autorisation distincts :

1. Déverrouiller le coffre. Tant que le coffre est verrouillé, toute action reposant sur un secret échoue. Il ne doit pas y avoir de branche « utiliser une solution de repli non protégée ».
2. Approuver un nouveau processus d'agent pour la durée de son exécution. L'approbation doit identifier l'autorité de signature du code, et pas seulement un nom de processus modifiable comme node ou python.
3. Exiger la présence de l'utilisateur pour chaque utilisation d'identifiants ayant une portée irréversible, par exemple un jeton de déploiement de production, un rôle de propriétaire cloud ou une clé SSH capable de modifier un parc de machines.

L'approbation par session est le bon choix par défaut pour les agents de programmation. Un nouveau processus constitue une frontière significative : un nouveau lancement peut utiliser un autre binaire, un autre espace de travail, d'autres variables d'environnement héritées ou une autre configuration MCP. Une approbation permanente rend les actions ultérieures silencieuses précisément lorsque leur provenance devient plus difficile à vérifier.

L'approbation par appel doit rester rare, mais elle doit être stricte lorsque l'identifiant peut causer un dommage important. Un jeton qui ouvre uniquement un outil de suivi des problèmes en lecture seule ne mérite pas une empreinte pour chaque GET. Un identifiant SSH capable d'exécuter kubectl apply en production, oui. Cela crée une interruption, et cette interruption est volontaire.

L'alternative courante consiste en un gros fichier de politiques : approuver les commandes correspondant à cette expression régulière, autoriser les domaines de cette liste, rejeter les arguments contenant certains mots. Cette approche semble évoluer facilement, car elle remplace les invites par l'automatisation. Elle crée aussi un second langage de programmation qui doit modéliser les guillemets du shell, les redirections, les wrappers, les liens symboliques, curl --config, les charges utiles encodées, l'expansion des commandes distantes et chaque nouvel outil installé par un agent.

Je ne placerais pas une autorité de production derrière une grammaire que personne n'audit après vendredi.

Utilisez plutôt une petite échelle de décision : verrouillé ou déverrouillé, cette session est-elle approuvée, cet identifiant nécessite-t-il une nouvelle approbation ? Ces contrôles gardent un sens clair lorsqu'une analyse d'incident commence.

Les contrôles d'accès du trousseau ont des limites précises

Un élément du trousseau protégé par biométrie n'est utile que si vous choisissez soigneusement la contrainte d'accès, comprenez son comportement de repli et empêchez le processus autorisé de devenir un distributeur de secrets.

Apple documente SecAccessControlCreateWithFlags pour associer des exigences d'accessibilité et d'autorisation à un élément du trousseau. Pour un secret local de développeur qui ne doit pas migrer par sauvegarde ou par iCloud Keychain, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly est généralement la classe de stockage la plus sensée. Elle exige un code d'accès et rend l'élément indisponible si ce code est supprimé ; le suffixe ThisDeviceOnly l'empêche aussi d'être transféré vers un autre appareil.

Pour un secret qui doit exiger une vérification biométrique, utilisez un indicateur de contrôle d'accès plutôt que d'ajouter une invite autour d'une simple recherche dans le trousseau. Ce fragment Swift simplifié stocke un mot de passe générique que seul l'ensemble biométrique actuellement enregistré peut libérer :

import Security

let access = SecAccessControlCreateWithFlags(
    kCFAllocatorDefault,
    kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
    .biometryCurrentSet,
    nil
)!

let item: [CFString: Any] = [
    kSecClass: kSecClassGenericPassword,
    kSecAttrService: "com.example.agent-gateway",
    kSecAttrAccount: "release-bot",
    kSecAttrAccessControl: access,
    kSecValueData: Data(token.utf8)
]

let status = SecItemAdd(item as CFDictionary, nil)
precondition(status == errSecSuccess)

biometryCurrentSet est plus strict que biometryAny. Il lie l'accès aux empreintes ou aux données faciales actuellement enregistrées, de sorte que la modification de l'ensemble biométrique enregistré invalide l'élément protégé. biometryAny accepte toute donnée biométrique enregistrée et ne fournit pas le même signal de changement. Apple répertorie les deux indicateurs dans SecAccessControlCreateFlags ; choisissez le premier lorsqu'une nouvelle empreinte doit entraîner un reprovisionnement délibéré.

La récupération nécessite un contexte d'authentification et une invite d'opération qui décrit l'action en termes compréhensibles :

import LocalAuthentication
import Security

let context = LAContext()
context.localizedReason = "Use release-bot for the requested deployment action"

let query: [CFString: Any] = [
    kSecClass: kSecClassGenericPassword,
    kSecAttrService: "com.example.agent-gateway",
    kSecAttrAccount: "release-bot",
    kSecReturnData: true,
    kSecMatchLimit: kSecMatchLimitOne,
    kSecUseAuthenticationContext: context,
    kSecUseOperationPrompt: "Authorize credential use"
]

var result: CFTypeRef?
let status = SecItemCopyMatching(query as CFDictionary, &result)

Le code est volontairement incomplet sur un point : il ne dit pas quoi faire de result. Une application classique pourrait le convertir en Data, créer un en-tête Authorization et poursuivre. Une passerelle pour agent doit garantir que ces données restent dans le processus qui effectue l'appel authentifié. Ne les renvoyez pas dans la réponse MCP. Ne les placez pas dans un fichier temporaire. Ne les écrivez pas dans les journaux lorsque la requête échoue.

Soyez prudent avec les fenêtres de réutilisation. L'exemple d'Apple montre que la validation de Touch ID peut réutiliser pendant une durée configurée un récent déverrouillage de l'appareil, jusqu'à cinq minutes. Cette commodité évite aux applications ordinaires de multiplier les invites. Pour un point de contrôle d'agent, elle peut effacer le moment d'approbation délibérée que vous vouliez imposer. N'utilisez pas de période de grâce pour les identifiants qui exigent une validation à chaque utilisation, sauf si vous avez décidé consciemment et documenté de l'accepter.

Une autre limite mérite d'être mentionnée. Les données biométriques peuvent échouer, être indisponibles ou se verrouiller après plusieurs tentatives infructueuses. Apple expose des politiques qui autorisent le repli vers le code de l'appareil et d'autres qui exigent la biométrie. Décidez laquelle correspond à votre garantie de sécurité. Si vous dites « Touch ID à chaque déploiement de production », accepter discrètement une autre solution de repli modifie cette garantie, et le texte de l'interface doit le refléter.

Suivez une instruction malveillante jusqu'au point où elle réussit

Un agent n'a pas besoin d'un exploit spectaculaire pour détourner un identifiant. Il lui suffit d'une instruction plausible, d'une capacité trop large et d'un canal de sortie qui renvoie plus que ce que l'utilisateur voulait.

Imaginez un agent de programmation qui aide sur une pull request. Il lit un document du dépôt ajouté par un attaquant. Le document affirme que la vérification de la version exige l'exécution d'un script assistant. Ce script utilise la session cloud CLI existante du développeur, répertorie les identifiants de déploiement et envoie une requête encodée vers un point de terminaison externe. L'agent peut exécuter des commandes shell et a hérité de AWS_PROFILE, de GH_TOKEN ou d'un accès à un agent SSH.

Le premier échec s'est produit avant l'exécution du script : le développeur a donné à l'agent des identifiants ambiants. Le deuxième s'est produit lorsque l'exécuteur d'outils a laissé l'agent choisir des destinations réseau arbitraires. Le troisième s'est produit lorsque les journaux et la sortie des commandes ont renvoyé des éléments d'authentification ou des informations de session dans le contexte de l'agent.

Touch ID lors de la connexion n'aurait pas sauvé cette conception. La personne peut s'être authentifiée une heure auparavant, puis s'être éloignée. Un élément du trousseau protégé seulement par « appareil déverrouillé » peut devenir disponible pour un processus que l'utilisateur n'avait jamais voulu autoriser pour cette tâche. Apple avertit elle-même que l'accès lorsque l'appareil est déverrouillé n'est pas assez restrictif pour tous les cas d'utilisation.

Modifions maintenant l'architecture. L'agent demande une action avec ces champs :

{
  "channel": "http",
  "credential": "release-bot",
  "method": "POST",
  "url": "https://api.example.com/releases",
  "body": {"branch": "feature/fix-ci"}
}

La passerelle résout release-bot en interne. Elle compare la destination demandée avec l'action qu'elle va effectuer, demande une autorisation si l'identifiant l'exige, ajoute elle-même l'en-tête, puis enregistre l'action. L'agent reçoit le statut HTTP et une réponse expurgée. Il ne voit jamais la valeur de l'en-tête.

Le document du dépôt peut encore convaincre l'agent de demander un mauvais déploiement. C'est pourquoi l'examen de la destination et de l'action compte. Mais le document ne peut pas demander à l'agent d'exfiltrer un jeton qu'il n'a jamais détenu. Il ne peut pas non plus réutiliser ce jeton contre un autre service après la fin de l'appel approuvé.

Il s'agit d'une réduction réelle de la portée d'une compromission, pas de magie. Un agent compromis qui a l'autorisation de déployer peut toujours déployer quelque chose de nuisible. Le système limite le vol d'identifiants et rend l'action attribuable ; il ne résout pas l'examen de code malveillant et ne remplace pas le jugement humain.

Lorsque j'examine des configurations d'agents, je cherche le premier endroit où une instruction peut devenir une chaîne secrète. C'est généralement là que se trouve la correction.

Les handles de capacité sont plus sûrs que les chaînes secrètes

Un agent doit demander une capacité nommée avec des paramètres d'action structurés, tandis qu'un processus local de confiance résout cette capacité en identifiant et effectue l'effet de bord.

Le mot « capacité » est souvent employé de manière vague. Ici, il désigne une référence utile uniquement à l'intérieur de la passerelle, comme release-bot, staging-ssh ou billing-read. Ce n'est pas un alias de jeton que l'agent pourrait échanger contre le jeton. Ce n'est pas une variable modèle qui s'étend en valeur d'environnement. C'est un sélecteur transmis à un processus qui conserve l'accès exclusif à l'identifiant.

Ce choix impose de la rigueur à l'interface des outils. Les outils HTTP doivent accepter la méthode, l'URL, les en-têtes que l'agent peut fournir sans danger et le corps. L'injection de l'identifiant doit avoir lieu après validation, à l'intérieur de la passerelle. Les outils SSH doivent accepter un hôte, un utilisateur, une commande et une identité d'identifiant sélectionnée, puis appeler un assistant qui possède le chemin d'authentification. Ils ne doivent pas renvoyer un chemin IdentityFile ni proposer une opération générique « lire un secret ».

C'est ici qu'une interface sobre l'emporte. Un shell général héritant de tous les identifiants du développeur prendra en charge davantage d'outils dès le premier jour. Il sera aussi presque impossible de répondre à la question : quel agent a utilisé quel compte pour quelle requête sortante ? Une interface HTTP et SSH limitée offre moins de possibilités initiales, mais préserve les faits nécessaires à une décision de sécurité.

Sallyport suit ce modèle : l'agent utilise le shim stdio intégré sp mcp pour demander des actions HTTP ou SSH, tandis que l'application conserve les identifiants API et SSH dans son coffre chiffré et effectue elle-même l'action. L'agent reçoit le résultat, pas les identifiants en clair.

La limite est assumée. Un outil qui ne connaît que HTTP et SSH ne couvrira pas automatiquement toutes les applications de bureau, tous les clients de bases de données, tous les registres de paquets ou tous les binaires locaux de l'environnement d'un développeur. L'ajout d'un canal doit nécessiter la conception de son modèle d'action, de son comportement d'expurgation, de sa sémantique d'autorisation et de ses champs d'audit. Un bouton général « exécuter n'importe quoi avec ma connexion » est plus facile à livrer et plus difficile à défendre.

Utilisez des libellés d'identifiants explicites qui indiquent leur portée prévue. prod-deployer vaut mieux que token-4. github-readonly-org vaut mieux que github. Le libellé fait partie de la décision humaine et de l'enregistrement d'audit ; l'ambiguïté devient donc un problème opérationnel plutôt qu'une simple préférence de nommage.

Gardez le format de la requête assez étroit pour que la passerelle puisse l'afficher sans l'interpréter. Un réviseur peut comprendre POST https://api.example.com/releases. Il ne peut pas déduire de manière fiable l'effet d'un blob Base64 transmis par un wrapper shell.

Une piste d'audit doit décrire l'action sans copier le secret

Une passerelle d'identifiants a besoin de deux types d'enregistrements : la session d'agent qui a obtenu l'autorité et chaque effet de bord qu'elle a tenté. Un flux unique de journaux de terminal ne peut pas fournir les deux sans perdre le contexte ou divulguer des données sensibles.

Enregistrez la session lorsqu'un nouveau processus d'agent demande un accès. Capturez l'identité du processus disponible pour la passerelle, son autorité de signature, l'heure de démarrage, la décision d'approbation et l'état de révocation. Si l'utilisateur révoque la session, les demandes ultérieures de ce processus doivent échouer même si le processus reste actif.

Enregistrez chaque action séparément. Pour HTTP, conservez le libellé de l'identifiant, la méthode, la destination, le statut, la durée et un résumé soigneusement choisi du corps. Pour SSH, conservez le libellé de l'identifiant, l'hôte, l'utilisateur distant, la commande, le code de sortie et la durée. N'enregistrez pas les en-têtes Authorization, les valeurs porteuses, les octets des clés privées, les corps complets contenant des données client ni une sortie de commande sans restriction.

Les journaux qui contiennent des secrets deviennent un autre coffre, avec des contrôles d'accès moins bons.

La preuve d'intégrité est importante, car un incident impliquant un agent commence souvent par une chronologie contestée : « L'agent a-t-il appelé ce point de terminaison ? » « La session a-t-elle été approuvée ? » « Quelqu'un a-t-il modifié l'historique local ? » Un journal d'événements chaîné par hachage fournit un objet concret à vérifier ultérieurement. La vérification doit fonctionner sans devoir déchiffrer chaque événement, sinon la personne chargée de vérifier l'intégrité doit d'abord recevoir les données sensibles que le journal était censé protéger.

Sallyport construit ses journaux Sessions et Activity à partir d'un journal d'audit chiffré, chaîné par hachage et inaccessible en écriture, et sp audit verify vérifie la chaîne hors ligne sans clé du coffre. Cette propriété est utile, car l'examen de l'intégrité ne doit pas nécessiter l'accès aux secrets du développeur.

Une chaîne de hachage n'empêche pas une machine compromise de tenter une mauvaise action. Elle rend plus difficile la réécriture discrète de la séquence enregistrée et fournit à l'enquête une suite d'événements cohérente. Ne la présentez pas comme une mesure de prévention.

Apple Platform Security et la documentation Apple Developer Security sont utiles ici, car elles séparent les protections matérielles, les contrôles du système et les responsabilités de l'application. Cette séparation est exactement ce dont la sécurité des agents a besoin. Le matériel sécurisé peut contrôler l'accès, mais l'application choisit toujours ce qu'elle envoie sur le réseau et ce qu'elle écrit sur le disque.

L'accès à la production exige moins de chemins, pas des suppositions plus intelligentes

Le déploiement le plus sûr pour les agents de programmation IA consiste à commencer par un petit ensemble d'identifiants nommés, des destinations connues, une identité de session visible et une classe d'action irréversible nécessitant une nouvelle approbation. L'accès ambiant et étendu invite à découvrir le modèle de menace pendant une panne.

Utilisez cette liste avant d'autoriser un agent à toucher à un identifiant :

1. Vérifiez que l'agent ne peut pas lire le secret par des variables d'environnement, des fichiers, un assistant d'identifiants, la sortie d'un outil ou un processus enfant.
2. Vérifiez que le processus de confiance effectue la requête HTTP ou l'authentification SSH et injecte l'identifiant après réception de paramètres structurés de l'agent.
3. Configurez le verrouillage du coffre pour refuser toute action reposant sur un secret. Testez-le avec l'application verrouillée, pas seulement avec l'écran du Mac verrouillé.
4. Exigez une nouvelle approbation de session au démarrage d'un processus d'agent et faites en sorte que l'approbation identifie son autorité de signature.
5. Marquez les identifiants ayant une portée de déploiement, d'administration, de destruction ou d'accès SSH étendu afin qu'ils nécessitent une autorisation à chaque utilisation.

Testez les cas difficiles. Ajoutez un faux secret tel que canary-agent-secret-9f31 à un identifiant hors production. Demandez à l'agent d'inspecter le dépôt, d'exécuter les tests et de présenter la sortie des outils. Recherchez ensuite cette chaîne exacte dans sa transcription, l'historique du terminal, les répertoires temporaires, les journaux, l'environnement des processus enfants et les enregistrements d'audit. Si elle apparaît quelque part en dehors du processus coffre, la conception a remis à l'agent un chemin vers le secret.

Faites de même pour la révocation. Approuvez une session, effectuez une requête sans danger, révoquez la session alors que le processus reste ouvert, puis tentez à nouveau la même requête. La seconde requête doit échouer avant d'atteindre le service distant. Un contrôle de révocation qui ne prend effet qu'après un redémarrage n'est pas un confinement, mais de la documentation.

N'utilisez pas une invite biométrique comme décoration autour d'une exportation d'identifiant. Placez l'invite à la frontière où l'utilisateur autorise un processus ou une action précise, et gardez l'identifiant du côté protégé. C'est ainsi que Secure Enclave et Touch ID deviennent des contrôles utiles pour les agents de programmation IA, plutôt qu'une histoire rassurante sur le stockage.