POLITIQUES D'ACCÈS POUR LES AGENTS

Routage des agents IA avec des politiques que vous contrôlez

Décidez de la manière dont votre application traite les personnes, les utilisateurs assistés par l'IA et les agents autonomes, route par route. Proof of Actor fournit les éléments de preuve; vos politiques prennent la décision.

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

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

Une seule politique pour tout le monde ne suffit plus

La plupart des applications ont été conçues autour d'un seul type d'utilisateur: une personne qui clique dans une interface et qui est connectée à un compte. Le contrôle d'accès suivait cette hypothèse. Si la session est valide, la requête passe. Si elle semble automatisée, un CAPTCHA ou un blocage apparaît.

Ce modèle ne tient plus. Aujourd'hui, la même application sert des personnes, des personnes travaillant avec des assistants IA et des agents autonomes agissant pour le compte de quelqu'un. Certains agents sont les propres intégrations des clients. Certains sont des assistants IA qui récupèrent de la documentation. Certains sont des crawlers. Quelques-uns tentent d'abuser de votre produit. Une règle binaire ne peut pas bien servir l'ensemble.

Le routage et les politiques d'accès pour les agents IA remplacent cette règle unique par un ensemble de décisions délibérées: quels acteurs obtiennent quelle expérience, sur quelles routes et dans quelles conditions. Proof of Actor fournit à votre application les éléments de preuve nécessaires pour prendre ces décisions, et laisse les décisions elles-mêmes entre vos mains. Pour les principes de conception derrière cette approche, lisez concevoir des politiques d'application pour les humains et les agents IA, et consultez le cas d'usage des applications SaaS pour voir comment les politiques se traduisent dans des workflows produit réels.

À quoi ressemble une bonne politique pour les agents

Une politique utile est précise. Elle nomme une route ou un workflow, une classe d'acteur, le niveau de preuve requis et la réponse. Par exemple:

Routes de catalogue en lecture seule: autoriser les agents vérifiés et fournir une réponse structurée; autoriser les agents déclarés avec la limite de débit standard.
Actions qui modifient le compte: conserver votre réauthentification existante pour tout le monde; ajouter une revue lorsque l'acteur est Unknown et que l'action a un fort impact.
Soumissions au support: accepter le contenu divulgué comme assisté par l'IA et le marquer pour le routage.
Inscription: conserver les vérifications existantes; ne jamais décider uniquement à partir d'un résultat d'acteur inferred.

Chacun de ces cas répond à l'acteur sans traiter tous les agents comme des abus et sans faire confiance aveuglément à chaque agent. Cet équilibre est tout l'enjeu d'un accès sensible aux agents, et l'article de blog sur concevoir des politiques d'application pour les humains et les agents IA développe d'autres exemples route par route.

Les cinq réponses

La capacité Route de Proof of Actor est construite autour de cinq réponses entre lesquelles vos politiques peuvent choisir.

Allow

Laisser la requête continuer normalement. La plupart du trafic, y compris la plupart du trafic d'agents sur des routes publiques ou à faible risque, devrait simplement être allowed.

Adapt

Modifier l'expérience pour l'adapter à l'acteur. Fournir une réponse API structurée ou une version Markdown d'une page à un agent vérifié plutôt qu'une interface pensée pour un humain. Le guide sur fournir du contenu structuré aux agents IA couvre ce modèle.

Challenge

Demander quelque chose de plus fort: une nouvelle connexion, un justificatif supplémentaire, une confirmation du propriétaire du compte. Utilisez les challenges sur les routes où le coût d'une mauvaise décision est élevé.

Review

Laisser l'action passer dans une file d'attente plutôt que de la mener directement à son terme, ou la signaler pour qu'un humain la vérifie. Review est utile lorsque le blocage nuirait à des utilisateurs légitimes, mais qu'une exécution sans surveillance est trop risquée.

Limit

Appliquer une limite de débit ou de volume adaptée à l'acteur et à la route, afin que les appelants automatisés ne puissent pas submerger un workflow conçu pour des personnes.

Pourquoi robots.txt n'est pas une politique d'accès

