Passer au contenu principal
Les règles firewall statiques attrapent les appels que vous saviez nommer. Elles ne peuvent pas attraper l’appel qui est individuellement autorisé mais erroné en agrégat — 200 appels db.query à 3h du matin dimanche, un agent martelant un outil défaillant dans une boucle serrée, un saut outil-à-outil que cet espace de travail n’a jamais fait auparavant. Chaque appel passe chaque règle ; le pattern est le problème. La détection d’anomalies du firewall est la couche comportementale. La passerelle apprend la forme normale d’usage des outils de votre espace de travail et score l’activité en live contre elle, faisant remonter les déviations sur un flux que n’importe quel Member peut lire. C’est votre moyen de remarquer un agent compromis ou une boucle emballée sans avoir pré-écrit une règle pour une forme que vous n’aviez jamais vue. Cette page est la page d’atterrissage ciblée pour ce flux de détection d'anomalies du firewall ; la Vue d’ensemble du Firewall est la référence approfondie.
Le flux d’anomalies est de la détection, pas de l’application. Il vous dit ce qui paraît anormal — il ne bloque pas. Quand un pattern est réel, vous le transformez en une règle ou un verdict rate-limité de sorte que la prochaine occurrence soit arrêtée en ligne. Lire le flux est ouvert à chaque Member ; transformer une découverte en politique est Developer+.

​
1. Ce que la détection d’anomalies du firewall signale

Quatre sortes de signaux, chacune liée à un mode de défaillance différent :
Le volume d’appels par outil scoré contre une baseline heure-de-la-semaine apprise. Un outil déclenche rate_spike quand son compte dépasse un plancher absolu et tourne haut par rapport à la baseline pour cette heure, ou quand son z-score franchit le seuil. Le keying sur l’heure-de-la-semaine (pas l’heure-du-jour) signifie que mardi-14:00 est comparé aux mardi-14:00 passés, de sorte que le trafic de pic légitime en semaine ne se lit pas comme un pic alors que le même volume à 3h du matin dimanche le fait.
La même comparaison heure-de-la-semaine, appliquée au coût accumulé plutôt qu’au nombre d’appels. Un outil dont la dépense tourne bien au-delà de sa norme de coût apprise apparaît comme un burn_spike — le signal d’avertissement précoce pour un agent qui est coûteux avant d’être destructeur.
Un groupe (conversation, tool, arguments) qui se répète de nombreuses fois dans une fenêtre courte — un agent coincé à ré-émettre le même appel d’outil défaillant au lieu de récupérer. Un polling lent et légitime ne le déclenche pas ; le signal est une boucle serrée.
Une transition consécutive tool_a → tool_b pour laquelle cet espace de travail n’a aucune baseline apprise. La première fois qu’un agent passe, disons, de crm.read → http.fetch, cette arête est inédite — exactement le genre d’étape qu’une chaîne d’exfiltration de données emprunte.
La détection d’anomalies complète les règles de séquence. Une règle de séquence correspond à une chaîne que vous avez définie à l’avance ; novel_path signale une transition que vous n’avez pas définie — c’est votre moyen de découvrir les chaînes pour lesquelles il vaut la peine d’écrire une règle de séquence.

​
2. La baseline sur 14 jours

Le détecteur n’est pas un seuil fixe — c’est une norme apprise. Pour chaque bucket (tool, hour-of-week), la passerelle garde un nombre d’appels et un coût attendus glissants, backfillés à partir d’un lookback de 14 jours (environ deux occurrences de chaque bucket heure-de-la-semaine — assez pour lisser un seul jour étrange sans perdre la forme hebdomadaire). novel_path utilise la baseline de transition parallèle : le nombre d’occurrences appris pour chaque arête tool_a → tool_b dans cette heure-de-la-semaine. Un espace de travail tout neuf n’a pas encore de baseline. C’est bien : sans norme apprise, les détecteurs de volume retombent sur un plancher absolu, de sorte qu’un déluge évident est quand même attrapé dès le premier jour pendant que les normes par heure se remplissent.
SignalCe dont il apprend
rate_spike / burn_spikeLe compte et le coût par (tool, hour-of-week), glissants sur 14 jours.
novel_pathLe compte de transition par (tool_a → tool_b, hour-of-week).
retry_loopAucune baseline — un seuil de répétition fenêtré sur (conversation, tool, args).
Le flux rapporte uniquement des noms d’outils, des ids de tokens redactés et des comptes. Un id de clé API brut n’apparaît jamais — chaque item porte un digest à sens unique du token appelant, de sorte que vous pouvez distinguer deux anomalies sans que le flux ne fuite jamais la clé derrière elles.

