Passer au contenu principal
Vous n’avez pas besoin de rédiger une seule règle firewall pour être protégé. Le contrôle d’autonomie — aussi appelé référentiel Secure Agents — applique une posture zero trust complète à votre espace de travail en une transaction : Firewall et Guardrails, ensemble, avec annulation en un clic. C’est le chemin le plus rapide vers une posture de sécurité significative. Rédigez des règles plus tard pour affiner ; commencez ici.
Le référentiel Secure Agents est le contrôle d’autonomie — il n’y a pas d’objet « référentiel » séparé. Appliquer un niveau d’autonomie écrit atomiquement une politique firewall et un guardrail (nommés d’après le niveau) et en fait la posture active de votre espace de travail, en une transaction. Vous pouvez les ouvrir et les modifier après. L’annulation en un clic restaure l’état précédent depuis un snapshot d’audit.

​
1. Ce que fait le contrôle d’autonomie

Trois niveaux, chacun couvrant les deux mêmes couches :
NiveauPosture FirewallGuardrailsMode observe
tightRefus par défaut ; shell destructeur et egress SSRF refusésPII Shield + Secrets Blocker appliquésDésactivé
balancedAudit par défaut ; shell destructeur refuséPII Shield en mode audit uniquement (signale la PII)Désactivé
permissiveAucune politique appliquanteAucun guardrailActivé — chaque appel d’outil est journalisé comme un écart de couverture
balanced est la posture de départ recommandée. Il audite tout ce que vos agents font et signale la PII, tout en refusant quand même les actions les plus destructrices (shell destructeur) — afin que vous voyiez le comportement réel de vos agents avant de décider quoi restreindre d’autre. Pour un passage qui ne bloque rien, commencez à permissive. tight est la bonne cible une fois que vous comprenez le comportement normal de votre agent. Il applique une posture de refus par défaut : shell destructeur refusé, egress SSRF refusé, et les guardrails PII Shield et Secrets Blocker actifs (filtrant vos requêtes pour la PII et les secrets). permissive désactive toute application mais laisse le mode observe activé, afin que chaque appel d’outil soit quand même journalisé. Utilisez-le pour auditer un nouvel agent sans risque de blocks accidentels — puis passez à balanced ou tight une fois que vous savez ce qu’il fait.

​
2. Comment appliquer un niveau

1

Prévisualiser le changement (optionnel mais recommandé)

Simulez le niveau avant de l’appliquer. La vue Simulate de la console (sous Firewall → Posture) ou l’API montre exactement quelles règles et guardrails seraient actifs — rien ne change.
# Simuler tight — retourne le diff complet de la politique, rien n'est appliqué
GET /api/workspace/firewall/simulate?level=tight
Rôle : Member (lecture seule, aucun changement).
2

Choisir un niveau dans la console

Allez sur Firewall → Posture dans la console. Sélectionnez balanced, tight ou permissive dans le contrôle de niveau d’autonomie et confirmez. Le changement prend effet sur le prochain appel d’outil — aucun redéploiement.Rôle : Developer+ requis pour appliquer.
3

Ou appliquer via l'API

POST /api/workspace/firewall/autonomy
Content-Type: application/json

{ "level": "balanced" }
La réponse inclut un audit_id — conservez-le. Vous en avez besoin pour l’annulation.Rôle : Developer+.
4

Observer les événements et les correspondances

Après l’application, allez sur Firewall → Events / Runs pour voir les verdicts des appels d’outils et Guardrails → Matches pour voir les hits de politique de contenu. Les deux flux se mettent à jour en temps réel. Si quelque chose se déclenche que vous n’attendiez pas, examinez-le avant de resserrer davantage.
5

Annuler si nécessaire

Tout changement d’autonomie peut être annulé avec un seul appel. L’annulation restaure l’état précédent exact — politiques, règles, guardrails, réglages — depuis le snapshot d’audit, pas une réinitialisation générique.
POST /api/workspace/firewall/autonomy/undo/:audit_id
Rôle : Developer+.Le audit_id est retourné quand vous appliquez le niveau (Étape 3) et est également visible dans Firewall → Audit.

​
3. Le chemin recommandé

Commencez balanced → simulez tight → regardez → resserrez.
  1. Appliquez balanced — vous obtenez une piste d’audit complète ; seul le shell destructeur est refusé, tout le reste est audité. Exécutez vos agents normalement pendant un jour ou deux.
  2. Simulez tight — exécutez GET /api/workspace/firewall/simulate?level=tight et comparez ce qui serait refusé par rapport à ce que vous avez vu dans le flux Events. Si des appels de shell destructeur ou des requêtes sortantes de type SSRF font partie de votre trafic normal, corrigez-les d’abord dans l’agent.
  3. Observez Events et Matches — Firewall → Events montre chaque verdict d’appel d’outil ; Guardrails → Matches montre les hits de politique de contenu. Les deux sont filtrables par verdict, outil, exécution et session.
  4. Appliquez tight — une fois que la sortie de simulation ne contient pas de surprises, appliquez tight. L’annulation est à un appel si quelque chose se casse en production.
  5. Affinez avec des règles — utilisez les règles Firewall pour créer des exceptions ou ajouter des contrôles que les niveaux de preset ne couvrent pas. Le niveau d’autonomie est votre plancher ; les règles personnalisées ajoutent de la précision.

​
4. Exigences de rôle

ActionRôle minimum
Simuler un niveau (GET .../simulate)Member
Lire la piste d’auditMember
Voir les Matches guardrailMember
Voir les Events & Runs firewallDeveloper+
Appliquer un niveau d’autonomieDeveloper+
Annuler un changement d’autonomieDeveloper+

​
5. Ce que ce n’est pas

  • Pas une boîte noire. Appliquer un niveau d’autonomie écrit une vraie politique firewall et un guardrail (nommés d’après le niveau) et en fait la posture active de votre espace de travail. Vous pouvez les ouvrir, les inspecter et les modifier après — c’est un point de départ rapide, pas un preset verrouillé.
  • Réversible, dans les limites. L’annulation en un clic restaure l’état précédent Firewall et Guardrails depuis un snapshot d’audit. 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 n’est pas disponible pour ce changement — vous ré-appliquez le niveau désiré à la place. Rare, mais cela vaut la peine de le savoir.
  • Pas un substitut aux clés à portée limitée. Le contrôle d’autonomie définit la posture par défaut de l’espace de travail. Les clés API individuelles peuvent quand même être attachées à des politiques spécifiques pour un contrôle plus fin. Voir Guardrails vs. Firewall pour savoir comment les couches se composent.
Le contrôle d’autonomie est conçu pour les 30 premières minutes — protégez-vous rapidement, comprenez le comportement réel de vos agents, puis resserrez depuis une position de visibilité plutôt que de devinette.

Démarrage rapide

Configuration zero trust complète en 5 minutes, y compris les clés à portée limitée et les guardrails.

Firewall

Détails au niveau des règles — verdicts, surfaces, prédicats d’arguments et flux d’approbation HITL.