Les API avaient autrefois un modèle de trafic simple. Un développeur s'inscrivait, recevait une clé, écrivait une intégration, et cette intégration appelait vos endpoints selon un calendrier ou lorsqu'un utilisateur cliquait sur quelque chose. La gestion des bots pour les API s'est construite autour de ce modèle: authentifier la clé, plafonner le volume, filtrer le trafic manifestement abusif et maintenir le service disponible pour tous les autres.
Ce modèle tient toujours, et les outils conçus pour cela restent importants. Ce qui a changé, c'est qui se trouve derrière les appels. La même clé API peut désormais transporter des requêtes d'une personne utilisant l'app de votre client, d'une personne qui a demandé à un assistant IA d'effectuer le travail, et d'un agent autonome exécutant une tâche en plusieurs étapes pendant la nuit. Vos contrôles existants voient une clé et un taux de requêtes. Vos décisions produit, support et policy ont souvent besoin de plus.
Proof of Actor comble cet écart. Il indique à votre API qui ou quoi agit sur chaque requête et énonce la preuve, puis laisse la décision à votre code. Cette page le compare aux principales couches de protection contre les bots API afin que vous puissiez voir où chacun s'inscrit.
La version courte
| protection des bots API | Proof of Actor | |
|---|---|---|
| Question principale | Cette requête est-elle autorisée, authentifiée et dans les limites? | Qui ou quoi agit, et quelle est la preuve? |
| Couches typiques | passerelle API, règles anti-bot WAF, clés API, limites de débit | classification des acteurs dans votre API ou MCP server |
| Identifie | Le compte ou l'intégration qui possède la clé | L'acteur derrière chaque requête: Human, Human + AI, Agent ou Unknown |
| Résultat | Allow, reject, throttle; parfois un score de bot | Une classe plus une base: verified, declared, inferred ou unknown |
| Trafic ambigu | Généralement autorisé si la clé est valide, ou rejeté par une règle | Unknown, avec un comportement de repli que vous choisissez par route |
| Qui décide de la réponse | Configuration de la passerelle et du WAF | Le code de votre application |
| Par défaut à l'installation | Application | Observation; rien ne change jusqu'à ce que vous ajoutiez une policy |
| Meilleur atout | Disponibilité, filtrage des abus, quotas, traçabilité | Servir correctement chaque acteur et comprendre l'utilisation de l'API |
Les sections ci-dessous expliquent chaque partie.
Ce que la protection des bots API fait bien
Il vaut la peine d'être précis sur le rôle de chaque couche, car Proof of Actor est conçu pour se placer à côté de toutes, et non pour en remplacer aucune.
passerelles API
Une passerelle est la porte d'entrée de votre API. Elle termine les connexions, authentifie les clés API ou les tokens, route les requêtes vers le bon service, applique les quotas et enregistre souvent l'utilisation pour la facturation et l'analytique. Elle répond rapidement et de manière cohérente à la question "cet appelant est-il autorisé à entrer, et par quelle porte?" sur chaque endpoint.
règles anti-bot WAF
Un pare-feu applicatif Web avec des règles anti-bot inspecte le trafic à la recherche de schémas d'attaque connus et d'automatisations abusives. Il peut filtrer les tentatives d'injection, bloquer le trafic provenant de sources ayant des antécédents d'abus, et challenger ou supprimer les requêtes qui ressemblent à du scraping ou à des attaques d'identifiants. C'est votre meilleure défense contre le trafic qui ne devrait jamais atteindre votre code.
clés API et tokens
Les clés et les tokens vous donnent une traçabilité. Chaque requête est reliée à un compte, vous savez donc quelle intégration a effectué un appel, vous pouvez révoquer l'accès et attribuer l'usage. Les tokens avec portée vont plus loin et limitent ce qu'un appelant peut faire.
limites de débit
Les limites de débit protègent la disponibilité. Elles empêchent une intégration de consommer la capacité destinée à tout le monde, et elles ralentissent les tentatives de force brute et d'énumération. Les limites par clé et par route sont un contrôle standard et efficace.
Ensemble, ces couches répondent très bien aux questions de protection et de traçabilité. Conservez-les.
La question à laquelle elles n'ont pas été conçues pour répondre
Aucune de ces couches n'est conçue pour vous dire quel type d'acteur se trouve derrière une requête authentifiée. Une clé valide dit quel compte possède l'intégration. Elle ne dit pas:
- si cet appel précis vient d'une personne qui appuie sur un bouton dans l'app de votre client,
- si une personne a demandé à un assistant IA d'effectuer l'action,
- si un agent autonome a effectué l'appel comme une étape d'une tâche plus longue,
- ou si personne ne peut le dire.
Cette distinction compte de plus en plus chaque mois. Une API qui sert une intégration CRM, un outil de planification ou une plateforme pour développeurs reçoit de plus en plus un trafic d'agents via les mêmes clés qui servent des apps pilotées par des humains. Si vous voulez fournir aux agents une réponse structurée, exiger une confirmation pour des écritures à fort impact déclenchées par des agents, étiqueter les soumissions assistées par IA, ou simplement mesurer la part de votre usage API qui est pilotée par des agents, vous avez besoin du contexte d'acteur.
Ce que Proof of Actor ajoute à une API
Proof of Actor renvoie l'une des quatre classes pour chaque interaction:
- Human: les signaux observables indiquent une interaction pilotée par un humain.
- Human + AI: une personne a dirigé l'interaction avec une assistance IA qui a été déclarée ou observée via une intégration prise en charge.
- Agent: interaction automatisée ou provenant d'un agent.
- Unknown: la preuve ne permet pas une détermination fiable.
Chaque résultat indique aussi sa base de preuve:
- Verified: par exemple, une HTTP Message Signature (RFC 9421) vérifiée par rapport à une clé publiée.
- Declared: le client ou votre propre application l'a déclaré.
- Inferred: signaux comportementaux ou contextuels, clairement étiquetés comme inférence.
- Unknown: aucune base fiable.
Pour les API, la base verified est particulièrement utile. Les agents qui signent leurs requêtes peuvent être vérifiés par rapport à leurs clés publiées, ce qui est l'approche derrière le travail IETF Web Bot Auth. Lisez l'explication sur Web Bot Auth pour les équipes produit pour le contexte, et le guide sur la vérification des requêtes d'agents signées pour l'aspect mise en œuvre.
Une limite compte ici. Une signature valide prouve quelle clé a signé la requête. Elle ne prouve pas que l'agent est autorisé à effectuer l'action. L'autorisation reste à sa place, dans le contrôle d'accès propre à votre API. L'entrée autorisation d'agent explique la différence.
Scores et clés versus preuve d'acteur
Certains produits de protection contre les bots associent un score à chaque requête. Un score est efficace pour une décision de blocage. Il est moins utile pour les décisions produit API, car il ne dit pas si une requête légitime était pilotée par un humain ou par un agent, et il ne sépare pas les faits vérifiés des inférences.
Les clés API ont la limite opposée. Elles sont précises sur la propriété et silencieuses sur l'acteur. La clé d'un même client peut transporter les quatre classes en une seule heure.
Proof of Actor garde ces deux distinctions visibles. Votre API voit le compte issu de la clé, la classe d'acteur issue de Proof of Actor, et la base qui la soutient. Chaque couche répond à la question qu'elle sait traiter.
Où chacun s'exécute
Les passerelles et les WAF s'exécutent à la périphérie de votre réseau ou devant vos services. Cette position est adaptée à la protection et aux quotas.
Proof of Actor s'exécute là où vit la logique de votre API. Les équipes fondatrices peuvent s'intégrer via un middleware Node.js, Next.js, une couche edge que vous contrôlez, l'API HTTP générique, ou une intégration MCP server. Voir intégrations pour la liste complète. Parce qu'il s'exécute dans votre application, il peut utiliser ce que votre API sait: la route, le workflow, le fait qu'un client se soit déclaré, et le fait qu'une signature ait été vérifiée.
Les décisions de routage restent dans votre code
Proof of Actor ne bloque rien par défaut. Il démarre en mode observation, donc son installation ne change rien à la manière dont votre API répond. Vous voyez votre mélange d'acteurs par endpoint, vous examinez la preuve pour des résultats individuels, et vous surveillez votre taux de Unknown.
Quand vous êtes prêt, vous écrivez des policies définies par l'application par route, par classe d'acteur et par base. Les résultats typiques sont:
- Allow: servir la requête normalement.
- Adapt: renvoyer une réponse structurée ou réduite pour un agent verified.
- Challenge: exiger une étape de confirmation supplémentaire, par exemple une approbation humaine pour une écriture à fort impact.
- Review: mettre l'action en file d'attente pour qu'une personne la vérifie.
- Rate-limit: appliquer une limite plus stricte à une classe et à une base spécifiques sur une route spécifique.
Vous pouvez prévisualiser une policy sur du trafic réel avant de l'appliquer, puis l'appliquer route par route. Le guide sur le déploiement sûr de policies sensibles aux acteurs couvre le processus, et la protection des actions sensibles sans bloquer les agents montre des modèles courants.
Gestion des appelants API Unknown
Chaque API reçoit du trafic qui ne peut pas être classé avec confiance. Avec les contrôles traditionnels, une clé valide signifie généralement que la requête passe, et une clé invalide signifie qu'elle ne passe pas. Il n'y a rien entre les deux.
Proof of Actor vous donne un résultat explicite Unknown et vous permet de choisir le comportement de repli par route. Les endpoints de catalogue en lecture seule peuvent rester ouverts. Les modifications de compte peuvent conserver vos contrôles plus stricts existants. Les exports en masse peuvent aller en review. Voir gestion du trafic Unknown et trafic automatisé Unknown pour les détails.
Comment ils se combinent
La configuration API la plus solide utilise chaque couche pour son propre rôle:
- À la périphérie, le WAF filtre le trafic abusif et mal formé.
- À la passerelle, les clés sont authentifiées, les quotas sont appliqués et l'utilisation est enregistrée.
- Dans l'API, Proof of Actor classe chaque requête qui passe et indique sa base.
- Dans vos handlers, les policies utilisent la classe et la base pour choisir la réponse: traitement normal pour un appel piloté par un humain, réponse structurée pour un agent verified, étape de confirmation pour une écriture à fort impact pilotée par un agent, comportement de repli pour Unknown.
- Dans l'analytique, votre équipe voit quels endpoints et workflows chaque classe d'acteur utilise, en plus des données de compte issues de la passerelle.
Rien dans cette pile n'est dupliqué. La passerelle connaît le compte, le WAF connaît les schémas de menace, et Proof of Actor connaît l'acteur.
Quand se concentrer sur quoi
Concentrez-vous d'abord sur la protection des bots API lorsque vos principaux problèmes sont les abus, la disponibilité ou l'usage non facturé: attaques par identifiants sur les endpoints d'authentification, scraping agressif, ou une intégration qui monopolise la capacité des autres.
Concentrez-vous sur Proof of Actor lorsque vos principales questions portent sur vos appelants: quelle part de votre trafic API est pilotée par des agents, quels agents appellent quels endpoints, où l'usage piloté par des humains et celui piloté par des agents diffèrent, et quelles routes nécessitent une policy sensible aux acteurs. Les cas d'usage APIs et identification des agents IA pour les API vont plus loin.
La plupart des équipes qui exploitent une API de production ont besoin de réponses aux deux.
Commencer
Proof of Actor est en private beta. Les équipes fondatrices sélectionnées peuvent bénéficier jusqu'à 12 months of free access within agreed usage limits, avec aucune facturation automatique. Demandez un accès anticipé et dites-nous quelle API et quels appelants vous souhaitez comprendre.