Passer au contenu principal
La plupart des équipes recourent à la sécurité des agents trop tard et un plan à la fois — une regex sur les prompts ici, une deny-list d’outils là. Le résultat est une posture avec des trous : un filtrage de texte qui ne voit jamais un shell.exec, ou un firewall d’outils qui ne remarque jamais un numéro de carte de crédit qui s’en va dans un prompt. La façon la plus rapide d’arriver à un référentiel de sécurité d’agent complet est de définir les deux plans à la fois. Le contrôle d’autonomie d’OrcaRouter — le référentiel Secure Agents — fait exactement cela : un seul interrupteur au niveau de l’espace de travail qui écrit une politique firewall et un guardrail ensemble, en une seule transaction, avec annulation en un clic. Vous ne rédigez pas de règle pour être protégé ; vous choisissez un niveau et affinez plus tard.
Les deux plans sont complémentaires, pas redondants. Les Guardrails filtrent le texte des prompts/réponses (PII, secrets, intention de jailbreak et d’injection) ; le firewall gouverne les actions qu’un agent entreprend (quels outils, appels MCP et hôtes). L’un seul laisse une lacune que l’autre comble — voir Guardrails vs. Firewall.

​
1. Pourquoi un référentiel bat deux demi-mesures

Une vraie exécution d’agent traverse les deux plans dans une seule requête. Le modèle lit un prompt (texte), décide d’appeler db.query (action), et le résultat de l’outil revient dans le tour suivant (texte à nouveau). Sécuriser un seul plan laisse l’autre sans garde :

Firewall seul

Vous refusez le shell destructeur, mais un prompt porte quand même le SSN d’un client directement au modèle — et un argument d’outil fuite quand même une clé API.

Guardrails seuls

Vous masquez la PII dans les prompts, mais l’agent appelle quand même rm -rf, atteint un endpoint cloud-metadata, ou boucle sur un outil emballé.
Le contrôle d’autonomie supprime le choix. Un seul niveau définit une posture cohérente à travers les deux plans, de sorte qu’il n’y a pas de fenêtre où l’un est configuré et l’autre non.

​
2. Le référentiel de sécurité d’agent : trois niveaux

Chaque niveau couvre les deux mêmes plans. Choisissez-en un ; c’est votre plancher, et vous ajoutez de la précision avec des règles plus tard.
NiveauFirewallGuardrailsMode observe
tightDefault-deny ; shell destructeur + outils de forme fetch refusésPII Shield + Secrets Blocker appliquésDésactivé
balancedDefault-audit ; shell destructeur refuséPII Shield en audit seulement (signale la PII)Désactivé
permissiveAucune politique appliquanteAucunActivé — journalise chaque appel comme une lacune
Quelques spécificités à fixer, puisqu’elles façonnent ce que chaque niveau attrape réellement :
tight estampille le verdict par défaut de la politique firewall à deny, puis superpose des règles deny pour les noms d’outils shell/exec qui portent des commandes destructrices — shell.*, bash, cmd, powershell, exec — et pour les noms d’outils de forme fetch qui portent du SSRF — http_fetch, web_search, fetch_url, request (et leurs variantes MCP-namespacées <server>.*). Il refuse ces noms d’outils ; il n’embarque pas de règle d’egress CIDR ou cloud-metadata. Si vous voulez refuser 169.254.169.254 ou les plages RFC-1918 par destination, rédigez votre propre règle d’egress — voir Contrôle d’egress.
Les guardrails PII Shield et Secrets Blocker sont tous deux actifs et appliquants. PII Shield masque la PII sur la requête avant qu’elle n’atteigne le modèle ; Secrets Blocker attrape les identifiants dans la requête. Les secrets dans les arguments d’outils sont attrapés par ce guardrail sur la requête — le firewall ne les retire pas par défaut.
balanced audite tout (verdict par défaut audit) de sorte que vous voyez le comportement réel de votre agent, tout en refusant quand même la seule classe la plus destructrice — le shell destructeur. PII Shield s’exécute en mode audit seulement (signale la PII, ne bloque pas). Vous obtenez une trace complète avec presque aucun risque de block inattendu, puis vous resserrez depuis la visibilité plutôt que les conjectures.
permissive n’applique rien — il existe pour observer un agent tout neuf avec un risque nul de blocks accidentels. Le mode observe reste activé, de sorte que chaque appel d’outil est quand même journalisé comme une lacune de couverture (visible dans Discovered Tools). Utilisez-le pour apprendre la forme d’un agent, puis passez à balanced ou tight.

​
3. Un exemple concret : appliquer balanced, surveiller les deux flux

