Ce que Proof of Actor peut établir, et ce qu'il ne peut pas.
Une description claire des classifications, des preuves qui les sous-tendent, des contextes auxquels elles s'appliquent et des limites autour desquelles nous concevons le produit.
- Signature de requêtevalid · sample-crawler.exampleverified
- Déclaration du client"research-assistant/2.1"declared
- Interaction navigateurpointer + keyboard eventsinferred
- Aucun signal pris en chargeroute not instrumentedunknown
La version courte
| Ce que Proof of Actor peut vous indiquer (lorsque cela est pris en charge) | Ce qu'il ne peut pas garantir |
|---|---|
| Qu'une signature de requête d'agent prise en charge soit valide | Que l'agent est honnête, sûr, ou autorisé à effectuer une action |
| Qu'une session expose certains signaux d'interaction ou d'automatisation | Qu'un humain n'a utilisé aucune IA en dehors de votre intégration observable |
| Que l'utilisation de l'IA ait été déclarée ou observable dans un workflow pris en charge | Détection universelle de l'assistance par IA, du contenu copié ou d'un autre appareil |
| Cette preuve était insuffisante | Qu'une interaction inconnue est malveillante |
La disponibilité dépend de votre intégration et des vérifications activées. Le propriétaire de l'application conserve le contrôle des décisions d'application.
Classifications
Quatre classes publiques. Chacune a une signification définie et une limite explicite.
- Humain
Les signaux observables pris en charge indiquent une interaction dirigée par un humain.
Ne signifie pas : Qu'aucune IA n'a été utilisée, ou que l'identité réelle de la personne est vérifiée.
- Humain + IA
L'assistance IA a été déclarée, ou détectée par une intégration prise en charge qui peut réellement l'observer.
Ne signifie pas : Que toute utilisation cachée de l'IA peut être détectée, y compris dans un autre onglet ou sur un autre appareil.
- Agent
Interaction automatisée ou d'origine agent, appuyée par une identité vérifiable ou une inférence soigneusement qualifiée.
Ne signifie pas : Que l'agent est autorisé, sûr, ou agit avec une délégation valide d'une personne.
- Inconnu
Les preuves disponibles ne permettent pas une détermination fiable.
Ne signifie pas : Que l'interaction est suspecte ou malveillante.
Vérifié, déclaré, déduit, unknown
Chaque résultat comporte une base. Une classe ne présente jamais une inférence comme une vérification cryptographique, ce qui compte surtout pour les applications sensibles à la sécurité.
- verified
- Vérifié. Une assertion cryptographique ou autrement vérifiable, validée, par exemple une signature de requête contre une clé publiée. Cela prouve ce contrôle, rien de plus.
- declared
- Déclaré. L'acteur ou votre application l'a déclaré, par exemple une divulgation d'assistance IA ou un client qui se présente comme un agent. Une déclaration peut être inexacte.
- inferred
- Inféré. Une conclusion tirée de signaux comportementaux ou contextuels. Les inférences peuvent être erronées et sont toujours étiquetées comme des inférences.
- unknown
- Inconnu. Pas assez de preuves pour statuer. Le résultat est signalé comme Inconnu plutôt que deviné.
Lorsqu'un chiffre de confiance nécessiterait derrière lui un modèle testé et calibré, nous utilisons plutôt la force qualitative des preuves. Vous ne verrez pas chez nous un chiffre du type 99.7% human à moins qu'il n'ait été mesuré et expliqué.
Contextes pris en charge et leurs limites
Navigateur
Un collecteur côté navigateur voit les sessions interactives sur les pages où il s'exécute. Il ne peut pas voir les clients qui n'exécutent pas JavaScript, l'activité dans d'autres onglets, applications ou appareils, ni le texte qu'une personne a copié depuis ailleurs.
Serveur et API
Une intégration côté serveur voit le contexte de requête et, lorsque les clients le prennent en charge, les signatures de requête. Elle ne peut pas voir l'écran d'une personne, et la plupart des clients non signés peuvent se décrire comme ils le souhaitent.
MCP
Un MCP server voit les détails déclarés du client et les appels d'outil qu'il effectue. Un nom de client déclaré est une déclaration, pas une vérification.
Deux limites à comprendre
Texte généré par l'IA depuis un autre onglet ou appareil
Si une personne pose une question à un chatbot dans un autre onglet, ou sur son téléphone, puis colle la réponse dans votre formulaire, le trafic web ordinaire n'en montre généralement rien. La session paraît dirigée par un humain parce qu'un humain l'a dirigée.
Proof of Actor signale Humain + IA uniquement lorsque l'assistance a été Déclarée, ou observée par une intégration prise en charge qui peut réellement la voir, comme la propre fonctionnalité d'assistant de votre app.
Ce qu'une requête de bot signée prouve
Une HTTP message signature validée par rapport à une clé publiée montre que la requête a été signée avec une clé associée à cet identifiant, comme le domaine d'un opérateur.
Cela n'établit pas l'identité réelle de la personne ou de l'entité derrière la requête, ni si une personne lui a délégué une autorité, ni si l'action est sûre ou autorisée. Les standards dans ce domaine, y compris les travaux IETF Web Bot Auth, sont encore des Internet-Drafts.
Pas de blocage par défaut
Proof of Actor ne bloque, ne rejette et ne défie rien par défaut. Nous déconseillons de bloquer ou de rejeter uniquement sur la base d'un résultat d'acteur Inféré, et en particulier de prendre des décisions lourdes de conséquences concernant des personnes (emploi, crédit, services financiers, éducation ou accès à des services essentiels) sur cette seule base.
L'application des politiques se fait dans votre application, selon des politiques que votre équipe choisit et confirme, avec des solutions de repli explicites pour Unknown et pour les délais d'attente.
Unknown et abstention
Lorsque les preuves ne permettent pas une détermination fiable, le résultat est Unknown. Unknown n'est jamais converti en Human, et cela ne signifie pas suspect. Le conserver visible vous indique où votre couverture s'arrête, ce qui est une information nécessaire avant d'appliquer quoi que ce soit.
Principes de confidentialité et de gouvernance
Limitation de la finalité
Les preuves décrivent les interactions au propriétaire de l'application. Elles ne sont pas utilisées pour créer des profils intersites.
Collecte minimale
Chaque intégration collecte ce dont son contexte a besoin. La télémétrie sensible nécessite un consentement explicite.
Isolement des locataires
Les preuves d'un client ne sont jamais visibles pour un autre client.
Rétention configurable
La conservation est convenue avec chaque équipe fondatrice pendant l'intégration.
Accès contrôlé par le client
Vous décidez qui, dans votre équipe, peut voir les éléments de preuve et les résultats.
Aucun contrôle d'identité
Aucune collecte biométrique ni vérification d'identité ne font partie de Proof of Actor.
Convenu avec chaque équipe
Performance et méthodologie
La couverture, le taux d'inconnu, les faux positifs et l'étalonnage sont mesurés avec les équipes fondatrices dans chaque contexte pris en charge, par rapport à des résultats que ces équipes connaissent déjà. La méthodologie et les résultats sont publiés ici au fur et à mesure que chaque contexte mûrit.
Des questions sur la confidentialité ou la sécurité ? [email protected]