Comment déployer des politiques sensibles aux acteurs en toute sécurité

Qu'est-ce qui peut mal se passer lorsque vous déployez des politiques sensibles aux acteurs ?

Une politique sensible aux acteurs modifie la façon dont votre application répond en fonction de qui ou de ce qui agit. Bien faite, elle offre une expérience fluide aux personnes, donne aux agents légitimes un parcours structuré et n'ajoute de la friction que là où cela compte. Mal faite, elle bloque de vrais utilisateurs, casse des intégrations dont vos clients dépendent et crée des tickets de support que personne ne peut expliquer.

La différence vient rarement de la logique de la politique. Elle vient du déploiement. (Pour le modèle de politique lui-même, voir concevoir des politiques au niveau de l'application pour les humains et les agents IA.) Ce guide décrit un processus par étapes que les équipes peuvent suivre pour n'importe quelle route : observer, prévisualiser, appliquer sur une portion, puis étendre. Chaque étape a un critère de sortie clair et un moyen rapide de revenir en arrière.

Les trois modes

Considérez chaque politique comme fonctionnant dans l'un de trois modes par route :

• Observer. Les classifications sont enregistrées. L'application répond exactement comme elle le ferait sans elles.
• Prévisualiser. La politique est évaluée et sa décision est enregistrée, mais pas appliquée. Vous pouvez voir ce qui se serait passé.
• Appliquer. La décision est appliquée aux requêtes réelles.

Le mode appartient au couple route et politique, pas à toute l'application. Vos pages de documentation peuvent être en application alors que votre parcours de paiement est encore en observation.

Étape 1 : Observer jusqu'à connaître votre référence

Commencez avec toutes les routes en mode observation. Collectez au minimum :

• la route et la méthode,
• la classe d'acteur (Human, Human + AI, Agent ou Unknown) et son fondement (verified, declared, inferred ou unknown), comme défini dans notre taxonomie pour le trafic applicatif,
• le statut de réponse et un indicateur de résultat simple pour la route, comme "compte créé" ou "la recherche a renvoyé des résultats".

Laissez tourner assez longtemps pour couvrir les cycles hebdomadaires normaux et toute version que vous publiez pendant cette période. Puis notez votre référence pour chaque route qui vous intéresse : la répartition des classes, le taux d'Unknown et le taux de résultat par classe. Vous comparerez tout ce qui suit à ces chiffres.

Critère de sortie : vous pouvez décrire, pour chaque route candidate, qui l'utilise et en quoi les résultats diffèrent selon la classe.

Étape 2 : Écrire la politique comme des données

Les politiques sont plus faciles à examiner, à tester et à restaurer lorsqu'elles sont des données plutôt que des instructions if dispersées.

type ActorClass = "human" | "human_ai" | "agent" | "unknown";
type Basis = "verified" | "declared" | "inferred" | "unknown";
type Action = "allow" | "adapt" | "challenge" | "review" | "limit";
type Mode = "observe" | "preview" | "enforce";

interface Rule {
  actor: ActorClass | "*";
  basis?: Basis[];
  action: Action;
}

interface RoutePolicy {
  route: string;
  mode: Mode;
  enforcePercent: number;
  rules: Rule[];
  fallback: Action;
}

export const policies: RoutePolicy[] = [
  {
    route: "GET /api/catalog",
    mode: "preview",
    enforcePercent: 0,
    rules: [
      { actor: "agent", basis: ["verified"], action: "allow" },
      { actor: "agent", basis: ["declared", "inferred"], action: "limit" },
    ],
    fallback: "allow",
  },
];

Chaque politique comporte un fallback explicite. C'est l'action utilisée pour les résultats Unknown, pour les délais d'attente et pour tout cas qu'aucune règle ne couvre. Le choisir délibérément est la décision de sécurité la plus importante de tout le processus.

Étape 3 : Évaluer en un seul endroit

Une seule fonction d'évaluation maintient un comportement cohérent entre les modes.

export function decide(policy: RoutePolicy, actor: ActorClass, basis: Basis): Action {
  for (const rule of policy.rules) {
    const actorMatch = rule.actor === "*" || rule.actor === actor;
    const basisMatch = !rule.basis || rule.basis.includes(basis);
    if (actorMatch && basisMatch) return rule.action;
  }
  return policy.fallback;
}

Appliquez ensuite le mode :

export function applyPolicy(policy: RoutePolicy, actor: ActorClass, basis: Basis, requestKey: string) {
  const decision = decide(policy, actor, basis);
  const inSlice = bucket(requestKey) < policy.enforcePercent;
  const enforced = policy.mode === "enforce" && inSlice;
  record({ route: policy.route, mode: policy.mode, actor, basis, decision, enforced });
  return enforced ? decision : "allow";
}

function bucket(key: string): number {
  let h = 0;
  for (const c of key) h = (h * 31 + c.charCodeAt(0)) >>> 0;
  return h % 100;
}

Le compartiment stable signifie que la même session ou le même client reste dans ou hors de l'échantillon appliqué, afin que les personnes ne voient pas le comportement changer d'une requête à l'autre.

Étape 4 : Comment mesurer les faux positifs avant d'appliquer ?

Faites passer une route au mode prévisualisation. Désormais, chaque requête enregistre la décision qu'elle aurait reçue. C'est là que vous découvrez si la politique est juste.

Un faux positif est une requête que la politique aurait restreinte mais qui aurait dû être autorisée. Vous ne pouvez pas le mesurer à partir des classifications seules, parce que la classification est précisément ce que vous testez. Mesurez-le à l'aide de signaux indépendants d'un usage légitime :

• la requête a mené à un flux normal réussi, par exemple un utilisateur connecté qui enregistre son travail,
• le client est une intégration partenaire connue ou un opérateur vérifié que vous avez accepté de servir,
• des tickets de support ou des signalements d'utilisateurs mentionnent la route concernée,
• une revue manuelle d'un échantillon de requêtes qui auraient été restreintes.

Passez un échantillon en revue à la main. Lire vingt vraies requêtes que la politique aurait challengées est le moyen le plus rapide de trouver une règle trop large.

Critère de sortie : l'ensemble des requêtes qui auraient été restreintes est dominé par un trafic que vous avez réellement l'intention de restreindre, et vous avez une explication pour chaque catégorie de faux positifs que vous avez trouvée.

Étape 5 : Appliquer sur une portion

Passez la route en application avec une petite enforcePercent. Gardez la portion assez petite pour qu'une erreur n'affecte que peu de requêtes et assez grande pour produire un signal mesurable en un jour ou deux.

Surveillez les mêmes métriques que celles définies comme votre référence :

• le taux de résultat par classe sur la route,
• les taux d'erreur et d'achèvement des challenges,
• le volume de support mentionnant la route,
• la latence, puisque l'évaluation se trouve sur le chemin de la requête.

Si les résultats du trafic Human baissent dans la portion appliquée par rapport au reste, arrêtez-vous et enquêtez avant d'étendre.

Étape 6 : Étendre progressivement

Augmentez la portion par étapes, par exemple d'une petite part à un quart, puis à la moitié, puis à tout le trafic, en restant à chaque étape assez longtemps pour voir un cycle normal. L'expansion est ennuyeuse lorsque les étapes précédentes ont été bien faites. C'est l'objectif.

Choisir les repli et le comportement en cas d'échec

Décidez à l'avance de ce qui se passe lorsque les preuves sont manquantes ou que l'évaluation ne peut pas s'exécuter.

• Fail open signifie que la requête se poursuit comme elle le ferait sans contexte d'acteur. Utilisez-le pour les routes à faible risque comme les pages publiques, la documentation et les endpoints de catalogue en lecture seule.
• Fail closed signifie que votre contrôle plus fort existant s'applique, comme une réauthentification ou une file de revue. Utilisez-le pour les actions à fort impact lorsque vous disposez déjà d'un tel contrôle.

Ne laissez jamais un timeout ou une erreur produire un résultat Human. Une preuve manquante est Unknown, et Unknown prend le repli de la route. Notre article sur pourquoi Unknown est un résultat valide lors de la classification du trafic IA explique pourquoi cette règle compte.

async function actorWithTimeout(evaluate: () => Promise<{ actor: ActorClass; basis: Basis }>) {
  const timeout = new Promise<{ actor: ActorClass; basis: Basis }>((resolve) =>
    setTimeout(() => resolve({ actor: "unknown", basis: "unknown" }), 150),
  );
  return Promise.race([evaluate(), timeout]);
}

Comment restaurer rapidement une politique ?

La restauration doit être un changement de configuration, pas un déploiement. Conservez les politiques dans un magasin que votre équipe peut modifier rapidement, et rendez ces actions instantanées :

1. Remettre une route en mode prévisualisation, ce qui arrête l'application tout en conservant la mesure.
2. Mettre enforcePercent à zéro.
3. Désactiver une seule règle sans toucher aux autres.

Enregistrez chaque changement de politique avec son auteur et son horodatage. Lorsque les résultats évoluent, la première question est toujours : qu'est-ce qui a changé ?

Éviter les décisions lourdes de conséquences sur les personnes

Les classifications d'acteurs décrivent des preuves sur une interaction. Elles ne constituent pas un jugement sur une personne. N'utilisez pas une classe inférée comme seul fondement pour des décisions qui affectent l'emploi, le crédit, l'éducation, le logement ou l'accès à des services essentiels d'une personne. Pour ces flux, utilisez le contexte d'acteur pour choisir un processus, par exemple orienter vers une revue humaine, plutôt que pour décider d'un résultat.

Communiquer avant d'appliquer

Les politiques qui affectent les clients automatisés affectent aussi les personnes et les entreprises qui les exploitent. Un peu de communication évite beaucoup de travail de support :

1. Publiez vos règles d'accès automatisé. Indiquez quelles routes sont ouvertes, quelles limites s'appliquent et comment les clients peuvent s'identifier avec des requêtes signées en utilisant HTTP Message Signatures (RFC 9421) et le projet de protocole IETF Web Bot Auth.
2. Prévenez à l'avance les partenaires et les intégrateurs. Si une intégration connue tombe dans une portion restreinte pendant la prévisualisation, contactez son propriétaire avant d'appliquer.
3. Renvoie des réponses utiles. Lorsqu'une politique limite ou challenge une requête, répondez avec un code d'état clair, comme 429 Too Many Requests avec Retry-After, et un lien vers votre documentation. Un corps lisible par machine au format Problem Details donne aux clients automatisés une raison structurée. Les agents bien conçus s'adaptent lorsqu'ils comprennent pourquoi.
4. Donnez à votre équipe support les preuves. Lorsqu'un ticket arrive à propos d'une requête bloquée, le support doit pouvoir retrouver la route, la classe, le fondement et la décision de politique sans demander à l'ingénierie.

Les équipes qui annoncent les changements et les expliquent voient beaucoup moins de surprises que celles qui modifient les règles en silence, et les clients qui s'adaptent deviennent plus faciles à reconnaître au fil du temps.

Une checklist pour chaque route

• Référence enregistrée pour la répartition des classes, le taux d'Unknown et les résultats.
• Politique écrite comme des données avec un repli explicite.
• Prévisualisation exécutée, échantillon revu, catégories de faux positifs expliquées.
• Application démarrée sur une petite portion avec surveillance des métriques.
• Comportement en cas d'échec choisi : fail open ou fail closed.
• Restauration testée avant l'extension.

Où Proof of Actor s'insère

Proof of Actor est conçu autour de ce processus. L'observation est le comportement par défaut, chaque résultat porte son fondement, et les politiques Route sont à vous de définir et d'appliquer dans votre propre code, route par route. Detect, Understand, Route : dans cet ordre.

Pour dérouler un déploiement sur votre propre application avec notre équipe, demandez un accès anticipé. Pour le flux de décision de bout en bout, lisez Comment Proof of Actor fonctionne.

Sources

• RFC 6585: Additional HTTP Status Codes, Section 4: le code d'état 429 Too Many Requests
• RFC 9110: HTTP Semantics, Retry-After: indiquer aux clients quand réessayer
• RFC 9457: Problem Details for HTTP APIs: corps d'erreur lisibles par machine
• RFC 9421: HTTP Message Signatures: comment les clients automatisés signent les requêtes
• draft-ietf-webbotauth-httpsig-protocol: brouillon IETF Web Bot Auth pour le trafic automatisé signé (travaux en cours en novembre 2026)