RespuestasPublicado14 fuentes
Un gateway para IA, dos tipos de acceso y una regla clave: no exponer la clave maestra
Mantén el código, el gateway y las credenciales principales en el entorno de confianza; el servidor de desarrollo no confiable debe recibir permisos limitados y revocables. El miniprograma debe llamar a una función de negocio en el backend, no a un gateway de chat abierto ni con acceso a la clave maestra.
Publicado porImágenes generadas con GPT Image 2
Respuesta de investigación
Conclusiones clave
- Mantén el código, el gateway y las credenciales principales en el entorno de confianza; el servidor de desarrollo no confiable debe recibir permisos limitados y revocables.
- El miniprograma debe llamar a una función de negocio en el backend, no a un gateway de chat abierto ni con acceso a la clave maestra.
- Antes de abrir el servicio, corrige la escucha en todas las interfaces y verifica la autenticación: el código actual no demuestra que el acceso esté protegido.
- Para conectar servidores confiables, empieza con el túnel SSH que ya existe y mide la latencia; no hay datos que permitan asegurar que el cambio no tendrá ningún coste.
![[GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you operate via client side tool execution on the](https://d15bya8fi85z1v.cloudfront.net/chat/X2Iv9UzutJWrB6MyNYnoFEwyNX93/images/B46231A279305D82E030/F351DDBF81DB11332C64.png)
Prompt de IA
openai.comCreate a landscape editorial hero image for this Studio Global article: [GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you operate via client side tool execution on the. Article summary: <tool call {"name":"attempt completion","arguments":{"result":"在你确认的边界下，推荐统一采用“网关留在可信 VPS，现有可信业务后端负责对外接入”的架构：不可信开发环境只获得受限调用权限，小程序只访问业务接口。无需先建设 Nginx、负载均衡或复杂防火墙体系，但不能承诺绝对零时延损失。\n\n 先指出当前代码的安全缺口\n\n 当前启动入口默认监听所有网卡，而不是仅本机。依. Topic tags: general web, code, api, security, data. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with
La opción más sencilla que respeta los límites planteados es mantener el gateway en un VPS de confianza y usar el backend de negocio existente como único punto de entrada. El entorno de desarrollo no confiable recibiría permisos acotados; el miniprograma, en cambio, solo accedería a funciones de producto. Así no hace falta empezar por desplegar Nginx, un balanceador o una capa compleja de cortafuegos. Eso sí: no hay base para prometer que la arquitectura tendrá latencia adicional nula.
Antes de conectar clientes, hay que cerrar estos huecos
El código actual merece una revisión antes de abrir cualquier acceso:
- El punto de entrada de la aplicación escucha por defecto en todas las interfaces, no solo en la dirección local. Véase
main.go. En el VPS de confianza conviene limitar el gateway a la interfaz de loopback y no exponerlo directamente a Internet. - La ruta principal no muestra autenticación para quienes llaman al servicio y registra rutas de chat, catálogo de modelos y estadísticas. Véase
internal/api/chat.go. Que un cliente tenga un campo para introducir una clave no significa que el servidor la esté verificando. - Hay middleware de autenticación antiguo para Gin, pero el arranque actual usa el enrutamiento HTTP estándar, y la ruta principal revisada no lo invoca. Véanse
middlewares/auth.goymain.go. Configurar una variable de entorno de ese middleware no demuestra que el acceso actual esté protegido. - La configuración de admisión existente está marcada para pruebas locales y exige que el límite por cliente sea cero. No debe tratarse como un sistema de límites listo para producción con varios usuarios. Véanse
internal/chatadmission/config.goyinternal/chatadmission/config.go.
Desarrollo no confiable: acceso remoto, no despliegue del gateway
Flujo recomendado: VPS de desarrollo no confiable → entrada HTTPS limitada en el backend de confianza → enlace privado → gateway en el VPS de confianza.
El código fuente, la compilación, la instancia del gateway y las credenciales de los proveedores deben permanecer en el entorno confiable. El servidor de desarrollo solo necesita una dirección de acceso y una credencial específica para desarrollo.
Esa entrada puede conservar el protocolo de chat que necesite el cliente, pero debería permitir únicamente los métodos, rutas y modelos imprescindibles. No debería dar acceso a estadísticas, administración, reenvío arbitrario ni funciones de gestión de cuentas. Emite una credencial independiente para cada entorno, revocable y de duración limitada, con modelos permitidos, tamaño máximo de solicitud, concurrencia y presupuesto acumulado. Separa por completo las credenciales de desarrollo de las de producción.
La verificación de la credencial y el descuento del presupuesto deben ocurrir en el backend confiable. No basta con aplicar controles dentro del servidor no confiable.
El límite de seguridad importa: si no se confía en quien administra el host, hay que asumir que puede leer o modificar las credenciales, solicitudes y respuestas que pasen por ese entorno. Una credencial temporal reduce el tiempo de exposición, pero no impide que la copien. Un contenedor, un binario distribuido o la ofuscación tampoco garantizan confidencialidad frente a quien controla el host.
Por eso, el objetivo no es guardar una clave maestra imposible de robar en el VPS no confiable. Es evitar que la clave maestra llegue allí y limitar el daño si se filtra un permiso de desarrollo. El trabajo verdaderamente sensible debe permanecer en un entorno confiable.
No conviene conectar ese VPS por SSH directamente al gateway actual, que no muestra autenticación. Si se compromete la identidad del túnel, podrían saltarse los controles previstos. Si el túnel es imprescindible, debe terminar en la entrada de desarrollo limitada, no en el gateway original ni en otros servicios privados.
Miniprograma de prueba: ofrecer una función, no un gateway abierto
Flujo recomendado: miniprograma de WeChat → backend de negocio confiable, con inicio de sesión, cuotas y agente → enlace privado → gateway → modelo externo.
El miniprograma debería reutilizar el inicio de sesión del producto. En el flujo oficial, el cliente obtiene una credencial temporal y el servidor la intercambia por la identidad del usuario; luego el servidor genera su propio estado de sesión. La clave de sesión no debe entregarse al cliente.9
La interfaz puede recibir la descripción del puesto, los requisitos y la experiencia personal necesaria para la tarea, pero no debería contener la clave maestra del gateway ni permitir que el usuario elija cualquier modelo, instrucción de sistema o herramienta. En el backend, añade una función concreta —por ejemplo, «mejorar los puntos fuertes del perfil»— con modelos candidatos, plantilla de instrucciones, capacidades de búsqueda y formato de salida fijados por el servicio. No conviertas la función en un proxy de chat sin límites.
El backend debe obtener la identidad de la sesión ya validada, no confiar en un identificador de usuario enviado en el cuerpo de la petición. También debe separar tareas, contexto y cuotas por usuario para evitar mezclar historiales.
Define límites por usuario, por tarea y para el conjunto del servicio: número máximo de llamadas al modelo y a herramientas, tamaño de entrada y salida, presupuesto total de la prueba y un mecanismo de suspensión de emergencia. La prueba puede ser gratuita, pero no debería carecer de un tope de gasto. Cada paso del agente consume el presupuesto de la misma tarea; las cancelaciones, los tiempos de espera y los reintentos también deben estar acotados para que un bucle de exploración no multiplique las llamadas indefinidamente.
Si el backend funciona con varios procesos, la reserva y liquidación de cuotas deben coordinarse mediante transacciones en la base de datos existente. Si cada proceso calcula el presupuesto por separado, el límite global podría no respetarse.
El miniprograma puede seguir usando el dominio HTTPS del backend de negocio. WeChat exige configurar previamente los dominios permitidos para las comunicaciones de red habituales del miniprograma, por lo que no hace falta publicar además el dominio del gateway.7
Conexión privada: reutilizar el túnel y medir antes de cambiarlo
Si el backend y el gateway están en la misma máquina confiable, prioriza la conexión local. Si están en dos máquinas confiables, la primera opción puede ser reutilizar el túnel SSH persistente existente: el backend confiable llama al gateway a través de él, sin crear un túnel nuevo por cada solicitud.
Usa una identidad SSH dedicada, limitada al reenvío de puertos y al destino necesario. El gateway debe escuchar en una dirección local y, si el túnel cae, las llamadas deben fallar: no deberían desviarse a una ruta pública sin protección. Deja las llamadas sin una clave de aplicación solo para este enlace interno controlado, y únicamente si también confías en los demás procesos del host. Toda entrada accesible desde un entorno no confiable debe verificar una credencial independiente.
Solo si las mediciones muestran que el túnel es un cuello de botella tendría sentido probar WireGuard entre las dos máquinas confiables. WireGuard ofrece autenticación y cifrado basados en claves de los pares, pero eso no demuestra que vaya a ser más rápido en este caso.12
16
La propuesta no añade un intermediario de terceros ni otra capa de proxy inverso. El backend debería reutilizar conexiones, transmitir la respuesta progresivamente cuando corresponda y propagar la desconexión del miniprograma a la tarea en curso.
La latencia adicional todavía no está demostrada. Mide por separado el tiempo de red entre el backend y el gateway, el tiempo hasta el primer fragmento de respuesta y la duración total de la tarea. Compara la mediana y los valores de cola alta. La calidad real de la ruta desde China continental hasta el gateway y el proveedor del modelo también requiere una prueba específica.
Tampoco conviene asumir que un modelo es rápido solo por su nombre. Las pruebas actuales de modelos candidatos mantienen la configuración previa de modo profundo, alto nivel de razonamiento y respuesta detallada; además, no demuestran que el proveedor real esté disponible ni cuál será su latencia. Véase internal/upstream/studioglobal/registry_fast_models_test.go y internal/upstream/studioglobal/registry_fast_models_test.go. Para optimizar puntos fuertes, crea y mide una configuración ligera específica de esa función sin cambiar directamente la configuración de desarrollo existente.
Orden de implementación y comprobaciones
- Limita dónde escucha el gateway y comprueba que ni Internet ni el VPS no confiable pueden acceder a él saltándose el backend.
- En el backend confiable, separa los permisos de desarrollo limitado de los permisos de prueba pública, cada uno con sus credenciales y presupuesto.
- Implementa un agente con límites, reserva de cuotas, propagación de cancelaciones y salida progresiva, además de un presupuesto global.
- Comprueba que se rechacen las credenciales ausentes o revocadas; que el acceso de desarrollo no alcance rutas administrativas; que la tarea se detenga al agotar su cuota; y que usuarios, llamadas múltiples y reintentos no superen los límites previstos.
- Abre una prueba pequeña, mide la latencia y decide entonces si hace falta cambiar el transporte privado o separar instancias.
Qué queda fuera y qué debe confirmarse
Esta propuesta no implementa nada, no despliega servicios, no ejecuta pruebas ni escribe un ADR o un plan. Es una recomendación de arquitectura, no una validación de que la instalación actual sea segura.
Tampoco propone empezar con balanceadores, una malla de servicios o una plataforma permanente para agentes. A cambio, hay que aceptar los límites de capacidad y el posible fallo de una instancia única.
Antes de abrir la prueba al público, falta confirmar si las condiciones del proveedor permiten ofrecerla, cómo circularán realmente los datos personales de experiencia y qué requisitos de cumplimiento aplican. Conviene enviar solo la información necesaria y, cuando sea posible, reducir los datos identificativos; no registrar el currículum completo ni credenciales.
La decisión central es sencilla: el código y las claves maestras se quedan en el entorno confiable; desarrollo recibe permisos limitados; el miniprograma recibe funciones de negocio; y la conexión interna usa un canal privado controlado. La prioridad es cerrar la autenticación, los presupuestos y los límites de cada tarea, no sumar capas de infraestructura por defecto.
Studio Global AI
Continúe su investigación
Esta página incluye una respuesta respaldada por fuentes que puede continuar dentro de Studio Global.
La gente también pregunta
¿Cuál es la respuesta corta a "Un gateway para IA, dos tipos de acceso y una regla clave: no exponer la clave maestra"?
Mantén el código, el gateway y las credenciales principales en el entorno de confianza; el servidor de desarrollo no confiable debe recibir permisos limitados y revocables.
¿Cuáles son los puntos clave a validar primero?
Mantén el código, el gateway y las credenciales principales en el entorno de confianza; el servidor de desarrollo no confiable debe recibir permisos limitados y revocables. El miniprograma debe llamar a una función de negocio en el backend, no a un gateway de chat abierto ni con acceso a la clave maestra.
¿Qué debo hacer a continuación en la práctica?
Antes de abrir el servicio, corrige la escucha en todas las interfaces y verifica la autenticación: el código actual no demuestra que el acceso esté protegido.