Passer au contenu principal
Quand une clé fuite, qu’un prestataire quitte le projet, ou qu’un token arrive simplement en fin de vie, vous devez échanger le credential sur un serveur MCP enregistré sans démanteler l’enregistrement du serveur, re-rédiger ses règles firewall, ni interrompre les agents déjà connectés via la passerelle. C’est ce qu’est la rotation : mettez à jour l’auth sur un serveur existant, et la passerelle MCP commence à injecter le nouveau secret dès le tout prochain tools/call qu’elle dispatche. L’auth de chaque serveur est chiffrée au repos et masquée en lecture, de sorte que le token en clair ne fait jamais d’aller-retour vers votre console, vos agents, ou le modèle. La rotation est une mise à jour d’un seul champ via la console d’espace de travail.

​
1. Pourquoi la rotation des secrets MCP est une action à part

Un serveur MCP enregistré détient trois choses que vous ne voulez pas perdre quand un credential change : un name unique par espace de travail (le namespace <server>.<tool> contre lequel vos règles font correspondre leurs globs), un endpoint, et son ensemble d’outils découverts. Supprimer et recréer le serveur pour changer un token orphelinerait chaque règle cadrée sur <server>.* et forcerait un nouveau sondage. La rotation contourne tout cela. Vous faites un PUT sur le même enregistrement de serveur avec un nouveau auth_json ; tout le reste — nom, règles, outils découverts — reste en place.
La passerelle injecte les credentials au moment du dispatch, ne les déchiffrant que pour faire l’appel amont. Un secret tourné prend effet à la prochaine connexion — OrcaRouter invalide le cache d’outils par espace de travail à chaque changement de serveur, donc il n’y a aucun TTL à attendre.

​
2. Une rotation concrète

Disons que vous avez enregistré un serveur MCP nommé github avec un bearer token, et que ce token doit tourner. Lisez d’abord l’enregistrement actuel — la réponse masque le secret, donc vous ne manipulez jamais l’ancien texte en clair : 
# Configurez depuis la session console (UserAuth), pas une clé relais.
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42 \
  -H "Authorization: Bearer <your console access token>"
Puis faites un PUT sur le même enregistrement avec uniquement le nouveau credential. Envoyez l’id dans le corps et le nouveau auth_json ; la passerelle le re-chiffre avant qu’il ne touche la base de données : 
curl -X PUT https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your console access token>" \
  -H "Content-Type: application/json" \
  -d '{
    "id": 42,
    "auth_json": "{\"token\":\"ghp_NEW_token\"}"
  }'
Les champs que vous omettez sont laissés intacts — name, endpoint, auth_mode et enabled conservent tous leurs valeurs stockées. Le nouveau token est actif au prochain tools/call.
Renvoyez le masque pour conserver un secret ; envoyez une vraie valeur pour le changer. Si vous lisez l’enregistrement et le PUT à l’identique, le placeholder masqué dans auth_json est reconnu comme « conserver ce qui est stocké » — le secret n’est pas écrasé par le masque. Seul un auth_json réellement nouveau fait la rotation du credential.

​
3. Changer de mode d’auth, pas seulement le secret

La rotation couvre aussi le déplacement d’un serveur entre schémas d’auth. L’ensemble fermé de valeurs auth_mode est :
Aucun credential. auth_json est vide. À utiliser pour les serveurs MCP publics ou de confiance réseau.
{ "token": "…" } — envoyé comme en-tête Authorization: Bearer.
{ "client_id": "…", "client_secret": "…", "token_url": "…" }. Si vous stockez un access_token statique dans le JSON, la passerelle l’envoie comme bearer token ; l’échange de client-credentials lui-même n’est pas encore exécuté, donc un serveur qui a besoin d’un échange en direct échouera jusqu’à ce que vous fournissiez un token.
{ "username": "…", "password": "…" } — auth HTTP basic.
Passer d’un mode credentialé à un autre (p. ex. bearer → basic) nécessite d’envoyer un auth_json frais dans la même requête. Le chiffré stocké est lié à son mode d’origine, donc l’ancien secret ne peut pas être réinterprété sous la nouvelle forme — fournissez le nouveau credential, ou la mise à jour est rejetée.

​
4. Après la rotation : re-sonder

Un credential tourné change quels outils vous pouvez atteindre si l’ancien token avait été révoqué. Sondez le serveur pour confirmer que la nouvelle auth fonctionne et rafraîchir son status de joignabilité : 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your console access token>"
Le sondage exécute un handshake MCP avec le nouveau credential déchiffré et rapporte ok, degraded, ou down. Un échec d’auth fait surface ici plutôt que comme une erreur d’outil déroutante en plein run.

​
5. Rôles et ce qui reste masqué

Chaque action de cette page est un appel console à portée d’espace de travail (/api/workspace/firewall/mcp_servers, UserAuth) et est soumise à des rôles :
ActionRôle minimum
Lire un serveur (secret masqué)Member
Rotation / mise à jour / enregistrementDeveloper+
SuppressionDeveloper+
Le texte en clair n’est jamais renvoyé à votre console. Les lectures masquent le secret et redactent l’endpoint ; la passerelle est la seule chose qui déchiffre un credential, et seulement au moment où elle compose le serveur amont. Le modèle et vos agents ne voient ni l’ancien ni le nouveau token.

​
6. Où cela s’inscrit

La rotation est une opération dans la surface de confiance MCP plus large. Une fois vos serveurs connectés et authentifiés, la même passerelle évalue chaque tools/call contre votre politique firewall avant qu’il ne s’exécute, applique la quarantaine de skill par-dessus, et gouverne la portée sortante.

Connecter un serveur

Enregistrer un serveur MCP et sonder ses outils.

S'authentifier

Choisir le bon mode d’auth pour chaque serveur.

Lister les outils MCP autorisés

Cadrer quels outils chaque serveur peut exposer.

Limites d'egress

Gouverner où les appels d’outils peuvent atteindre.
Voir Firewall : serveurs MCP pour le cycle de vie complet du serveur et la checklist de confiance MCP pour la passe de durcissement de bout en bout. La rotation est aussi un point récurrent contre l’empoisonnement d’outils MCP et l’exfiltration de données : un credential que vous pouvez tourner vite est un credential sur lequel une fuite ne peut pas s’installer.

​
FAQ

Non. La rotation ne change que le credential. Le serveur conserve son name, donc chaque règle cadrée sur <server>.* — et toute liste d’autorisation — reste attachée.
Le nouveau secret est injecté au prochain tools/call dispatché. Il n’y a aucun TTL de cache à attendre — OrcaRouter invalide le cache d’outils d’espace de travail à chaque changement de serveur.
Non — et c’est tout l’intérêt. Les lectures renvoient un secret masqué ; le texte en clair n’est jamais déchiffré que par la passerelle au dispatch. Faites la rotation en envoyant une nouvelle valeur, puis sondez pour confirmer qu’elle fonctionne.