IDENTIFICATION DES AGENTS IA

Identification des agents IA pour les APIs

Votre API sait déjà quelle clé a effectué une requête. Proof of Actor vous indique quel type d'acteur se trouvait derrière, quelle preuve étaye ce résultat, et laisse votre code décider de la suite.

Obtenir un accès anticipé Découvrir le fonctionnement

Par Toshendra SharmaFondateur et CEO, AgentCredia · Updated November 13, 2026

Votre API connaît la clé. Elle ne connaît pas l'acteur.

Chaque requête API arrive avec une certaine preuve de qui paie pour elle : une clé API, un jeton OAuth, une session. Cette preuve répond bien à une question. Elle vous indique quel compte est responsable de l'appel. Elle ne vous dit pas ce qui effectue réellement l'appel à cet instant.

Une seule clé API peut être utilisée par un développeur qui teste dans un terminal, par un travail backend exécuté selon un horaire, par une personne qui travaille avec un assistant IA, et par un agent autonome à qui l'on a remis la clé avec pour mission d'achever une tâche. Ce sont des acteurs très différents. Ils ont des rythmes différents, des modes de défaillance différents et des profils de risque différents. Les traiter tous de la même façon signifie soit restreindre excessivement l'automatisation légitime sur laquelle vos clients s'appuient, soit sous-protéger les parties de votre API qui ne devraient jamais être pilotées par un agent sans supervision.

L'identification des agents IA pour les APIs comble cet écart. Au lieu de tout déduire de la clé, vous obtenez une classification de l'acteur derrière chaque requête, ainsi que la preuve qui l'étaye. C'est ce que Proof of Actor est conçu pour fournir, et le cas d'usage des APIs montre comment les équipes API l'appliquent route par route.

Pourquoi les équipes API ont besoin maintenant d'un contexte d'acteur

Le trafic automatisé vers les APIs n'a rien de nouveau. Les scripts, les intégrations et les robots d'exploration font depuis toujours partie du paysage. Ce qui a changé, c'est la nature de l'automatisation. Les agents IA peuvent lire la documentation, enchaîner les appels, réessayer de manière créative et agir au nom de personnes qui ne suivent pas chaque étape. Beaucoup sont utiles et bienvenus. Certains sont mal conçus. Quelques-uns sont hostiles.

Sans contexte d'acteur, les équipes API ont tendance à se replier sur des outils grossiers :

Des limites de débit par clé, qui ralentissent les bons agents et les mauvais agents de la même manière.
Des règles basées sur le user-agent, qui cessent de fonctionner dès qu'un client change un en-tête.
Des blocages globaux, qui poussent l'automatisation légitime à scraper votre application web à la place.

Le contexte d'acteur vous permet de répondre avec précision. Un agent signé provenant d'un opérateur que vous reconnaissez peut obtenir une limite plus élevée sur les routes de lecture. Un appelant inconnu qui touche une route d'écriture peut être invité à présenter des identifiants plus forts. Une personne qui utilise un assistant IA peut conserver une expérience normale. Le but n'est pas d'arrêter les agents. Le but est de donner à chaque type d'appelant le bon chemin. Pour savoir ce qu'une requête signée peut et ne peut pas vous dire, lisez ce que prouvent les requêtes signées des agents IA.

Comment fonctionne l'identification des agents IA dans Proof of Actor

Proof of Actor suit le même flux fondé d'abord sur la preuve pour chaque requête. Vous pouvez lire le déroulé complet dans Comment cela fonctionne ; voici la version courte pour les équipes API.

1. Signaux provenant de votre intégration

Votre intégration transmet à Proof of Actor les signaux disponibles dans ce contexte. Pour une API, cela signifie généralement des éléments de contexte de requête comme les en-têtes et les détails du protocole, toutes signatures cryptographiques de requête fournies par le client, ainsi que les déclarations que le client fait à son sujet. Chaque signal est étiqueté avec son origine.

2. Classification avec un fondement

Les signaux sont vérifiés et combinés en l'une des quatre classes publiques :

Human : les signaux observables indiquent une interaction dirigée par un humain.
Human + AI : l'assistance IA a été déclarée ou détectée par une intégration capable de l'observer.
Agent : trafic automatisé ou d'origine agentique, étayé par une identité vérifiable ou par une inférence soigneusement qualifiée.
Unknown : la preuve ne permet pas d'établir une détermination fiable.

