Le vrai problème des identifiants pour l’IA se règle en supprimant les secrets, pas avec un détecteur d’attaques de plus

Pendant que l’industrie débat de la sécurité de l’IA, une des couches clés, la délivrance des accès, peut déjà être fermée. L’infrastructure access-first de Toqen.app tourne depuis décembre 2025.

·
Allée de centre de données avec des câbles et le titre de l’article
Un secret qui circule sur le réseau peut être pris. Une preuve qui ne quitte jamais l’appareil, non.

En septembre 2026, Dario Amodei, à la tête d’Anthropic, a publié un essai expliquant que les dispositifs de sécurité actuels ne suivent pas le rythme des modèles d’IA. Le même mois, Anthropic a publié un rapport sur les vecteurs d’attaque réels, et l’un des principaux reste le vol de jetons, de mots de passe et de clés d’API, ainsi que l’interception d’identifiants.

La communauté cherche activement comment rendre les actions des systèmes d’IA vérifiables et contrôlables. Mais pour bâtir un dispositif qui tienne, il faut nommer correctement la nature du changement.

L’IA ne casse pas le chiffrement, elle change l’échelle de l’automatisation

L’intelligence artificielle augmente l’échelle des attaques : l’erreur humaine coûte moins cher à l’attaquant, et les identifiants transportables classiques deviennent une cible encore plus tentante. Un modèle peut produire du hameçonnage personnalisé en continu, cloner une voix et ratisser des traces numériques.

Mais la logique de l’attaque ne bouge pas : trouver et voler un secret transportable, un mot de passe, un code SMS, un jeton bearer, pour le présenter au nom du titulaire. Tant qu’un secret circule sur le réseau, on peut l’intercepter, le soutirer ou l’acheter.

C’est pourquoi il faut changer non seulement les méthodes de détection, mais l’architecture même de l’accès.

L’architecture access-first

Par access-first nous entendons une architecture où la sécurité ne commence pas par la surveillance et la détection de compromission, mais par le retrait complet des secrets transportables du chemin réseau de l’authentification.

Dans Toqen.app, cela se joue au niveau du matériel et du protocole :

  1. La clé ne quitte pas l’appareil. La clé privée de signature est créée dans une puce isolée, Secure Enclave ou Android Keystore, et ne peut physiquement être extraite ni envoyée sur le réseau.
  2. Il n’y a aucun secret dans les bases de données. Le serveur ne conserve que la clé publique servant à vérifier la signature cryptographique. Une fuite de la base du service ne donne rien pour se connecter.
  3. Chaque connexion est unique. La signature est produite à nouveau pour un défi précis à usage unique. Intercepter le trafic ne permet ni d’extraire la clé privée ni de rejouer la requête signée.
  4. Protection contre le phishing relay et la substitution de context et d’origin. Contrairement à une confirmation purement mécanique, l’application Toqen.app reçoit les paramètres d’origine de la requête, le Relying Party ID, le type d’action demandée et le défi à usage unique, directement par un canal vérifié. Vous voyez le vrai nom du service et la portée de l’accès sur l’écran du téléphone, même si on vous a attiré sur un faux site ou qu’on tente de vous faire autoriser la session de quelqu’un d’autre.

Cela supprime le secret transportable en tant que classe d’attaque à l’authentification : il n’y a tout simplement rien à intercepter ni à représenter sur le réseau.

Une limite honnête. Toqen.app ferme la couche où l’accès est accordé pour la première fois. La compromission du téléphone lui-même, un logiciel malveillant dans le système ou l’exploitation de failles dans du code tiers à l’intérieur d’une session déjà ouverte relèvent d’autres couches de sécurité et demandent leurs propres réponses.

Pratique et chronologie

En parallèle du débat actuel, il existe déjà une approche qui fonctionne pour une couche précise du problème : accorder l’accès en sécurité sans jamais faire circuler d’identifiant transportable.

L’architecture de Toqen.app a été lancée en décembre 2025. Convaincu que l’interaction sûre dans les scénarios human-to-agent et agent-to-agent deviendrait un enjeu critique pour tout le secteur, j’ai adressé les documents du projet aux entreprises clés :

  • 10 avril 2026 : envoi à OpenAI de la description de Toqen.app comme infrastructure de couche d’accès pour les systèmes agentiques, dans le cadre de leur appel à contributions Industrial Policy for the Intelligence Age.
  • 15 avril 2026 : réception de la confirmation que la soumission était acceptée pour examen.
  • 27 avril 2026 : envoi de spécifications complémentaires et de formats d’intégration possibles, pilote, subvention, soutien d’infrastructure.

Les mêmes documents ont été adressés à l’équipe d’Anthropic.

Conclusion et question ouverte

Avec un flux énorme d’initiatives entrantes, il est parfaitement normal que l’examen détaillé de chaque proposition prenne du temps. Notre propos est ailleurs : un segment précis de ce problème difficile dispose déjà d’une réponse pratique, avec un noyau en service, un client mobile open source et une architecture éprouvée.

Toqen.app est ouvert à la collaboration avec les équipes qui construisent l’infrastructure de l’IA, avec les chercheurs en sécurité et avec les équipes d’ingénierie.

Le code du client mobile est ouvert à l’audit, et toute la documentation technique ainsi que les contacts sont sur toqen.app.

Si les agents d’IA gagnent toujours plus d’autonomie, la prochaine couche d’infrastructure de sécurité doit-elle se construire autour de secrets que l’on peut voler, ou autour de preuves d’accès que l’on ne peut pas emporter ?

Le démonter étape par étape

Toute la chaîne de connexion se manipule mieux qu’elle ne se lit : un mot de passe ordinaire à côté d’une signature qui ne quitte jamais le téléphone, et un simulateur d’attaques qui montre ce que l’attaquant récupère exactement dans chaque cas.

Comment fonctionne Toqen.app : une visite interactive

Lire la suite