Passer au contenu principal
La passerelle se trouve entre votre agent et chaque modèle qu’il appelle. Cela en fait le point unique qui voit chaque appel quel que soit le fournisseur — chaque prompt, chaque réponse, chaque appel d’outil, et chaque requête sortante que votre agent route à travers elle — peu importe quel SDK a émis l’appel. C’est à ce point d’étranglement qu’appartiennent l’inspection et l’application. (Ce qu’elle ne peut pas voir — un outil qui s’exécute entièrement à l’intérieur de votre processus et ne traverse jamais la passerelle — est couvert dans §4.) Cette page explique exactement ce que la passerelle peut et ne peut pas voir, comment la détection fonctionne, et comment combler les lacunes.

​
1. Pourquoi la passerelle est le bon point d’inspection

La plupart des contrôles de sécurité vivent dans l’application : wrappers de bibliothèque, hooks de frameworks d’agents, SDKs par fournisseur. Ces contrôles ont un défaut structurel fatal — ils se brisent dès que vous ajoutez un second fournisseur, changez de framework, ou laissez un agent auto-installer un nouveau skill. La passerelle n’a aucune de ces coutures. Chaque appel que votre agent émet, quel que soit le modèle, le fournisseur, ou comment la capacité d’outil est arrivée, transite par un seul point avant que quoi que ce soit n’atteigne l’amont. C’est la seule couche où vous pouvez faire une garantie : si cela s’est produit, la passerelle l’a vu. OrcaRouter utilise cette position pour deux passes d’application distinctes :
  • Les Guardrails filtrent le texte — le prompt que votre agent envoie et la réponse que le modèle renvoie. Un block guardrail retourne HTTP 400 guardrail_blocked et ne coûte aucun quota.
  • Le Firewall juge les actions — les outils qu’un agent appelle, les serveurs MCP qu’il atteint, et les destinations réseau qu’il rapporte. Un refus firewall retourne HTTP 400 firewall_blocked sur la surface inbound, ou une erreur d’outil sur la surface MCP, afin que le modèle voie le rejet et puisse raisonner dessus.
Les deux couches sont configurées une fois dans votre espace de travail et s’attachent à une clé API. Aucun redéploiement. Aucun changement de SDK. Votre agent continue d’appeler https://api.orcarouter.ai/v1 exactement comme avant.

​
2. Les quatre surfaces d’application

Le Firewall évalue chaque appel d’outil contre exactement une surface — le point dans le cycle de vie de l’appel où la passerelle le voit.
SurfaceCe que la passerelle voit
inboundLes outils que votre agent annonce au modèle sur la requête — les définitions d’outils. Bloquer ici empêche le modèle de choisir un outil dangereux.
responseLes tool_calls que le modèle émet dans sa réponse — les actions choisies par le modèle avant qu’elles ne soient dispatchées.
mcpUn tools/call dispatché via la passerelle MCP du Firewall ou évalué via le hook SDK — l’appel au moment du dispatch.
egressUne destination réseau sortante (host / IP / CIDR) rapportée par un outil — la surface SSRF et d’exfiltration de données.
Les Guardrails ajoutent deux étapes de texte supplémentaires qui se superposent aux surfaces ci-dessus : input (le prompt de requête et les messages) et output (le texte de réponse du modèle). Une seule requête peut passer par toutes.

​
3. Détection à la première utilisation

La détection se produit à la passerelle, à la première utilisation — pas au moment de l’installation. Un outil, un serveur MCP ou un skill qu’un agent auto-installe est intercepté la première fois que son appel traverse la passerelle. C’est délibéré : la passerelle est le seul point d’étranglement qui voit chaque fournisseur, chaque agent, et chaque appel peu importe comment la capacité est arrivée. Attendre une détection au moment de l’installation manquerait les capacités chargées à l’exécution.
Cela signifie qu’un nouvel outil atterrit dans la vue Discovered tools dès qu’il apparaît sur une requête, même si aucune règle ne le nomme. Activez le mode observe pour enregistrer chaque appel d’outil sans règle correspondante comme un écart de couverture — cette vue pilote la rédaction de politiques à partir du trafic réel.

​
4. Ce que la passerelle ne peut pas voir

La garantie d’inspection couvre les appels qui traversent la passerelle. Elle ne s’étend pas à un outil que votre agent exécute entièrement à l’intérieur de son propre processus — un qui lit un fichier local, appelle une fonction de bibliothèque, ou exécute un sous-processus sans jamais envoyer de message à la passerelle. C’est une limite honnête, pas un défaut de conception. L’objectif de conception est de faire de la passerelle le chemin audité pour les appels qui comptent — ceux avec des conséquences réelles :
Où il s’exécuteLa passerelle le voit ?Comment combler le gap
Appel d’outil médié par le modèle (le modèle émet tool_calls)Oui — surface responseAucune action requise ; déjà gouverné.
Dispatch MCP via la passerelle MCP du FirewallOui — surface mcpAucune action requise ; déjà gouverné.
Votre agent appelle POST /api/v1/firewall/evaluate avant de dispatcherOui — évalué en ligneDéjà gouverné via le hook d’évaluation.
L’outil s’exécute en processus, sans contact avec la passerelleNonRoutez le dispatch MCP et les outils qui appellent le réseau via la passerelle plutôt que de les appeler directement depuis le processus de l’agent.
Si vous avez des outils qui s’exécutent en processus aujourd’hui et ont des conséquences réelles, le chemin vers la couverture est de les enregistrer comme serveurs MCP derrière la passerelle MCP du Firewall ou d’appeler le hook d’évaluation depuis votre boucle d’agent avant de dispatcher.

​
5. Contrôle des rôles sur les données d’inspection

L’accès aux surfaces d’inspection est soumis à des rôles dans votre espace de travail :
CapacitéRôle minimum
Lire les correspondances guardrail, les politiques firewall et les outils découvertsMember
Lire les flux Events et Runs du firewallDeveloper
Créer ou modifier des guardrails, des politiques firewall, des règlesDeveloper
Exports de conformité, texte en clair des clés scopées passerelle-firewall, flag de clé is_firewall_gatewayAdmin
Un token scopé à la passerelle firewall (la clé utilisée pour appeler /api/v1/firewall/evaluate et la passerelle MCP) nécessite le rôle Admin pour être créé. Une clé API ordinaire retourne 403 sur ces routes.

​
6. Où aller ensuite

La pile de contrôle

Le chemin complet de la requête — clé, guardrails, modèle, firewall, audit — en un seul diagramme.

Responsabilité partagée

Ce que la passerelle sécurise et ce qui reste dans votre application.

Agent Firewall

Rédigez des politiques, configurez des surfaces, et gouvernez les appels d’outils en profondeur.
La passerelle est le point d’inspection unique pour chaque appel qui la traverse — configurez vos politiques une fois et chaque fournisseur, chaque agent et chaque appel d’outil est couvert.