Appliquer un niveau est une seule action de console (Firewall → Posture) ou un seul appel API. La route s’exécute sous votre session et requiert Developer+. 
# Configure in the console, or POST under your session token (Developer+):
POST /api/workspace/firewall/autonomy
Content-Type: application/json

{ "level": "balanced" }
La réponse porte un audit_id — gardez-le ; c’est ce que vous passez pour annuler. Une fois appliqué, le référentiel est en live dès le prochain appel d’outil. Aucun redéploiement, aucun changement de code d’agent. Maintenant, vous surveillez les deux plans à la fois :
  • Firewall → Events — chaque verdict d’appel d’outil (audit, les appels de shell destructeur refusés). Voir Journal d’événements.
  • Guardrails → Matches — chaque occurrence de politique de contenu (signalements de PII Shield).
Parce que balanced écrit une politique firewall réelle et éditable et un guardrail réel (chacun nommé d’après le niveau), vous pouvez ouvrir l’un ou l’autre ensuite et l’affiner — le référentiel est un point de départ, pas un preset verrouillé.
Prévisualisez avant de vous engager. GET /api/workspace/firewall/simulate?level=tight (Member, lecture seule) montre exactement ce que tight changerait contre votre état actuel — rien n’est appliqué. Exécutez-le après un jour ou deux sur balanced pour confirmer que tight ne refusera pas des appels qui font partie de votre trafic normal.

​
4. L’annulation est un seul appel

Chaque changement d’autonomie est réversible à partir de son snapshot d’audit, restaurant l’état antérieur exact — politiques, règles, guardrails et réglages — pas une réinitialisation générique. 
# Developer+; :audit_id is the value returned when you applied the level.
POST /api/workspace/firewall/autonomy/undo/:audit_id
Pour un très grand espace de travail dont le snapshot dépasse la limite de taille du journal d’audit, l’application réussit quand même mais l’annulation en un clic est indisponible pour ce changement — vous ré-appliquez le niveau que vous voulez à la place. C’est rare, mais bon à savoir avant de resserrer un espace de travail de production occupé.

​
5. Le chemin recommandé

Commencez large, observez, puis resserrez depuis une position de visibilité :
1

Appliquer balanced

Trace d’audit complète ; seul le shell destructeur est refusé ; la PII est signalée. Exécutez vos agents normalement pendant un jour ou deux.
2

Simuler tight

GET /api/workspace/firewall/simulate?level=tight et comparez ses refus à ce que le flux Events a réellement montré. Si des appels de forme fetch ou de shell destructeur font partie de votre flux normal, corrigez d’abord l’agent.
3

Appliquer tight

Une fois que simulate ne réserve aucune surprise, passez à tight. L’annulation est à un appel près si la production casse.
4

Affiner avec des règles

Le référentiel est votre plancher. Taillez des exceptions ou ajoutez des contrôles qu’il ne couvre pas avec des règles firewall et des guardrails nommés. Attachez une politique ou un guardrail spécifique à une clé individuelle pour une portée plus fine.

​
6. Rôles pour le référentiel combiné

Le contrôle d’autonomie couvre les deux plans, mais chaque action est filtrée par rôle.
ActionRôle minimum
Simuler un niveau / voir les Matches de guardrail / voir Discovered ToolsMember
Voir Events & Runs du firewallDeveloper+
Appliquer un niveau d’autonomieDeveloper+
Annuler un changement d’autonomieDeveloper+
Toute la configuration s’exécute dans la console sous votre session (/api/workspace/firewall/* et /api/guardrail/*). Seuls les appels de relais /v1/* utilisent une clé sk-orca-… ; les routes de clé de passerelle sont une portée séparée. Voir Portée : clés, politiques, espaces de travail.

​
7. Après le référentiel : où affiner chaque plan

Le référentiel vous protège dans les 30 premières minutes. À partir de là, chaque plan a sa propre référence pour le travail de précision :

Vue d'ensemble du Firewall

Verdicts, surfaces, prédicats d’arguments, approbations — le plan action.

Guardrails

Règles keyword, regex, PII, llm_judge et grounding — le plan contenu.

Mode shadow

Déployer une politique firewall resserrée en audit seulement avant d’appliquer.

Référentiel Secure Agents

La page conceptuelle du contrôle d’autonomie et sa sémantique d’annulation.
Le référentiel est le plancher qui ferme les deux plans à la fois ; les règles sont votre moyen de relever le plafond. Voir Sécuriser les agents IA et la pile de contrôle pour la façon dont les couches se composent, et Agence excessive pour la menace à laquelle ce référentiel répond le plus directement.