​
3. Une lecture concrète

Disons qu’une clé d’agent commence à boucler. Tirez le flux dans la console sous Security → Firewall → Anomalies, ou lisez-le directement — n’importe quel Member le peut : 
curl https://api.orcarouter.ai/api/workspace/firewall/anomalies \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN"

{
  "data": {
    "items": [
      {
        "id": "3f1c9a7b0e2d4a86",
        "kind": "retry_loop",
        "tool_name": "db.query",
        "token_id_redacted": "sk-***-9f2a",
        "count": 412,
        "baseline": 0,
        "z_score": 0,
        "suggested_action": "rate_limit",
        "first_seen": 1749470400,
        "last_seen": 1749470520
      }
    ],
    "snoozed_until": 0
  }
}
Un item retry_loop ne porte aucun baseline ni z_score (ces champs restent 0 — ils appartiennent aux détecteurs de volume/coût), et il porte un id opaque stable de sorte que deux boucles distinctes sur le même outil ne se télescopent pas sur une seule ligne. Un rate_spike est l’inverse : il rapporte une baseline apprise et un z_score, et laisse id vide.
$ORCA_SESSION_TOKEN est votre session / token d’accès de console — la même auth que chaque route de gestion /api/workspace/firewall/*. Ce n’est pas une clé de relais sk-orca-… (celles-ci ne sont que pour les appels de modèle /v1/*) et pas une clé de passerelle firewall. Une clé de relais sur cette route est rejetée.
Chaque item nomme l’outil, le token redacté, combien d’appels se sont déclenchés, le z-score (signaux de volume/coût seulement), et un suggested_action (rate_limit, block_tool ou review). À partir d’ici, vous agissez : posez une règle deny sur l’outil, validez ses arguments, ou ouvrez le journal d’événements pour voir exactement ce que l’agent a fait.

​
4. Mettre le flux en sourdine

Un test de charge connu ou un backfill planifié allumera le flux. Plutôt que de courir après le bruit, mettez-le en sourdine — jusqu’à 7 jours : 
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/anomalies/snooze \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"until": 1749643200}'
Pendant qu’une mise en sourdine est active, le flux ne renvoie aucun item et rapporte snoozed_until ; il se vide de lui-même au moment où l’échéance passe. Le plafond est un plafond dur — un until mal saisi ou hostile plus loin est borné de sorte que la détection d’anomalies ne peut pas être réduite au silence indéfiniment. POSTer un until passé ou présent vide une mise en sourdine existante.
Lire le flux est une action Member ; le mettre en sourdine est Developer+ — couper un signal de sécurité à l’échelle de l’espace de travail est une écriture, pas une lecture.

​
5. RBAC en un coup d’œil

La surface analytics se sépare selon la ligne lecture/action habituelle :
ActionRôle
Lire le flux d’anomaliesMember
Lire les réglages, politiques, outils découvertsMember
Mettre le flux en sourdineDeveloper+
Events, runs, agrégation, traceDeveloper+
Rédiger une règle à partir d’une découverteDeveloper+
Les vues d’agrégation plus légères — réglages, politiques, et la carte de couverture des outils découverts — sont aussi des lectures Member ; le détail au niveau des lignes des événements et exécutions est Developer+, parce qu’il porte les données d’arguments par appel.

​
6. Du signal à la politique

Le flux est le début d’une boucle, pas la fin :
1

Repérer le pattern

Un novel_path ou un rate_spike montre une forme que vous n’attendiez pas. Lisez-le contre le journal d’événements pour confirmer qu’il est réel, pas un cas isolé.
2

Écrire la règle

Transformez la découverte en application — un block, une clause d’argument, une règle de séquence pour la chaîne, ou un plafond de coût pour la dépense.
3

La déployer en toute sécurité

Posez d’abord la règle sous le mode shadow pour mesurer son rayon d’impact avant qu’elle ne bloque un seul appel, puis appliquez.

​
Où aller ensuite

Vue d'ensemble du Firewall

La référence complète de la détection d’anomalies et le reste du plan de politique.

Journal d'événements

Plongez d’une anomalie aux appels exacts qui la sous-tendent.

Bloquer un outil

Transformer une découverte en une règle appliquante.

Modes d'application

Comment détection, audit, shadow et application s’imbriquent.
Pour les menaces que ces signaux exposent, voir exfiltration de données et agence excessive.