Restringir el MCP por origen de red

Por defecto, la superficie MCP está protegida solo por la posesión del token: cualquier origen en internet que presente un PAT válido abre una sesión y ejecuta las tools de tu organización. Un token filtrado (en un .mcp.json subido al repositorio, un log de CI, un backup de la configuración de una laptop) es acceso de lectura a tu infraestructura, desde cualquier lugar.

La allowlist de origen no reemplaza al token. Agrega un segundo factor: además de tener la credencial, tienes que estar en tu red. Un token filtrado deja de ser suficiente.

Cómo funciona

Declaras los bloques CIDR (IPv4 e IPv6) autorizados a hablar con el servidor MCP, en Gobernanza → Acceso por origen de red.

La verificación corre en cada solicitud, no solo cuando se abre la sesión. Una sesión MCP es larga y con estado, pero la autorización de origen no lo es: un token que cambia de red a mitad de una investigación se rechaza a partir de ese momento.

Antes de activarla: parte de los orígenes observados

El modo de falla aquí es el lockout: configurar la lista equivocada y dejar a todo tu equipo afuera. El NAT de la oficina, el egress del clúster y las salidas de VPN rara vez son la dirección que la gente supone, y adivinar el bloque es la forma más rápida de quedarte afuera.

Para eso está la pantalla de orígenes observados: la última dirección desde la que cada uno de tus tokens nos llegó. Empieza por ahí. Es la dirección real, medida de nuestro lado, y no la que alguien supone. Basta con conectarte una vez con tu cliente MCP antes de configurar la lista.

También sirve para otra cosa, y esa parte siempre fue real: confirma que la lectura de la IP es correcta de punta a punta (un conteo de hops equivocado aparece ahí como un valor obviamente erróneo) y revela un uso que viene de un lugar que nadie esperaba.

Y si de todos modos te quedas afuera, el camino de vuelta no depende de ella: el rechazo devuelve la IP de quien llama y se convierte en una entrada de auditoría, así que el bloque que falta se puede leer en el propio rechazo.

Qué guardamos de ese origen, y por cuánto tiempo

Registrar la dirección de cada conexión autorizada es lo que hace que la pantalla de arriba funcione para quien todavía no tiene una lista. Y eso es recolección, así que viene declarada y con un interruptor.

Una dirección por token, la última. No hay historial: cada conexión sobrescribe el valor anterior. No guardamos la ruta, la geolocalización ni la dirección de cada solicitud.
No sale de tu organización. La leen los owners y admins de tu organización, y nadie más: no alimenta ningún agregado entre clientes y nunca se envía a un proveedor de modelos.
Vive lo que vive el token. Revocar un token borra la dirección en la misma acción; eliminar la organización borra todo; y un origen que no se vuelve a ver en 90 días se borra solo: desde dónde se conectaba tu equipo hace tres meses no es evidencia del egress de hoy, y ofrecerlo como punto de partida sería un lockout con un paso extra.
La dirección de una conexión RECHAZADA queda en el log de auditoría de todos modos: así es como un token filtrado que se usa desde afuera se vuelve visible para ti, y un control de acceso que no registra el rechazo no es verificable.

Para desactivarlo: Gobernanza → Origen de las conexiones MCP, el interruptor “Registrar el origen de cada conexión”. Desactivarlo también borra lo que ya se observó en tu organización, y el cambio queda en tu log de auditoría. El costo es el de la primera sección: la lista de orígenes queda vacía, y configurar la allowlist vuelve a depender de que encuentres tu propio egress por otro lado.

Cuando se rechaza una solicitud

La respuesta es 403 con error: "origin_not_allowed", y no devuelve la lista: alguien de afuera no aprende nada sobre lo que se aceptaría. Sí devuelve la IP observada de esa solicitud, que es de quien llama, y es lo que permite que una persona legítima pida que se agregue su bloque.

Cada rechazo se convierte en una entrada de auditoría con la dirección observada. Así es como un token filtrado que se usa desde afuera se vuelve visible para ti. Una allowlist que bloqueara en silencio ocultaría justamente el evento que importa.

Qué pasa si no podemos leer la política

La solicitud se rechaza (503), no se permite.

No poder leer la política es ambiguo entre “no hay lista” y “no sé si hay una”, y en un control de acceso esas dos cosas no pueden tener el mismo efecto. Rechazar es visible y reversible; permitir en silencio convertiría una caída nuestra en un agujero en tu control.

Quién lo aplica, y qué significa eso para ti

Lo que no cubre

La conexión del Agent (runner) no pasa por aquí. Se conecta por mTLS con un certificado por organización, que es una prueba más fuerte que una dirección de red. Restringirla por IP agregaría fragilidad operativa (la flota es efímera y el egress cambia) sin agregar ninguna garantía.
No reemplaza la rotación de tokens. Si sospechas una filtración, revoca el PAT; la allowlist acota la ventana, no la cierra.
No es aislamiento de red. Filtra quién habla con el servidor MCP, no lo que pasa después. Para qué se puede leer, consulta la denylist de tools.