Chaque résultat comporte également son fondement : verified, declared, inferred ou unknown. C'est la partie que les équipes API apprécient le plus. Une requête dont la signature de message HTTP, telle que définie dans RFC 9421, est validée par rapport à une clé publiée est signalée comme verified. Un client qui se contente de se nommer comme agent est signalé comme declared. Un schéma qui ressemble à de l'automatisation est signalé comme inferred. Vous n'avez jamais à vous demander si un résultat repose sur la cryptographie ou sur une heuristique. Le fondement de la preuve fait partie de la réponse.

3. Un résultat sur lequel votre code peut agir

Le résultat revient à votre application avec la classe, le fondement et un résumé lisible de la preuve. Votre code décide quoi en faire. En mode d'observation, vous l'enregistrez simplement. Quand vous êtes prêt, vous l'utilisez dans vos routes.

Ce que votre équipe obtient : Detect, Understand, Route

Proof of Actor est un seul produit avec trois capacités.

Detect

Rassemblez les signaux d'acteur que votre API peut voir et séparez les affirmations vérifiées des inférences comportementales. Les requêtes d'agents signées, les clients déclarés, les signaux d'automatisation et les résultats Unknown restent tous distincts, afin que rien ne soit discrètement fusionné en un seul score.

Understand

Voyez quels acteurs appellent quelles routes, comment cela évolue dans le temps et quelle preuve se trouve derrière chaque classification. Le taux d'Unknown reste visible, ce qui vous indique exactement où s'arrête votre couverture et où un signal plus fort serait utile.

Route

Écrivez des politiques par route et par niveau de risque : allow, adapt, challenge, review ou rate-limit. Conservez un chemin structuré et souple pour les agents vérifiés sur les endpoints en lecture seule. Demandez des identifiants plus forts pour les opérations à fort impact. Définissez un repli explicite pour Unknown et pour les délais d'attente, afin que votre API se comporte de manière prévisible quoi qu'il arrive. Vous décidez comment chaque politique échoue, en ouvert ou en fermé, selon le coût d'une erreur sur cette route.

La preuve d'identité, les identifiants et l'autorisation sont trois choses différentes

L'erreur la plus courante dans la conception d'APIs conscientes des agents consiste à fusionner trois questions distinctes en une seule. Proof of Actor les garde séparées, et votre conception devrait le faire aussi.

Preuve d'identité : quel type d'acteur appelle, et qu'est-ce qui le prouve ? C'est ce que fournit l'identification des agents IA. Une signature vérifiée associe une requête à une clé et à l'identifiant publié de son opérateur. Le groupe de travail IETF Web Bot Auth a pour mandat de normaliser ce type d'authentification cryptographique pour les clients automatisés, et son périmètre couvre l'authentification de l'agent plutôt que celle de l'utilisateur final.
Identifiants : quel compte est responsable de cet appel ? Il s'agit de votre clé API, jeton ou session, émis et géré par vous.
Autorisation : cet appelant est-il autorisé à faire cette chose précise ? Il s'agit de votre modèle d'autorisations.

Un agent vérifié n'est pas automatiquement un agent autorisé. Une signature valide ne prouve pas qu'une personne a délégué son autorité à l'agent, et elle ne rend pas l'action demandée sûre. Proof of Actor vous donne un contexte fiable pour la première question et laisse la deuxième et la troisième exactement là où elles doivent être : dans votre application. En savoir plus sur l'autorisation des agents et sur ce que la preuve peut et ne peut pas établir dans Détection et limites.

Unknown est une fonctionnalité, pas une défaillance

La signature des requêtes est facultative, et un client non signé peut se décrire comme il le souhaite. Un système qui force chaque requête à entrer dans Human ou Agent se trompera avec assurance une partie du temps, et vous ne saurez pas quand.

Proof of Actor signale Unknown lorsque la preuve ne permet pas d'établir une détermination. Unknown n'est jamais converti en Human et n'est jamais considéré comme malveillant par défaut. Votre politique définit ce que Unknown signifie pour chaque route : l'autoriser sur les lectures publiques, conserver vos contrôles existants sur les changements de compte, le mettre en file d'attente pour examen lorsque les enjeux sont élevés. Le fait de garder Unknown visible est ce qui rend vos autres classifications dignes de confiance. Le guide sur le traitement du trafic inconnu montre comment le concevoir.

