Saltar al contenido principal
Cuando una clave se filtra, un contratista termina su trabajo, o un token simplemente caduca, necesitas cambiar la credencial en un servidor MCP registrado sin derribar el registro del servidor, reescribir sus reglas de firewall, ni interrumpir a los agentes ya conectados a través del gateway. Eso es lo que es la rotación: actualizar la autenticación en un servidor existente, y el gateway MCP empieza a inyectar el nuevo secreto en el mismísimo siguiente tools/call que despacha. La autenticación de cada servidor se cifra en reposo y se enmascara en lectura, así que el token en texto plano nunca regresa a tu consola, tus agentes o el modelo. La rotación es una actualización de un solo campo a través de la consola del espacio de trabajo.

​
1. Por qué la rotación de secretos MCP es su propia acción

Un servidor MCP registrado guarda tres cosas que no quieres perder cuando cambia una credencial: un name único de espacio de trabajo (el espacio de nombres <server>.<tool> contra el que tus reglas hacen glob), un endpoint y su conjunto de herramientas descubierto. Eliminar y recrear el servidor para cambiar un token dejaría huérfana cada regla acotada a <server>.* y forzaría un sondeo fresco. La rotación esquiva todo eso. Haces PUT del mismo registro de servidor con un auth_json nuevo; todo lo demás — nombre, reglas, herramientas descubiertas — se queda en su sitio.
El gateway inyecta las credenciales en tiempo de despacho, descifrándolas solo para hacer la llamada upstream. Un secreto rotado surte efecto en la siguiente conexión — OrcaRouter invalida la caché de herramientas por espacio de trabajo en cada cambio de servidor, así que no hay TTL que esperar.

​
2. Una rotación concreta

Digamos que registraste un servidor MCP llamado github con un token bearer, y ese token necesita rodar. Lee primero el registro actual — la respuesta enmascara el secreto, así que nunca manejas el viejo texto plano: 
# Configura desde la sesión de consola (UserAuth), no una clave de relay.
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42 \
  -H "Authorization: Bearer <your console access token>"
Luego haz PUT del mismo registro con solo la nueva credencial. Envía el id en el cuerpo y el auth_json fresco; el gateway lo recifra antes de que toque la base de datos: 
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\"}"
  }'
Los campos que omites se dejan intactos — name, endpoint, auth_mode y enabled mantienen todos sus valores almacenados. El nuevo token está vivo en el siguiente tools/call.
Haz eco de la máscara para mantener un secreto; envía un valor real para cambiarlo. Si lees el registro y haces PUT de vuelta textualmente, el marcador enmascarado en auth_json se reconoce como “mantén lo que está almacenado” — el secreto no se sobrescribe con la máscara. Solo un auth_json genuinamente nuevo rota la credencial.

​
3. Cambiar el modo de autenticación, no solo el secreto

La rotación también cubre mover un servidor entre esquemas de autenticación. El conjunto cerrado de valores de auth_mode es:
Sin credencial. auth_json está vacío. Úsalo para servidores MCP públicos o de confianza por red.
{ "token": "…" } — enviado como una cabecera Authorization: Bearer.
{ "client_id": "…", "client_secret": "…", "token_url": "…" }. Si almacenas un access_token estático en el JSON, el gateway lo envía como un token bearer; el intercambio de client-credentials en sí aún no se ejecuta, así que un servidor que necesita un intercambio en vivo fallará hasta que suministres un token.
{ "username": "…", "password": "…" } — autenticación básica HTTP.
Cambiar entre dos modos con credenciales (p. ej. bearer → basic) requiere enviar un auth_json fresco en la misma solicitud. El texto cifrado almacenado está atado a su modo original, así que el viejo secreto no puede reinterpretarse bajo la nueva forma — suministra la nueva credencial, o la actualización se rechaza.

​
4. Después de rotar: re-sondea

Una credencial rotada cambia a qué herramientas puedes alcanzar si el viejo token había sido revocado. Sondea el servidor para confirmar que la nueva autenticación funciona y refrescar su status de alcanzabilidad: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your console access token>"
El sondeo ejecuta un handshake MCP con la credencial nueva descifrada e informa ok, degraded o down. Un fallo de autenticación aflora aquí en vez de como un confuso error de herramienta a mitad de ejecución.

​
5. Roles y qué permanece enmascarado

Cada acción de esta página es una llamada de consola con alcance de espacio de trabajo (/api/workspace/firewall/mcp_servers, UserAuth) y está restringida por rol:
AcciónRol mínimo
Leer un servidor (secreto enmascarado)Member
Rotar / actualizar / registrarDeveloper+
EliminarDeveloper+
El texto plano nunca se devuelve a tu consola. Las lecturas enmascaran el secreto y redactan el endpoint; el gateway es lo único que descifra una credencial, y solo en el momento en que marca el servidor upstream. El modelo y tus agentes no ven ni el viejo ni el nuevo token.

​
6. Dónde encaja esto

La rotación es una operación dentro de la superficie de confianza MCP más amplia. Una vez que tus servidores están conectados y autenticados, el mismo gateway evalúa cada tools/call contra tu política de firewall antes de que se ejecute, aplica la cuarentena de skill encima, y gobierna el alcance saliente.

Conectar un servidor

Registra un servidor MCP y sondea sus herramientas.

Autenticar

Elige el modo de autenticación correcto para cada servidor.

Lista de permitidos de herramientas MCP

Acota qué herramientas puede exponer cada servidor.

Límites de egress

Gobierna dónde pueden alcanzar las llamadas a herramienta.
Ver Firewall: servidores MCP para el ciclo de vida completo del servidor y la lista de verificación de confianza MCP para la pasada de endurecimiento de extremo a extremo. La rotación también es una partida permanente contra el envenenamiento de herramientas MCP y la exfiltración de datos: una credencial que puedes rodar rápido es una credencial sobre la que una filtración no puede sentarse.

​
FAQ

No. La rotación cambia solo la credencial. El servidor mantiene su name, así que cada regla acotada a <server>.* — y cualquier lista de permitidos — permanece adjunta.
El nuevo secreto se inyecta en el siguiente tools/call despachado. No hay TTL de caché que esperar — OrcaRouter invalida la caché de herramientas del espacio de trabajo en cada cambio de servidor.
No — y ese es el punto. Las lecturas devuelven un secreto enmascarado; el texto plano solo lo descifra el gateway en el despacho. Rota enviando un valor nuevo, luego sondea para confirmar que funciona.