Passer au contenu principal
APIS

Comprenez qui appelle votre API.

Ajoutez le contexte d'acteur à chaque requête API : quel client appelle, quelle est la solidité des preuves, et ce que votre API doit faire, route par route.

Obtenir un accès anticipéDécouvrir le fonctionnement
example-app.test · résultat d'acteur

POST /api/v1/orders

Agentbasis: inferred

Preuve

Trafic avec clé API sans contexte navigateur et avec un schéma de requêtes automatisé

Votre politique: Demander l'identifiant plus fort avant de créer la commande

Une clé API n'est pas une identité, et une identité n'est pas une permission.

La plupart du trafic API arrive avec un identifiant qui indique quel compte paie, et non quel client appelle ni qui l'a demandé. Certains clients signent leurs requêtes, beaucoup ne font que déclarer un nom, et beaucoup ne disent rien du tout.

Proof of Actor sépare les trois questions auxquelles chaque API doit répondre, afin que chacune bénéficie de la bonne preuve et du bon contrôle.

trois questions distinctes
  • Qui appelle ?Identité d'acteur : 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

Proof of Actor répond à la première. Votre stack conserve les deux autres.

Ce que les équipes API font avec le contexte d'acteur

  • Reconnaître les clients signés

    Vérifiez les signatures des requêtes par rapport aux clés publiées et voyez à quel opérateur appartient une requête.

  • Traiter les déclarations comme des déclarations

    Enregistrez les noms de client déclarés par eux-mêmes et gardez-les séparés de l'identité vérifiée.

  • Politiques par route

    Autorisez librement les lectures à faible impact et demandez davantage sur les écritures et les endpoints à fort impact.

  • Voir chaque appelant

    Comprenez quels clients utilisent quels endpoints, y compris les inconnus.

  • Séparer les identifiants

    Les clés API et OAuth décident toujours de l'accès. Le contexte d'acteur ajoute qui appelle.

  • Plan pour Inconnu

    Définissez ce qui se passe lorsqu'un appelant ne fournit aucune preuve exploitable, route par route.

01 · Détecter

Preuves de chaque requête.

Les intégrations serveur, edge et HTTP API lisent les signatures des requêtes, les détails client déclarés et le contexte de la requête, puis attribuent à chacun sa base.

  • Signatures HTTP vérifiées à partir des clés publiées.
  • Noms de clients déclarés enregistrés comme déclarations.
  • Capturez le contexte de la requête depuis votre serveur, votre passerelle ou votre périphérie.
signaux · dernière requête par source
  • 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

02 · Comprendre

Savoir qui utilise quel endpoint.

Voir la répartition des acteurs sur chaque route, quels opérateurs vous contactent le plus, et où les appelants inconnus se concentrent.

  • Appelants par route et par opérateur.
  • La preuve derrière chaque classification.
  • Taux Unknown par endpoint.
trafic par route · 7 jours
  • /dashboardInconnu 7%
  • /api/v1/catalogInconnu 15%
  • /support/ticketsInconnu 8%
  • /signupInconnu 21%
HumainHumain + IAAgentInconnu

03 · Routage

Des contrôles adaptés à l'impact.

Rédigez des politiques au niveau des routes : réponses structurées pour les agents Verified, limites standard pour les clients Declared, identifiants renforcés pour les actions à fort impact.

  • Politiques par route, classe et base.
  • Passez à des identifiants plus forts quand cela compte.
  • Observer, prévisualiser, puis appliquer.
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

Exemples de décisions

De la requête au résultat, puis à votre décision.

  • Un agent vérifié lit votre catalogue

    Requête

    GET /api/v1/catalog

    Résultat

    Agentbasis: verified

    Votre décision

    Autorisez avec la limite de débit agent et la réponse structurée.

  • Un client automatisé passe une commande

    Requête

    POST /api/v1/orders

    Résultat

    Agentbasis: inferred

    Votre décision

    Demandez l'identifiant plus fort de l'app avant de créer la commande.

  • Un client sans preuve

    Requête

    GET /api/v1/catalog

    Résultat

    Inconnubasis: unknown

    Votre décision

    Route en lecture seule : autoriser avec la limite de débit par défaut.

Déployer sans risque

Les équipes commencent en mode observation et avancent route par route.

  1. 01

    Observer chaque route

    Ajoutez le middleware ou l'API HTTP devant votre API. Les signatures, les déclarations et les appelants Unknown sont enregistrés par route.

  2. 02

    Prévisualiser les politiques de route

    Vérifiez ce que des limites de débit pour agents ou des justificatifs de montée en niveau auraient fait sur du trafic réel avant leur application.

  3. 03

    Appliquer selon l'impact

    Laissez les lectures ouvertes, resserrez les écritures et laissez les clés API et OAuth contrôler l'accès.

Fonctionne avec votre pile

  • Équipes fondatrices

    Middleware de serveur web (Node.js)

    Côté serveur

    Signaux au niveau de la requête pour les applications rendues côté serveur et les APIs.

  • Équipes fondatrices

    Next.js

    Côté serveur et edge

    Middleware pour les pages et les routes API.

  • Équipes fondatrices

    Script navigateur

    Signaux navigateur uniquement

    Signaux d'interaction provenant de sessions de navigateur, en complément d'une intégration côté serveur.

  • Équipes fondatrices

    Cloudflare et runtimes de périphérie

    Edge

    Signaux à la périphérie avant que les requêtes n'atteignent votre origine.

  • Équipes fondatrices

    API HTTP générique

    N'importe quelle stack

    Envoyez le contexte de la requête à une API et recevez un résultat avec sa base.

  • Équipes fondatrices

    Serveur MCP

    MCP

    Contexte d'acteur pour les appels d'outils MCP.

  • Feuille de route

    WordPress

    Plugin

    Plugin pour les sites WordPress.

  • Feuille de route

    Mobile natif

    iOS et Android

    SDK natifs iOS et Android.

Les intégrations sont réalisées en pratique avec chaque équipe fondatrice pendant l'onboarding. Vous utilisez une pile différente ? Dites-le-nous lors de votre candidature.

En savoir plus

Lire Détection et limites

Questions fréquentes

Les clients doivent-ils signer leurs requêtes ?

Non. Les requêtes signées fournissent la preuve la plus solide, mais Proof of Actor enregistre aussi les déclarations et les inférences, chacune étiquetée selon sa base, et signale Inconnu lorsqu'il n'y en a pas assez.

Une signature valide signifie-t-elle que le client est autorisé à agir ?

Non. Il montre que la requête a été signée avec une clé liée à un identifiant publié. Ce que cet opérateur peut faire est décidé par votre autorisation et votre politique.

Remplace-t-il les clés API ou OAuth ?

Non. Les identifiants contrôlent toujours l'accès. Proof of Actor ajoute qui ou quoi appelle, afin que vous puissiez appliquer de meilleures politiques par-dessus.

Pouvons-nous définir des règles différentes par endpoint ?

Oui. Les politiques sont écrites par route, donc les endpoints en lecture seule et les écritures à fort impact peuvent être traités différemment.

Quel est le coût ?

Les équipes fondatrices sélectionnées peuvent bénéficier jusqu'à 12 months free dans les limites d'utilisation convenues.

Savoir qui appelle votre API.

Rejoignez le programme fondateur développeur de Proof of Actor.

Obtenir un accès anticipéEspace développeur

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