Passer au contenu principal
La réponse courte : les Guardrails gouvernent le texte ; le Firewall gouverne les actions. Ils sont complémentaires — une seule requête passe par les deux — et la façon la plus rapide de les configurer ensemble est un niveau d’autonomie. Le reste de cette page est pour les cas où vous devez savoir quelle couche possède une menace spécifique.
Rôle requis. Tout membre de l’espace de travail peut lire les politiques et le flux Matches des guardrails ; le flux Events du firewall nécessite le rôle Developer. La création ou la modification de guardrails ou de politiques firewall nécessite également Developer ou supérieur.

​
1. La distinction en une ligne

CoucheGouverneVoit
GuardrailsTexte — ce que le modèle lit et écritContenu du prompt, contenu de la réponse
Agent FirewallActions — ce que l’agent faitAppels d’outils, dispatches MCP, destinations réseau sortantes
Les Guardrails se déclenchent avant l’appel en amont (sur le prompt) et après (sur la réponse). Le Firewall se déclenche sur chaque appel d’outil que le modèle émet ou que l’agent émet — peu importe le modèle ou le fournisseur qui a servi le tour.

​
2. Comparaison côte à côte

DimensionGuardrailsAgent Firewall
GouverneTexte du prompt et texte de la réponse du modèleAppels d’outils, dispatches MCP, destinations d’egress, coût de l’agent
VoitLe message utilisateur, le prompt système, et la réponse du modèleNom de l’outil, arguments de l’appel, les appels d’outils que le modèle émet, host/IP sortant
S’attache viaguardrail_id sur la clé APIfirewall_policy_id sur la clé API
Types de règleskeyword, regex, pii, max_chars, external, llm_judge, groundingGlob de nom d’outil + clauses d’arguments + portée d’egress + propriété de skill
Exemples de menacesPII dans les prompts, secrets API dans les réponses, jailbreaks, sortie hors-sujet, contexte surdimensionnéAppel d’outil dangereux, SSRF, exfiltration de données, boucle de coût d’agent incontrôlée, serveur MCP non approuvé
Verdicts / actionsblock (HTTP 400 guardrail_blocked), mask, flagallow, audit, deny (HTTP 400 firewall_blocked), sanitize, pending_approval, cap_cost
Quand il se déclencheÉtape input : avant l’appel modèle ; étape output : après que le modèle répondSur chaque appel d’outil que le modèle émet ou que l’agent émet
Mode shadow / observeNon — les guardrails se déclenchent ou ne se déclenchent pasOui — le mode shadow rétrograde les verdicts appliquants en audit pour un déploiement sûr

​
3. Menace → quelle couche

Utilisez ce tableau pour orienter une nouvelle exigence de sécurité vers le bon contrôle :
MenaceUtilisez
PII dans un message utilisateurGuardrails — règle pii en entrée (mask / block)
Secret dans la réponse du modèleGuardrails — règle de secrets en sortie
Appel d’outil dangereux (shell.exec rm -rf /)Firewall — deny sur glob d’outil + clause d’argument
SSRF / exfiltration de données via URL sortanteFirewall — liste allow/deny d’egress
Injection de prompt depuis du contenu non fiableLes deux — guardrail d’entrée + liste blanche firewall
Secret dans un argument d’outilFirewall sanitize + règle de secrets Guardrails
Jailbreak / contournement de politiqueGuardrails — llm_judge / keyword / regex
Prompt surdimensionné ou coût en tokensGuardrails — règle max_chars
Dépenses d’agent incontrôlées (boucle de coût)Firewall — verdict cap_cost
Serveur MCP non approuvéFirewall — deny surface MCP / pending_approval
Données sensibles d’un résultat d’outilGuardrails — règle de sortie sur la réponse
Le « pourquoi » en profondeur pour chaque association se trouve sur les pages d’approfondissement des Menaces.

​
4. Utilisez les deux — les niveaux d’autonomie les configurent ensemble

Les Guardrails et le Firewall sont conçus pour se composer, pas pour se concurrencer. Une seule requête passe par les deux plans :
  1. Le guardrail d’entrée s’exécute — le texte du prompt est filtré et optionnellement masqué.
  2. L’appel modèle — le prompt (éventuellement assaini) atteint le modèle en amont.
  3. Le Firewall — chaque appel d’outil que le modèle émet est évalué.
  4. Le guardrail de sortie s’exécute — le texte de la réponse du modèle est filtré.
La façon la plus rapide de configurer les deux à la fois est un niveau d’autonomie — un réglage unique qui écrit atomiquement une politique Firewall et une politique Guardrails pour tout l’espace de travail, avec annulation en un clic :
Niveau d’autonomiePosture FirewallPosture Guardrails
tightRefus par défaut ; bloque shell destructeur + egress SSRFPII Shield + Secrets Blocker activés
balancedAudit par défaut ; refuse shell destructeurPII Shield en audit uniquement (signale la PII)
permissivePas de règles appliquantes ; mode observe activéAucune application
Appliquez un niveau d’autonomie depuis la console Firewall (POST /api/workspace/firewall/autonomy, Developer+), puis ajustez chaque plan indépendamment à partir de là.

​
5. Résumé

Les Guardrails possèdent le texte ; le Firewall possède les actions — exécutez les deux, laissez le niveau d’autonomie les connecter, et resserrez chaque plan indépendamment une fois que vous pouvez voir le trafic réel de vos agents.

Guardrails

Types de règles, détection de PII, juge LLM, harnais d’évaluation et référence API.

Agent Firewall

Verdicts, surfaces, niveaux d’autonomie, approbation HITL et référence API.