Passer au contenu principal
COMMENT ÇA MARCHE

Comment fonctionne Proof of Actor.

Un parcours fondé d'abord sur les preuves, de l'interaction entrante à la décision de l'application.

Demander un accès anticipéVoir la détection et les limites
politique · example-app.test
  • /api/v1/catalogenforceAgentAutoriser · API structurée
  • /support/ticketsenforceHumain + IAAutoriser · étiqueter comme Human + AI
  • /account/*previewInconnuConserver les contrôles existants
  • /api/v1/orderspreviewAgentExiger un identifiant plus fort

De l'interaction à la décision

  1. 01Requête ou événement d'applicationUne page vue, un appel API, un appel d'outil MCP ou une action dans l'app.
  2. 02Signaux provenant de l'intégration prise en chargeSeulement ce que cette intégration peut observer dans ce contexte.
  3. 03Normalisation et classification des preuvesLes signaux sont vérifiés, étiquetés selon leur base et combinés.
  4. 04Résultat d'acteur avec base et incertitudeHuman, Human + AI, Agent ou Unknown, ainsi que son fondement.
  5. 05Dashboard et analysesTendances, routes et preuves à examiner par votre équipe.
  6. 06La décision propre à votre applicationObserver uniquement, ou appliquer une politique que vous avez choisie.
POUR LES DÉVELOPPEURS

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent ou Unknown.
basis
Niveau de solidité des preuves : Verified, Declared, Inferred ou Unknown.
evidence
Les signaux derrière le résultat, pour que votre équipe puisse voir pourquoi.

Commencez en mode observation : enregistrez les résultats à côté de vos logs et ne changez rien tant que vous n'avez pas choisi une politique. Lire le guide d'intégration Node.js

Le mode observation est la valeur par défaut

L'installation de Proof of Actor ne bloque ni ne modifie aucune requête. Les résultats sont enregistrés afin que votre équipe puisse les comparer aux résultats réels de l'application, examiner les faux positifs et décider si une politique est appropriée.

Types de preuves

Les preuves disponibles dépendent de l'intégration et du contexte. Les vérifications de chaque flux de travail sont convenues avec l'équipe pendant l'onboarding, et les détails internes des signaux restent privés afin d'être plus difficiles à imiter.

  • Signatures de requête

    Signatures cryptographiques de clients automatisés qui publient leurs clés.

  • Déclarations

    Un client qui se désigne lui-même comme agent, ou une déclaration d'assistance par IA dans votre app.

  • Signaux d'interaction

    Signaux provenant d'un collecteur navigateur approuvé, sur les pages où il s'exécute.

  • Contexte de la requête

    En-têtes et détails de protocole disponibles pour une intégration côté serveur.

L'identité d'un agent n'est pas une autorisation

Une requête signée provenant d'un client automatisé peut montrer que la requête a été signée avec une clé associée à un identifiant publié, comme le domaine d'un opérateur. C'est une preuve utile pour savoir quel client l'a envoyée.

Cela n'indique pas qui a instruit l'agent, si une personne lui a délégué une permission, l'identité légale derrière lui, ni si l'action est sûre. Ce sont des questions distinctes auxquelles votre application répond avec sa propre authentification, autorisation et politique.

trois questions distinctes
  • Qui appelle ?Proof of Actor : signature, déclaration ou inférence
  • Quel identifiant ?Votre clé API, votre jeton OAuth ou votre session
  • Que peut-il faire ?Votre autorisation et votre politique

Comment les décisions de routage s'intègrent

Votre application appelle Proof of Actor, reçoit un résultat et applique ses propres règles. Vous choisissez, par route et par niveau de risque, si l'intégration échoue en ouverture (la requête se poursuit comme elle le ferait sans Proof of Actor) ou échoue en fermeture (votre vérification plus forte existante s'applique).

  • Délai d'attente API dépassé

    Si un résultat n'est pas disponible à temps, votre intégration utilise la solution de repli que vous avez choisie pour cette route. Un délai d'attente ne devient jamais un résultat Human.

  • Télémetrie manquante

    Si le collecteur du navigateur n'a pas été exécuté ou qu'un signal est absent, le résultat le reflète. Les preuves manquantes réduisent ce qui peut être affirmé; cela n'est pas considéré comme suspect.

  • Classifications Unknown

    Unknown est un résultat normal. Votre politique définit ce que Unknown signifie pour chaque route, par exemple: autoriser les pages publiques, conserver les vérifications existantes sur les modifications de compte.

  • Preuve obsolète

    Les preuves ont un moment et un périmètre. Un résultat obtenu plus tôt dans une session ne doit pas être réutilisé pour une action ultérieure, plus sensible, sans vérification fraîche.

Le flux d'intégration bêta

  1. 01AppliquerParlez-nous de l'application et de l'interaction que vous souhaitez comprendre.
  2. 02PérimètreConvenez de l'intégration, des routes, des limites d'utilisation et du traitement des données.
  3. 03Intégrer en mode observationAucun changement dans la manière dont votre app répond.
  4. 04ValiderComparez les résultats avec la vérité terrain que vous connaissez: couverture, taux d'inconnu, faux positifs, latence.
  5. 05DéciderActivez une politique uniquement là où les preuves la soutiennent.

Ce que nous mesurons avec les équipes fondatrices

Couverture, taux d'inconnu, faux positifs par rapport aux résultats connus et latence ajoutée, dans chaque contexte pris en charge.

Commencez en mode observation.

Postulez pour rejoindre le founding developer program.

Demander un accès anticipéVoir la détection et les limites

Vous préférez en parler d'abord ? Parler aux fondateurs