Maîtriser un agent autonome de longue durée

Un agent autonome de longue durée est la chose la plus difficile à sécuriser. Il boucle tout seul pendant des heures, choisit ses propres outils, récupère ses propres URL, et dépense votre argent tout du long. Les modes de défaillance ne sont pas un seul mauvais prompt — c’est une boucle de retry qui brûle 400 $ pendant la nuit, un appel d’outil que vous n’avez jamais revu, une clé que vous avez frappée pour une expérience d’une semaine et qui fonctionne encore six mois plus tard. Cette recette câble quatre contrôles autour exactement de cette forme d’agent. Vous les configurez tous dans la console (ou l’API REST) — l’agent continue d’appeler https://api.orcarouter.ai/v1/... exactement comme avant.

Nouveau ici ? Appliquez d’abord le référentiel balanced et observez ce que fait votre agent pendant une journée. Cette page est l’étape suivante : transformer l’observation en application pour un agent que vous ne pouvez pas surveiller en permanence.

1. La recette de l’agent autonome sécurisé

Un agent autonome sécurisé a besoin de quatre choses qu’un chatbot n’a pas :

Un plafond de coût strict

Une règle cap_cost refuse l’exécution une fois que sa dépense accumulée dépasse votre plafond — le disjoncteur pour une boucle qui ne s’arrête pas.

Détection de pics

La détection d’anomalies apprend la forme heure-de-la-semaine normale de l’agent et signale les pics de débit et de coût qui échappent aux règles statiques.

Approbation sur les appels dangereux

Un verdict pending_approval met en attente d’un humain les appels d’outils destructeurs ou irréversibles, au lieu de faire confiance à l’agent pour être prudent.

Une clé qui expire

Scopez la clé de l’agent à une expiration et un plafond de crédit afin qu’une expérience oubliée ne puisse pas tourner — ni dépenser — pour toujours.

Chacun correspond à un champ de politique Firewall ou de clé. Aucun ne touche le code de votre agent.

2. Plafonnez le coût de chaque exécution

La première chose qu’une boucle emballée fait sauter, c’est votre budget. Une règle cap_cost est un plafond de coût en pré-vérification stricte : quand elle correspond, la passerelle estime le coût de la requête et refuse avant le dispatch dès que la dépense accumulée de l’exécution dépasserait le plafond — de sorte qu’un appel hors budget n’atteigne jamais le fournisseur. Le plafond est scopé à l’exécution. La passerelle somme la dépense antérieure sur toute l’exécution de l’agent, de sorte qu’une longue exécution qui a déjà brûlé la majeure partie de son budget est refusée même quand le prochain appel individuel est bon marché. C’est ce qui en fait un disjoncteur plutôt qu’une limite par requête. Ajoutez une règle wildcard à votre politique firewall :

{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}

Cela plafonne l’exécution à 10 $ (cap_cost_cents est en centimes USD). Le verdict se résout en allow tant qu’on est sous le budget et en deny dès que l’estimation le franchirait. La plupart des templates de firewall intégrés (Coding, Support, RAG, Data, DevOps, Browser) livrent un plafond de coût par exécution exactement comme celui-ci — appliquez-en un et éditez le plafond.

L’accumulation scopée à l’exécution nécessite que la capture de journaux de requêtes soit activée pour l’espace de travail. Avec elle désactivée, le cumul de dépense antérieure lit zéro et le plafond se dégrade en par-requête uniquement — toujours sûr, mais il n’attrapera pas un goutte-à-goutte lent de 500 appels. Voir denial-of-wallet.

3. Détectez les pics contre une baseline apprise

Un plafond arrête la catastrophe ; la détection d’anomalies attrape l’étrange avant qu’il n’en devienne une. Le Firewall apprend la forme normale d’utilisation des outils de chaque espace de travail — une moyenne glissante sur 14 jours bucketée par heure-de-la-semaine, de sorte que le trafic du mardi-14:00 soit comparé à l’historique du mardi-14:00, pas à une moyenne quotidienne plate — et fait remonter les écarts sur un flux lisible par un viewer :

rate_spike — un outil se déclenchant bien au-dessus de sa norme

Le volume d’appels par outil scoré contre la baseline apprise. « 143 appels db.query en une heure contre une baseline de 8 » ressort même quand chaque appel individuel est autorisé.

burn_spike — coût grimpant au-delà de la dépense apprise

La même baseline, appliquée à la dépense au lieu du compte — une exécution qui brûle soudainement bien plus que cette heure ne le fait d’habitude.

retry_loop — un agent martelant un outil défaillant

La signature d’un agent autonome bloqué à réessayer le même appel cassé. Voir agence excessive.

novel_path — une transition d'outil jamais vue auparavant

Un saut d’outil à outil que cet espace de travail n’a jamais fait — la forme d’un agent allant quelque part de nouveau.

