Cómo está cableada la ruta de CLI y MCP

El 13 de agosto de 2026 publicamos Cómo está cableado el agente para recorrer el camino que hace una llamada a herramienta dentro de T6X. Este texto es el complemento más acotado de aquel: qué cambia cuando el operador está fuera de la plataforma y usa un agente por CLI u otro cliente MCP.

La respuesta corta es que cambia el protocolo, pero no cambian los controles.

Un asistente externo sigue llegando a la misma superficie de comandos gobernada. No recibe una segunda API, una ruta de aprobación más débil ni acceso directo a credenciales. MCP es solo el conector en el borde. Los puntos de control reales siguen siendo la identidad, la superficie efectiva de herramientas, la compuerta de aprobación, la intermediación de credenciales del lado del servidor y la cadena de auditoría.

La ruta externa

Para un asistente fuera de la plataforma, el recorrido se ve así:

agente por CLI o cliente MCP
  -> token de puente
  -> endpoint del puente MCP
  -> resolución de tenant y agente
  -> superficie efectiva de herramientas
  -> compuerta de aprobación para llamadas sensibles
  -> ejecución
  -> traza de auditoría encadenada por hash

Ese es el primer punto importante: el asistente externo no llama directamente al sistema de negocio. Entra al mismo host gobernado que usa el resto de la plataforma.

En el borde del puente, los nombres de herramienta se ponen en espacio de nombres como <serverSlug>__<toolName>. El puente actual del seed acepta Authorization: Bridge <token>, verifica el token, resuelve el agente referido, restaura el contexto de tenant del lado del servidor y solo entonces lista o ejecuta herramientas.

Así que incluso para una sesión manejada por CLI, la pregunta interesante no es “¿habla MCP?” La pregunta interesante es “¿qué deja hacer el host a esta identidad una vez que entra?”

La identidad llega antes que las herramientas

La página del producto para CLI dice que tu propio asistente firma como sí mismo, con inicio de sesión único o con una clave acotada, bajo las mismas reglas que todos. Eso importa porque la gobernanza empieza con la identidad, no con un prompt.

En la ruta del puente, el asistente presenta un token de puente. El servidor lo verifica y resuelve el registro de agente asociado antes de despachar. Si el token es inválido, o apunta a un agente que ya no existe, la llamada se detiene ahí. Si el agente pertenece a un tenant, el puente vuelve a entrar a ese contexto de tenant antes de hacer cualquier trabajo.

Eso es lo que evita que el conector externo se convierta en una puerta lateral. No se confía en el asistente por ser “tu IA”. Se le restringe porque el host restablece identidad y alcance antes de que una herramienta se vuelva invocable.

La superficie sigue gobernada

Una vez dentro, el asistente tampoco recibe una bolsa libre de herramientas.

T6X resuelve la superficie efectiva de un agente desde el lado del host. Para agentes ligados a una vista, la fórmula en runtime es el catálogo de la vista más cualquier allowlist explícita, menos denies, intersectado con los propios permisos de quien llama. El punto importante es estructural: la plataforma calcula la superficie, el modelo no.

La misma desconfianza aplica al efecto de las herramientas MCP. Un servidor MCP puede describir sus propias herramientas, incluido si afirma que leen o escriben. T6X no toma esa afirmación como suficiente. El efecto en runtime sale del catálogo del operador, y un efecto desconocido se niega en lugar de suponerse inocuo.

Eso cierra un modo de falla común en sistemas con agentes. Una herramienta destructiva no se vuelve de solo lectura porque un servidor la haya etiquetado así.

Las superficies de operador alrededor de MCP también están gobernadas. En el seed actual, el lado de escritura en GraphQL para definiciones de servidores MCP y sus adjuntos es solo para admin, y la ruta privilegiada para invocación directa de herramientas es aún más estrecha. Así que incluso el acto de definir o adjuntar capacidad MCP externa está detrás de verificaciones de rol.

Los secretos se quedan del lado del servidor

La propiedad de seguridad más fuerte en esta ruta es que el modelo no sostiene la credencial real de la integración.

La prueba concreta ya existe en el harness end to end de kubectl. El agente pide correr la herramienta kubectl con {{vault.KUBECONFIG}}. La fila de auditoría registra ese marcador, no el kubeconfig mismo. El secreto real se sustituye del lado del servidor por la ruta del puente con soporte de vault antes de que el servidor MCP externo reciba la llamada.

Eso significa que el asistente puede pedir trabajo que requiere una credencial sin ver jamás el valor de la credencial. El modelo recibe el marcador, el host lo resuelve y la traza de auditoría conserva el marcador original visible para revisión posterior.

Es el mismo diseño descrito en el artículo anterior sobre el cableado, solo que ahora visto desde la ruta del asistente externo y no desde el turno de un agente dentro de la plataforma.

La aprobación y la auditoría siguen importando más que el protocolo

Si el asistente llega a una herramienta sensible, el control importante sigue no siendo “¿esta llamada vino de una CLI?” El control importante es “¿qué efecto tiene esta herramienta, y fue aprobada bajo política?”

La promesa del pilar de CLI es que la vista previa, el mínimo privilegio y la confirmación en cambios sensibles aplican al asistente igual que a una persona. Esa promesa solo importa si la traza también es la misma. En T6X, la meta es una sola historia de auditoría, no una para humanos y otra para agentes externos.

Cada llamada sigue cayendo en el mismo registro a prueba de manipulaciones. El protocolo en el borde puede variar, pero el registro que importa es el que queda dentro del host gobernado.

Qué está implementado hoy

El repositorio actual ya muestra las piezas importantes de esta ruta:

texto del producto para CLI que posiciona explícitamente a MCP como la forma de traer tu propio asistente a la superficie de comandos.
cableado de configuración y despliegue para la URL base del puente MCP, el secreto del token y el secreto de firma de auditoría.
código del puente que verifica tokens Bridge, resuelve el agente objetivo y restablece el contexto de tenant antes de listar o despachar herramientas.
política MCP que separa operaciones de escritura ordinarias de otras privilegiadas y más estrechas.
evidencia del harness end to end de que los marcadores de vault sobreviven en las invocaciones MCP registradas mientras el secreto real se sustituye más tarde.

El controlador actual del puente en el seed también documenta con claridad un detalle de implementación pendiente: todavía espera que se conecte un proveedor concreto de herramientas in process antes de que ese endpoint pueda exponer un catálogo real de herramientas a través del puente. Es una nota sobre el estado actual del seed, no un modelo distinto de gobernanza.

La parte importante ya se ve en el código: los asistentes externos están hechos para entrar bajo los mismos controles, no alrededor de ellos.

El punto de MCP aquí

MCP es útil porque da un conector estándar para asistentes externos. Pero el protocolo en sí no es la historia del producto.

La historia del producto es la igualdad de controles:

el asistente entra como identidad
el host resuelve la superficie permitida
las acciones sensibles siguen con compuerta
los secretos se quedan del lado del servidor
cada llamada cae en la misma traza de auditoría

Por eso importa la ruta de CLI. No es un conector novedoso pegado al costado. Es otra forma de llegar a la misma superficie gobernada.