Définition
La base de preuve d’un résultat d’acteur décrit le type de preuve qui le sous-tend. Proof of Actor utilise quatre valeurs:
- vérifiée: une assertion cryptographique ou autrement vérifiable a réussi.
- déclarée: l’acteur ou l’application l’a indiqué.
- inférée: la conclusion a été tirée à partir de signaux comportementaux ou contextuels.
- inconnue: il n’y avait pas suffisamment de preuves pour conclure.
Chaque résultat comporte à la fois une classe (Human, Human + AI, Agent ou Unknown, décrite dans notre taxonomie du trafic applicatif) et une base. « Agent, vérifiée » et « Agent, inférée » sont des résultats différents et doivent être traités différemment.
Pourquoi la base compte
Sans base, une classification masque le poids qu’elle peut porter. Un tableau de bord qui affiche « Agent » pour une requête signée et « Agent » pour une estimation fondée sur le timing de la requête incite les équipes à appliquer la même politique aux deux. En particulier pour les applications sensibles à la sécurité, une inférence ne doit jamais ressembler à une vérification cryptographique.
Séparer la classe de la base permet d’aligner les politiques sur la solidité de la preuve:
- Une route en lecture seule pourrait autoriser tout résultat Agent.
- Une route à impact plus élevé pourrait ne considérer comme opérateurs connus que les agents vérifiés et exiger des identifiants plus robustes de tous les autres.
Les quatre valeurs en détail
Vérifiée
Quelque chose a été vérifié et a passé le contrôle. L’exemple le plus clair est une signature de message HTTP (RFC 9421) qui est validée avec une clé publiée par l’opérateur de l’agent. Une preuve vérifiée atteste de ce contrôle précis, et de rien d’autre: une signature valide montre quelle clé a signé la requête, pas que l’action est autorisée.
Déclarée
Quelqu’un l’a indiqué. Un client qui se présente comme un agent, un nom de client MCP ou une divulgation d’assistance par IA dans votre propre application sont des déclarations. Elles sont utiles, souvent sincères, et parfois fausses. L’usurpation de user-agent est l’exemple classique d’une fausse déclaration. L’en-tête User-Agent est auto-déclaré par conception.
Inférée
Le système a raisonné à partir de signaux: modèles d’interaction dans une session de navigateur, timing des requêtes, contexte navigateur manquant, détails du protocole. Les inférences peuvent être erronées, c’est pourquoi elles sont toujours étiquetées comme des inférences et pourquoi les décisions conséquentes concernant des personnes ne doivent jamais reposer uniquement sur elles.
Inconnue
La preuve ne permettait pas de conclure. Cela se rattache à la classification Unknown et doit correspondre à un repli explicite dans votre politique. Notre article sur pourquoi Unknown est un résultat valide lors de la classification du trafic IA explique pourquoi.
Base versus scores de confiance
Beaucoup de systèmes condensent les preuves en un seul nombre. Un score masque s’il provient d’une vérification cryptographique ou d’une heuristique, et un pourcentage non calibré suggère une précision qui n’existe pas. Un petit ensemble de bases nommées est plus facile à raisonner, plus facile à auditer et plus difficile à détourner.
Idées reçues fréquentes
« Déclarée signifie peu fiable. » Les déclarations sont souvent exactes et sont la seule preuve disponible pour certaines questions, comme la divulgation d’une assistance par IA. Elles ne doivent simplement pas être traitées comme des vérifications.
« Vérifiée signifie sûre. » La vérification concerne l’identité du signataire, pas l’intention ni l’autorisation.
Base de preuve dans Proof of Actor
Chaque résultat Proof of Actor indique sa base et un résumé lisible de la preuve. Les politiques s’exécutent dans votre application et peuvent utiliser ensemble la classe et la base. Voir Détection et limites ou demander un accès anticipé.
Sources
- RFC 9421: HTTP Message Signatures: la source la plus claire de preuve vérifiée
- RFC 9110: HTTP Semantics, User-Agent: un identifiant déclaré, auto-rapporté