Le flux rapporte les noms d’outils, les ids de tokens redactés et les comptes — jamais les arguments bruts. Le lire est ouvert à tout Member ; un Developer+ peut mettre en sourdine le flux jusqu’à 7 jours pendant qu’il enquête. Associez le flux à une règle cap_cost afin qu’un pic qui est aussi hors budget soit arrêté, pas seulement remarqué.

4. Mettez les appels dangereux en attente d’un humain

Vous ne pouvez pas relire chaque appel qu’un agent autonome effectue — mais vous pouvez le faire s’arrêter et demander avant la poignée qui compte. Un verdict pending_approval met un appel d’outil en attente hors-bande :

L’agent émet, disons, un appel payments.transfer. La règle correspond et le moteur renvoie une HTTP 400 firewall_approval_pending avec un id d’approbation — l’appel n’atteint jamais l’outil.
Un relecteur le résout depuis la console (Developer+), ou votre propre système le résout via un callback webhook signé HMAC vers POST /api/v1/firewall/approvals/:id/callback.
L’agent interroge GET /api/v1/firewall/approvals/:id ; une fois approuvé, il re-soumet l’appel d’origine avec un en-tête X-OrcaRouter-Firewall-Approval à usage unique, et la passerelle le laisse passer cette unique fois.

Une règle qui met en attente les écritures sur une surface destructrice :

{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}

Déployez ceci en mode shadow d’abord — pending_approval se rétrograde en audit, donc vous voyez quels appels seraient mis en attente sans réellement bloquer votre agent. Désactivez le shadow quand le flux semble correct.

5. Donnez à l’agent une clé qui expire

Le contrôle qui survit à toute politique est la clé elle-même. Un agent autonome devrait recevoir une clé scopée, pas votre clé par défaut. Définissez ces champs quand vous la frappez (console → clés, ou l’API de token) :

Champ	Définissez-le sur	Pourquoi
`expired_time`	un timestamp Unix	L’expérience se termine ; la clé meurt avec elle. `-1` signifie jamais — ne l’utilisez pas ici.
`credit_limit_usd`	un plafond en dollars	Un plafond de dépense sur la clé indépendant du plafond d’exécution. `0` signifie illimité.
`firewall_policy_id`	votre politique ci-dessus	Lie les règles cap_cost + approbation à cette clé.
`allow_ips`	les IPs d’egress de l’agent	Une clé fuitée est inutile depuis n’importe où ailleurs.

Définissez aussi une étiquette environment, afin que la clé — et tout ce qu’elle fait dans Events et Matches — soit attribuable à cet agent. Une clé qui expire, plafonnée en crédit, épinglée par IP est la dernière ligne : même si chaque politique était d’une manière ou d’une autre contournée, le rayon d’explosion est borné par le temps et les dollars.

La configuration de clé est une action console / API de token et est soumise à un rôle. Lire le texte en clair d’une clé de passerelle firewall nécessite Admin+.

6. Mettez le tout ensemble

Un agent autonome durci finit avec une politique firewall et une clé scopée :

Couche	Contrôle	Attrape
Budget	Règle `cap_cost`, scopée à l’exécution	Boucles emballées, denial-of-wallet
Comportement	Flux d’anomalies (rate / burn / retry / novel)	L’étrange-mais-autorisé
Confiance	`pending_approval` sur les outils destructeurs	Actions irréversibles
Portée	Clé qui expire, plafonnée en crédit, épinglée par IP	Clés oubliées ou fuitées

Rédigez ensemble les règles de budget et d’approbation, définissez un plafond par exécution avec les règles du firewall, et lisez le reste de la référence Firewall pour les surfaces, verdicts et l’observabilité. Pour les menaces connexes contre lesquelles cette recette se défend, voir agence excessive, appels d’outils dangereux, et denial-of-wallet.

7. Étapes suivantes

Durcir un agent MCP

Gouvernez un agent qui atteint des outils à travers des serveurs MCP.

Arrêter l'exfiltration

Des règles d’egress pour un agent qui récupère ses propres URL.

Modes d'application

Observe → shadow → enforce, le déploiement sûr.

Règles du firewall

Le langage de correspondance derrière chaque règle ci-dessus.

​1. La recette de l’agent autonome sécurisé

Un plafond de coût strict

Détection de pics

Approbation sur les appels dangereux

Une clé qui expire

​2. Plafonnez le coût de chaque exécution

​3. Détectez les pics contre une baseline apprise

​4. Mettez les appels dangereux en attente d’un humain

​5. Donnez à l’agent une clé qui expire

​6. Mettez le tout ensemble

​7. Étapes suivantes

Durcir un agent MCP

Arrêter l'exfiltration

Modes d'application

Règles du firewall

1. La recette de l’agent autonome sécurisé

2. Plafonnez le coût de chaque exécution

3. Détectez les pics contre une baseline apprise

4. Mettez les appels dangereux en attente d’un humain

5. Donnez à l’agent une clé qui expire

6. Mettez le tout ensemble

7. Étapes suivantes