De nombreuses équipes commencent avec robots.txt, et c'est un premier signal sensé pour les crawlers. Ce n'est pas une politique d'accès pour les agents. Les opérateurs de crawlers documentent des comportements différents selon les user agents: Anthropic indique que ses bots respectent les directives robots.txt (documentation du crawler Anthropic), tandis qu'OpenAI précise que pour ChatGPT-User, qui agit lorsqu'un utilisateur pose une question à ChatGPT, les règles robots.txt peuvent ne pas s'appliquer parce que l'action est initiée par un utilisateur (documentation du crawler OpenAI). robots.txt ne dit rien non plus sur les APIs, les outils MCP ou les workflows avec session ouverte.

Une politique d'accès doit s'exécuter là où la requête est traitée, lire des éléments de preuve comme une signature vérifiée selon RFC 9421, et choisir une réponse par route. Pour les MCP servers, la spécification d'autorisation MCP définit comment les clients obtiennent des jetons d'accès via HTTP; les politiques d'acteur ajoutent du contexte par-dessus cela, elles ne le remplacent pas.

Comment Proof of Actor alimente vos politiques

Chaque requête évaluée par votre intégration produit un résultat d'acteur composé de quatre éléments que votre politique peut lire:

Class: Human, Human + AI, Agent ou Unknown.
Base: verified, declared, inferred ou unknown, afin que votre politique puisse traiter différemment une signature validée et un nom de client auto-déclaré.
Résumé des éléments de preuve: une description lisible de ce sur quoi repose le résultat, utile pour la journalisation et la revue.
Contexte: quelle intégration et quelle route l'ont produit.

Parce que la base est explicite, vos politiques peuvent être précises. "Autoriser les agents" devient "autoriser les agents verified sur les routes de lecture, appliquer une limite de débit aux agents declared, utiliser le repli Unknown pour tout le reste." Le flux complet, de la requête à la décision, est décrit dans How It Works.

Les solutions de repli font partie de la politique

Une politique n'est valable que si son comportement en cas d'absence de preuve l'est aussi. Proof of Actor rend ces cas explicites au lieu de les masquer.

Unknown: les éléments de preuve ne permettent pas de conclure. Votre politique précise ce que Unknown signifie pour chaque route. Ce n'est jamais converti en Human et jamais considéré comme malveillant par défaut.
Timeout: le résultat n'est pas arrivé à temps. Votre intégration applique le repli que vous avez choisi pour cette route.
Signaux manquants: un collecteur ne s'est pas exécuté ou un en-tête était absent. Le résultat le reflète, et votre politique le traite en conséquence.

Pour chaque route, vous choisissez si vous voulez fail open or fail closed. Fail open signifie que la requête continue comme elle le ferait sans Proof of Actor; fail closed signifie que votre vérification plus stricte existante s'applique. Les routes à faible risque sont généralement fail open. Les actions sensibles sont généralement fail closed. Vous définissez cela par niveau de risque, pas globalement.

Garder séparés l'identité, les justificatifs et l'autorisation

Les politiques d'accès pour les agents se superposent à trois couches distinctes, et le fait de les garder séparées évite les erreurs les plus graves.

Les preuves d'identité répondent à la question: quel type d'acteur appelle et qu'est-ce qui le prouve? Proof of Actor fournit cela.
Les justificatifs répondent à la question: quel compte est responsable? Votre session, token ou API key fournit cela.
L'autorisation répond à la question: cet appelant peut-il effectuer cette action? Votre modèle d'autorisations fournit cela.

Une identité d'agent verified ne signifie pas que l'agent est autorisé, qu'une personne lui a délégué une autorité ou que son action est sûre. Utilisez les résultats d'acteur pour le routage et pour ajouter du contexte. Utilisez votre modèle d'autorisation pour accorder l'accès. La page Detection & Limitations explique exactement ce que chaque type de preuve peut établir.

Déployer sans rien casser

La manière la plus sûre d'introduire des politiques d'accès pour les agents est de procéder par étapes.

Observe. Installez Proof of Actor en mode observation. Rien ne change pour vos utilisateurs; les résultats sont enregistrés.
Understand. Analysez quels acteurs utilisent quelles routes, le taux de Unknown sur chacune, et les résultats qui contredisent ce que vous savez déjà.
Preview. Exécutez une politique en preview, en journalisant ce qu'elle aurait fait sans l'appliquer.
Enforce narrowment. Activez la politique sur une route où les éléments de preuve l'étayent clairement. Surveillez les résultats.
Expand. Étendez à davantage de routes à mesure que la confiance augmente.

