Appliquer les règles d'agents

L'application des règles est le niveau 2 du Contrôle des agents IA de SilentShield : au lieu de seulement enregistrer les visites des agents IA, votre serveur ou votre edge applique activement votre politique par clé — chaque agent est autorisé, limité ou bloqué. Elle s'appuie directement sur le mode observation. Les composants d'enforcement (middleware Next.js, binaire sidecar, Cloudflare Worker) sont actuellement fournis sur demande en accès anticipé — contactez [email protected].

Observer d'abord, appliquer ensuite

Notre recommandation claire : activez d'abord l'observation, laissez-la tourner une à deux semaines et consultez le rapport avant de bloquer quoi que ce soit — le même déploiement par étapes que le mode apprentissage de Wordfence ou un rollout DMARC (none → quarantine → reject). Seul le rapport montre quels services IA visitent réellement votre site et ce qu'un blocage vous coûterait, par exemple des citations dans la recherche IA. Appliquer sans cette vision, c'est décider à l'aveugle.

Comment fonctionne l'application

Tous les enforcers partagent le même contrat : ils récupèrent un bundle de politique pour votre clé API, vérifient sa signature Ed25519 avec les clés publiques épinglées de SilentShield, puis décident localement — autoriser, refuser ou limiter — sans aucun appel sur le chemin de la requête.

Vous récupérez une seule fois les clés de signature épinglées sur https://api.silentshield.io/.well-known/silentshield-agent-keys. Et chaque enforcer fonctionne en fail-open : à la moindre erreur — réseau, signature, bundle expiré — la requête est laissée passer. L'application des règles ne peut jamais mettre votre site hors service.

Variantes de configuration

Next.js (Edge Middleware)

Le même adaptateur Next.js qui observe peut aussi appliquer les règles. Définissez les variables d'environnement de la politique ; le middleware applique alors votre politique à l'edge :

.envbash

AGENT_POLICY_URL=https://api.silentshield.io/api/v1/agent/policy
AGENT_OBSERVE_API_KEY=YOUR_API_KEY
AGENT_TRUSTED_KEYS=[{"kid":"…","key":"<base64 ed25519 pubkey>"}]

Reverse proxy (nginx / Caddy / Traefik)

Un seul petit binaire sidecar dessert les trois proxys : le proxy l'interroge une fois par requête via forward auth. Démarrez-le avec votre clé de site et les clés de confiance :

Terminalbash

AGENT_POLICY_URL="https://api.silentshield.io/api/v1/agent/policy" \
AGENT_SITE_KEY="YOUR_API_KEY" \
AGENT_TRUSTED_KEYS='[{"kid":"…","key":"<base64 ed25519 pubkey>"}]' \
AGENT_SIDECAR_LISTEN=":8127" \
  ./agent-sidecar

Le sidecar répond sur GET /auth par 204 (autorisé), 403 (refusé) ou 429 avec Retry-After (limité). Voici comment le raccorder à votre proxy :

nginx.confnginx

location = /_ss_auth {
    internal;
    proxy_pass              http://127.0.0.1:8127/auth;
    proxy_pass_request_body off;
    proxy_set_header        Content-Length "";
    proxy_set_header        X-Forwarded-Method $request_method;
    proxy_set_header        X-Forwarded-Uri    $request_uri;
    proxy_set_header        X-Forwarded-Host   $host;
    proxy_set_header        X-Forwarded-For    $remote_addr;
    proxy_set_header        User-Agent         $http_user_agent;
    proxy_set_header        Signature          $http_signature;
    proxy_set_header        Signature-Input    $http_signature_input;
    proxy_set_header        Signature-Agent    $http_signature_agent;
}
location / {
    auth_request /_ss_auth;
    # ... your normal proxy_pass to the origin ...
}

Caddyfilecaddy

example.com {
    forward_auth 127.0.0.1:8127 {
        uri /auth
        copy_headers User-Agent Signature Signature-Input Signature-Agent
        # Caddy sends X-Forwarded-Method/-Uri/-Host automatically
    }
    reverse_proxy origin:8080
}

traefik.ymlyaml

http:
  middlewares:
    silentshield:
      forwardAuth:
        address: "http://agent-sidecar:8127/auth"
        authRequestHeaders:
          - "User-Agent"
          - "Signature"
          - "Signature-Input"
          - "Signature-Agent"

Cloudflare Worker

L'enforcer Cloudflare Worker vérifie le bundle de politique via Web Crypto Ed25519 et bloque avant même que les requêtes n'atteignent votre origin :

Terminalbash

cd enforcers/cloudflare-worker
npx wrangler secret put AGENT_SITE_KEY
# set AGENT_POLICY_URL + AGENT_TRUSTED_KEYS in wrangler.toml [vars]
npx wrangler deploy

Limites honnêtes

Les navigateurs agentiques sur des adresses IP résidentielles (Comet, ChatGPT Atlas et similaires) sont techniquement impossibles à distinguer des visiteurs humains. Aucun produit ne peut les identifier de manière fiable — SilentShield ne fait donc délibérément aucune promesse d'application pour cette catégorie.

robots.txt et les signaux de contenu émis sont indicatifs : les crawlers bien élevés les respectent, mais rien ne les y oblige. L'application technique n'a lieu que dans les enforcers de cette page — et même eux agissent de façon conservatrice, en ne refusant que les agents connus formellement identifiés, afin que les visiteurs légitimes ne soient jamais bloqués.

Configurer votre politique

Ce que chaque agent peut faire se configure par clé API dans le hub d'agents : Clés API → sélectionner une clé → Agent. Les préréglages couvrent les cas courants ; chaque modification devient un nouveau bundle signé que vos enforcers récupèrent automatiquement.

Ouvrir le hub d'agents →