Passer au contenu principal
Un seul appel d’outil peut paraître parfaitement innocent. Lire un enregistrement CRM : autorisé. Appeler un outil d’export : autorisé. Atteindre un hôte externe : autorisé. La forme de l’exécution — cinquante lectures, puis un export, puis un egress vers un hôte que vous n’avez jamais vu à 3h du matin un dimanche — est l’attaque. Les verdicts par appel jugent chaque appel isolément et ne la voient jamais. Cette page couvre les deux mécanismes du firewall qui surveillent une exécution dans le temps au lieu d’un appel à la fois : les règles de séquence (une chaîne ordonnée que vous rédigez) et la détection comportementale d’anomalies (déviation par rapport à la normale apprise de votre espace de travail). Ensemble, ils sont votre moyen de détecter le comportement de chaîne d’attaque d’agent qu’aucune règle allow/deny seule ne peut attraper.
Tout ici est configuré dans la console (Security → Firewall), dont les routes de gestion utilisent votre session / token d’accès — pas une clé de relais sk-orca-…. Les appels /v1/* de votre agent ne changent pas.

​
1. Pourquoi les règles par appel manquent la chaîne

Les globs d’outils et les clauses d’arguments du firewall sont sans état et déterministes par conception — ils décident un appel, vite, sur le chemin critique. C’est exactement ce que vous voulez pour « bloquer shell.exec rm -rf ». C’est exactement faux pour une exfiltration à feu lent où chaque appel individuel est légal. Deux outils complémentaires comblent la lacune :

Règles de séquence

Une règle que vous rédigez et qui correspond à une chaîne ordonnée d’appels dans une fenêtre temporelle — « lecture de masse → export → egress ». Vous nommez le pattern.

Détection d'anomalies

Le firewall apprend la forme normale d’usage des outils de chaque espace de travail et signale les déviations — boucles de retry, chemins d’outils jamais vus auparavant, et pics de volume/coût. Aucune règle à rédiger.

​
2. Règles de séquence : nommer la chaîne d’attaque

Une règle sequence vit à l’intérieur d’une politique firewall comme n’importe quelle autre règle, mais au lieu d’un seul tool_name_glob, elle porte une liste ordonnée d’étapes. Chaque étape est un glob d’outil avec un min_count optionnel et un egress: true optionnel ; les étapes doivent se produire dans l’ordre (l’entrelacement avec des appels non liés est acceptable) et toute la chaîne doit se compléter dans window_seconds. 
{
  "label": "bulk-read-then-exfil",
  "verdict": "audit",
  "sequence": {
    "window_seconds": 600,
    "steps": [
      { "match": "crm.*",   "min_count": 50 },
      { "match": "*.export" },
      { "match": "*", "egress": true }
    ]
  }
}
Ceci se déclenche quand un agent lit 50+ enregistrements crm.*, puis appelle n’importe quel outil *.export, puis fait n’importe quel appel d’egress — tout cela en dix minutes. Chaque appel à lui seul passerait ; le pattern est le signal.
Une séquence est évaluée sur l’appel qui la complète. La boucle de règles inline saute les règles de chaîne (un appel ne peut pas satisfaire une chaîne multi-étapes) ; la correspondance s’exécute quand un appel pourrait être l’étape finale d’une chaîne, moment auquel le firewall tire les événements récents de ce principal et teste la chaîne. Le verdict que vous définissez sur la règle est ce qui arrive alors à l’appel qui complète : audit l’enregistre et le laisse passer, pending_approval le met en attente de revue humaine, et deny le bloque. Donc une chaîne peut arrêter son appel final en temps réel — choisissez le verdict en conséquence. Utilisez audit quand vous voulez seulement détecter et alerter ; utilisez pending_approval ou deny (ou associez à un deny / règle d’egress par appel) quand vous avez besoin d’un arrêt dur.
La syntaxe complète du champ sequence — window_seconds: 0 pour aucune borne temporelle, les défauts de min_count, la sémantique d’ordonnancement des étapes — est dans le schéma de règle. Rédigez les règles de séquence dans l’éditeur de règles de la console ; enregistrer est une action Developer+.

​
3. Détection d’anomalies : déviation par rapport à la normale apprise

Là où les règles de séquence demandent « est-ce que ce pattern spécifique s’est produit », la détection d’anomalies demande « est-ce que quoi que ce soit de cette exécution est anormal pour cet espace de travail ». Elle n’a besoin d’aucune règle — le firewall construit une baseline à partir de votre propre trafic et score l’activité en live contre elle. Quatre sortes apparaissent :
Le volume d’appels par (outil, clé) scoré contre la baseline apprise pour cette heure-de-la-semaine. Une ligne apparaît quand le compte dépasse un plancher absolu et tourne haut par rapport à la baseline, ou quand son z-score franchit le seuil statistique. Ainsi « 100 appels db.query à 3h du matin dimanche » ressort même si un pic de même taille un mardi à 14h ne le ferait pas.
La même idée appliquée à la dépense : un outil brûlant des multiples de son coût de baseline appris pour cette heure-de-la-semaine. L’avertissement précoce de déni-de-portefeuille — associez-le à une règle cap_cost pour appliquer un plafond dur.
Un groupe (conversation, tool, arguments) qui se répète de nombreuses fois dans une fenêtre serrée — un agent coincé à appeler le même outil défaillant avec les mêmes arguments encore et encore, plutôt qu’un polling légitime lent.
Une transition tool_a → tool_b que cet espace de travail n’a jamais faite auparavant. La première fois qu’un agent passe de read_file directement à http_fetch, cette arête s’allume même si les deux outils sont individuellement autorisés.

​
La baseline heure-de-la-semaine

La baseline est une moyenne glissante sur 14 jours bucketisée par heure de la semaine (weekday × 24 + hour), de sorte que mardi-14:00 est comparé spécifiquement à l’historique des mardi-14:00 passés — pas à une moyenne plate de tous les temps qui laverait votre vrai rythme quotidien et hebdomadaire. Un espace de travail tout neuf sans norme apprise encore attrape quand même un déluge évident via un plancher absolu, donc vous êtes protégé dès le premier jour.
Le flux rapporte des noms d’outils, des ids de clés redactés, des comptes et un z-score — jamais de matériel de clé brut. Chaque anomalie porte une remédiation suggérée (rate_limit, review ou block_tool) de sorte que la prochaine étape est en un clic, pas une devinette.

​
4. Un parcours concret

Supposons qu’un prompt compromis pousse l’un de vos agents dans une boucle de défaillance serrée, puis sonde un chemin d’export qu’il n’a jamais touché. Voici ce que vous voyez — aucune règle rédigée à l’avance :
1

L'agent se comporte mal

Des instructions injectées poussent l’agent à réessayer un db.query défaillant avec des arguments identiques, puis à appeler report.export suivi d’un fetch sortant — un chemin que cet espace de travail n’a jamais exécuté.
2

Ouvrir le flux d'anomalies

Dans Security → Firewall → Anomalies, l’exécution fait apparaître un retry_loop sur db.query et un novel_path sur l’arête report.export → http_fetch. Lire le flux est une action Member — quiconque dans l’équipe peut trier.
3

Confirmer dans la trace d'événements

Cliquez jusqu’au journal d’événements et aux analytics d’exécution pour voir la séquence d’appels exacte, corrélée à l’exécution et à la conversation de l’agent. Le flux d’anomalies est lisible par un Member, mais le journal d’événements et la trace d’exécution portent la provenance des appels d’outils et sont Developer+.
4

Convertir la découverte en règle

Maintenant que vous avez vu la chaîne, encodez-la : un deny sur l’export dangereux, une liste blanche d’egress sur le fetch, ou une règle de séquence qui audite tout le pattern la prochaine fois. La détection d’anomalies trouve l’inconnu ; une règle épingle le connu.
Si le flux est bruyant pendant que vous affinez — un job batch légitime qui pique vraiment chaque dimanche, par exemple — mettez en sourdine le flux d’anomalies jusqu’à 7 jours pendant que vous enquêtez. Mettre en sourdine est une action Developer+ ; la fenêtre est bornée côté serveur de sorte que la détection revient toujours d’elle-même.

​
5. Règles de séquence vs. détection d’anomalies

Elles résolvent des problèmes adjacents — choisissez celle qui correspond à ce que vous savez :
Règle de séquenceDétection d’anomalies
Vous rédigezLa chaîne exacteRien — elle apprend
AttrapeUn pattern multi-étapes connuL’inconnu / l’anormal
AgitApplique le verdict de la règle à l’appel qui complète (audit / pending_approval / deny)Apparaît sur le flux
Un espace de travail mature exécute les deux : la détection d’anomalies est le radar qui fait remonter les chaînes que vous n’avez pas anticipées — remontée seulement, jamais de blocage ; les règles de séquence sont votre moyen de codifier celles que vous avez, de sorte qu’elles sont labellisées, tracées, et (avec un verdict pending_approval ou deny) capables de filtrer l’appel qui complète. Pour un arrêt dur sur un seul appel peu importe la chaîne, recourez à un verdict par appel.

​
6. RBAC et les routes derrière le flux

Le flux d’anomalies et les règles de séquence se situent sous les routes de gestion du firewall d’espace de travail — votre session / token d’accès, jamais une clé de relais :
Méthode & cheminRôleObjectif
GET /api/workspace/firewall/anomaliesMemberLire le flux d’anomalies (?window=).
POST /api/workspace/firewall/anomalies/snoozeDeveloper+Mettre en sourdine le flux ({until}, borné à 7 jours).
POST /api/workspace/firewall/rulesDeveloper+Créer une règle de séquence (ou toute règle) sous une politique.
POST /api/workspace/firewall/testDeveloper+Dry-run d’une politique contre un appel d’échantillon avant de vous y fier.
Les lectures du flux sont ouvertes à chaque Member pour que toute l’équipe puisse trier ; rédiger des règles et mettre le flux en sourdine sont des écritures Developer+, cohérentes avec le reste du modèle RBAC du firewall.

​
Où aller ensuite

Schéma de règle

Le champ sequence complet — étapes, min_count, window_seconds, et chaque autre champ de règle.

Journal d'événements

Où les séquences correspondantes et les anomalies atterrissent — filtrez par exécution, surface et verdict.

Plafonner le coût

Transformer un signal burn_spike en un plafond de dépense dur par exécution.

Contrôle d'egress

Arrêter l’étape finale d’exfiltration d’une chaîne à la frontière réseau.
Pour les playbooks d’attaquants que ces mécanismes contrent, voir attaques chaînées, exfiltration de données, et agence excessive. Pour la référence approfondie du firewall, voir Règles du Firewall.