Où l'identification des agents IA s'insère dans votre pile

Proof of Actor se place aux côtés de votre gateway, de votre authentification et de votre limitation de débit existantes. Il ne remplace aucun de ces éléments. Les emplacements typiques incluent :

Du middleware côté serveur devant vos gestionnaires de route, afin que chaque requête soit évaluée avant l'exécution de votre logique métier.
À la périphérie, afin que les signaux soient évalués avant que les requêtes n'atteignent votre origine.
Une intégration HTTP générique, afin que n'importe quelle pile puisse envoyer le contexte de requête et recevoir un résultat avec son fondement.

Les intégrations sont mises en place de manière accompagnée avec chaque équipe fondatrice pendant l'onboarding, afin que le parcours corresponde à votre architecture plutôt que l'inverse. Le hub développeur présente les chemins d'intégration disponibles aujourd'hui. Si vous exploitez des outils pour agents, le cas d'usage des MCP servers couvre les schémas spécifiques pour les appels d'outils.

Commencez en mode d'observation

Installer Proof of Actor ne modifie pas la manière dont votre API répond. Les résultats sont enregistrés afin que votre équipe puisse les comparer avec les issues que vous connaissez déjà, voir où les agents vont réellement, mesurer le taux d'Unknown sur chaque route et examiner toute classification qui semble erronée. Ce n'est qu'ensuite que vous activez une politique, route par route, lorsque la preuve le permet.

C'est ainsi que vous déployez l'identification des agents IA sans surprendre vos clients ni casser les intégrations dont ils dépendent. Le guide sur le déploiement sécurisé de politiques sensibles aux acteurs décrit la séquence étape par étape.

Rejoignez le programme fondateur pour développeurs

Proof of Actor est en version bêta privée avec un petit groupe d'équipes fondatrices de développement. Les équipes sélectionnées peuvent recevoir jusqu'à 12 mois d'accès gratuit, dans les limites d'utilisation convenues lors de l'onboarding, ainsi qu'un support d'intégration direct de la part de nos ingénieurs et une influence réelle sur ce que nous construirons ensuite.

Si vous exploitez une API et voulez savoir qui l'appelle vraiment, faites une demande d'accès anticipé. Dites-nous en quoi consiste votre API, quelles routes comptent le plus pour vous et quelles décisions vous prendriez différemment avec un contexte d'acteur. Nous vous dirons comment Proof of Actor s'intègre.

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Charte du groupe de travail Web Bot Auth (webbotauth), IETF.

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

Questions fréquentes

En quoi l'identification des agents IA est-elle différente de l'authentification par clé API ?

Une clé API vous indique quel compte a envoyé une requête. L'identification des agents IA vous indique quel type d'acteur se cache derrière la requête et quelle preuve soutient cette conclusion. Vous avez besoin des deux, et elles répondent à des questions différentes.

Proof of Actor peut-il identifier chaque agent IA qui appelle mon API ?

Proof of Actor classe chaque requête qu'il voit comme Human, Human + AI, Agent ou Unknown, et indique le fondement de chaque résultat. Lorsque la preuve n'est pas suffisamment solide, le résultat est Unknown plutôt qu'une supposition.

Identifier un agent signifie-t-il qu'il est autorisé à agir ?

Non. L'identification et l'autorisation sont distinctes. Proof of Actor fournit à votre application un contexte sur l'appelant, et vos propres règles d'autorisation décident de ce que cet appelant peut faire.

Proof of Actor bloquera-t-il les requêtes vers mon API ?

Pas à moins que vous ne décidiez que ce soit le cas. Chaque intégration commence en mode d'observation, et l'application des règles ne se fait qu'au moyen des politiques que votre équipe écrit et active.

Comment puis-je obtenir l'accès ?

Proof of Actor est en version bêta privée. Faites une demande d'accès anticipé et certaines équipes fondatrices peuvent recevoir jusqu'à 12 mois gratuits dans le cadre des limites d'utilisation convenues.

Savoir qui utilise votre app.

Private beta pour un petit groupe de développeurs fondateurs.

Obtenir un accès anticipé Voir les prix

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