Le guide sur déployer des politiques sensibles aux acteurs en toute sécurité décrit chaque étape, et protéger les actions sensibles sans bloquer les agents couvre les routes à forts enjeux.

Ce que votre équipe obtient

Avec Proof of Actor, votre équipe dispose d'une seule intégration avec trois capacités. Detect collecte les signaux d'acteur et sépare les assertions vérifiées des inférences. Understand affiche des analyses d'acteurs, des tendances et les éléments de preuve derrière chaque résultat, tout en gardant Unknown visible. Route vous permet d'écrire les politiques décrites sur cette page et de les appliquer là où vous le choisissez. Pendant la bêta privée, les politiques de routage sont conçues avec chaque équipe fondatrice et exécutées dans le code de votre propre application, afin que vous conserviez un contrôle total.

Erreurs courantes de politique à éviter

Les équipes qui conçoivent pour la première fois un accès pour les agents répètent souvent quelques erreurs. Les éviter fait gagner des semaines de reprise.

Bloquer tous les agents par défaut. Les agents légitimes contourneront alors votre dispositif, souvent en exploitant l'interface que vous avez construite pour les personnes, ce qui est plus difficile à protéger qu'un chemin structuré.
Faire confiance à un nom déclaré. Un client qui se contente de se nommer lui-même a fait une déclaration, pas apporté de preuve. Traitez-le comme vous traiteriez un appelant non vérifié.
Utiliser le même repli partout. Unknown sur une page de prix publique et Unknown lors d'un changement de mot de passe sont des situations différentes. Chaque route a besoin de sa propre réponse.
Décider à propos des personnes sur la base d'une inférence. Les résultats d'acteur sont un contexte pour le routage, pas un verdict sur une personne. Conservez les décisions à conséquences dans vos propres contrôles et votre revue.
Sauter l'observation. Appliquer l'enforcement dès le premier jour signifie découvrir les faux positifs par les plaintes des clients. Observez d'abord, puis appliquez là où la preuve est claire.

Une courte revue de politique avec vos responsables sécurité, produit et support avant chaque étape d'enforcement permet de détecter la plupart de ces erreurs tôt.

Commencez avec le Founding Developer Program

Proof of Actor est en bêta privée. Les équipes fondatrices sélectionnées peuvent bénéficier jusqu'à 12 mois d'accès gratuit, dans les limites d'utilisation convenues, avec l'aide directe de nos ingénieurs pendant que vous concevez vos premières politiques.

Si vous décidez de la manière dont votre application doit traiter les agents IA, demandez un accès anticipé. Dites-nous quelles routes comptent le plus et quelles décisions vous voulez prendre, et nous vous aiderons à construire des politiques adaptées. Vous pouvez également voir comment cela s'applique aux APIs et aux MCP servers.

Sources

Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
Overview of OpenAI crawlers, OpenAI.
RFC 9421: HTTP Message Signatures, IETF, February 2024.
MCP authorization, modelcontextprotocol.io.

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

Qu'est-ce qu'une politique d'accès pour agent IA?

C'est une règle que votre application applique en fonction du type d'acteur à l'origine d'une requête, par exemple autoriser des agents vérifiés sur des routes en lecture seule ou demander un justificatif plus fort pour des actions à fort impact. Proof of Actor fournit le résultat sur l'acteur; votre politique décide de la réponse.

Proof of Actor applique-t-il les politiques automatiquement?

Non. Chaque intégration commence en mode observation, et les politiques sont activées par votre équipe, route par route, lorsque vous estimez qu'elles conviennent à ce workflow.

Que se passe-t-il lorsque l'acteur est Unknown ou que la vérification expire?

Vous définissez une solution de repli explicite pour chaque route, par exemple autoriser les lectures publiques et conserver les vérifications existantes pour les changements de compte. Unknown et les délais d'attente ne deviennent jamais Human par défaut.

Dois-je bloquer tous les agents IA?

En général non. Beaucoup d'agents sont des participants légitimes. Les politiques vous permettent de leur donner un parcours structuré, de les limiter là où c'est important et de réserver des vérifications plus fortes aux actions sensibles.

Les politiques peuvent-elles prendre des décisions concernant des personnes?

Les résultats de Proof of Actor ne doivent pas constituer la seule base de décisions ayant des conséquences pour des individus, comme l'emploi, le crédit ou l'accès à des services essentiels. Utilisez-les pour le routage et le contexte, en complément de vos propres contrôles.

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