Puntos clave
- Nombra el proxy como un componente del producto con un responsable (Front Door, App Gateway o App API).
- Iguala en local y en vivo las reglas de rechazo de autenticación, rutas, tamaño del cuerpo y payloads.
- Elige el patrón de borde según el modelo de amenazas, no como un TLS añadido a última hora.
- Pon en una lista de permitidos los campos de reasoning y de passthrough; descarta las formas desconocidas.
- Aplica la autorización en la ruta de reenvío antes de que Foundry o la API del agente vean la llamada.
- Empieza las revisiones de seguridad por el proxy y después pasa a los prompts y a los controles del corpus.
Los shells en el navegador tientan a los equipos a confiar demasiado en la SPA. La interfaz de chat parece el producto. El proxy delante del backend del agente es donde la autenticación se convierte en autorización, donde se limita la salida y donde los payloads peligrosos se permiten por lista o se descartan.
Trata el proxy como una frontera de seguridad. Elige Front Door, Application Gateway o un patrón equivalente de forma deliberada. No añadas el TLS y la autorización más tarde. Los desajustes de runtime entre el proxy local y el de producción crean una falsa confianza. Los payloads de reasoning y passthrough necesitan listas de permitidos explícitas. Las revisiones de seguridad deberían empezar por el proxy, no por el system prompt.
Modelo con nombre: el proxy como plano de control
- Front end SPA: el shell del navegador guarda tokens y estado de la interfaz. No es la frontera de seguridad.
- Proxy con nombre: termina el TLS, valida la identidad, aplica los scopes, limita la salida y permite por lista la forma del payload.
- Foundry / API del agente: recibe solo lo que el proxy ya autorizó y dio forma.
- Paridad: local y en vivo comparten las mismas reglas de rechazo, aunque los proveedores sean distintos.
- Contrato: la SPA pide; el proxy con nombre decide qué llega al plano del agente.
Figura 1. El proxy como plano de control. La SPA es un front end. El proxy con nombre es responsable de la identidad, los scopes, la salida y la forma del payload antes de que Foundry o la API de tu agente vean la petición.
Contexto y restricción
Un fallo habitual es un proxy local que hace que las demos parezcan seguras mientras el borde en vivo reenvía más de lo que nadie revisó. Los prompts del modelo pueden estar bien y la frontera no. Trata el proxy como el plano de control de la autorización y la salida, y las revisiones se acortan.
Los tokens en el navegador no cuentan toda la historia. El proxy tiene que validar la identidad, aplicar los scopes, limitar la salida a backends aprobados y rechazar payloads con formas inesperadas. Si tu modelo de amenazas empieza por la inyección de prompts y se salta el borde, estás optimizando primero la capa equivocada.
La figura 2 es el planteamiento de Learn para los componentes de gateway delante de las API. Trata esos controles como parte del producto, no como un pulido opcional.
Figura 2. Refuerza la ruta del navegador a las API del agente. Los controles del gateway son parte del producto, no un pulido opcional. Fuente: Microsoft Learn: conceptos clave de API Management.
Diseño
1. Nombra el proxy como un componente del producto
Documenta qué servicio termina el TLS, valida los tokens y reenvía a Microsoft Foundry o a tu API. "El servidor Node en App Service" o "Front Door más la API" debería ser una caja explícita. Los bordes sin nombre acaban siendo bordes sin responsable. La figura 1 muestra esa caja con nombre como carril central.
2. Iguala el comportamiento del proxy local y del de producción
Los mocks locales que se saltan la autorización o abren el CORS enseñan a los desarrolladores los valores por defecto equivocados. Paridad no significa proveedores idénticos; significa las mismas reglas de rechazo para llamadas sin autenticar, cuerpos demasiado grandes y rutas desconocidas. La falsa confianza es un defecto. La figura 3 muestra esa paridad como rechazos compartidos, con el desajuste como antipatrón.
Figura 3. Local y en vivo comparten las reglas de rechazo de autenticación, tamaño y rutas. Una página de wiki que nadie abre no es paridad. Una comprobación que falla y bloquea la promoción sí lo es.
3. Elige Front Door o patrones de gateway a propósito
La latencia, el WAF, el origen privado y la gestión de certificados son distintos. Elige según el modelo de amenazas y la red que ya operas. Atornillar un borde tipo CDN a una aplicación que daba por hecha una intranet amable es como el TLS se convierte en teatro.
4. Pon en lista de permitidos los payloads de reasoning y passthrough
Los fragmentos de streaming, los blobs de llamadas a herramientas y los campos de "debug" viajan a través de los proxies. Las listas de permitidos explícitas son mejores que "reenviar todo lo que mande la SPA". Los campos inesperados son la vía por la que el contenido sensible sale de la ruta que revisaste. La figura 4 es el control de la lista de permitidos.
Figura 4. Permite por lista lo que pasa. Los campos conocidos van al backend del agente. Los desconocidos y los de debug se descartan para que nunca se conviertan en una fuga visible en el navegador.
5. Aplica la autorización en la ruta de reenvío
Rechaza los scopes ausentes o incorrectos antes de que el backend del agente vea la petición. Ocultar botones en React no es una frontera. El proxy y la API comparten una única historia de autorización.
6. Empieza las revisiones de seguridad por el borde
Los system prompts importan. El RBAC del corpus importa. Aun así, empieza la revisión por quién puede llegar al proxy, qué puede invocar y adónde pueden ir las respuestas. Reforzar los prompts en un borde abierto es decoración.
Fallos de Front Door que conviene nombrar
Son habituales los orígenes mal configurados, las sondas de estado que marcan como sanos los shells mientras los backends fallan y los comportamientos de caché que sorprenden al chat en streaming. Documenta el modo de fallo que aceptas: fallar cerrado en la autenticación, fallar de forma visible en el estado del origen y nunca fallar abierto en las comprobaciones de scope. Los operadores necesitan un runbook que no sea "reinicia la SPA".
Checklist de desajustes de runtime
Antes de declarar un shell listo para producción, compara: autenticación obligatoria en local y en vivo, tamaño máximo del cuerpo, rutas permitidas, reenvío de cabeceras, configuración de websocket o SSE y destinos de salida. Pon la comparación en la CI o en una checklist de release. Una página de wiki que nadie abre no es paridad. Una comprobación que falla y bloquea la promoción sí lo es.
Qué entra en la conversación sobre la lista de permitidos
Enumera las rutas de las peticiones, los métodos, los tipos de contenido y los modos de streaming de las respuestas. Enumera qué cabeceras pueden llegar al backend. Enumera qué formas de resultados de herramientas pueden volver al navegador. Si un campo solo sirve para la trazabilidad interna, no debería ser visible en el navegador por defecto. Las listas de permitidos parecen pedantes hasta la primera fuga accidental de un identificador interno.
Errores comunes
Confiar en la SPA. "Los usuarios ya han iniciado sesión" sustituye a la validación de la petición.
Desajuste entre local y en vivo. En desarrollo funciona; en producción se reenvía de más. La figura 3 hace visible ese defecto.
TLS más tarde. Los certificados y la configuración HTTP se convierten en una carrera.
Maximalismo del passthrough. Los campos JSON desconocidos viajan de polizón. La figura 4 es la lista de permitidos que lo impide.
Revisiones que empiezan por el prompt. Las preguntas sobre el borde llegan después de publicar.
Un solo ingeniero es responsable del borde. Las ausencias se convierten en ventanas de riesgo.
Úsalo tal cual o adáptalo
Úsalo tal cual
- La ruta del navegador al agente incluye una frontera explícita de proxy y seguridad con un responsable con nombre.
- Los proxies local y en vivo comparten las reglas de rechazo de autenticación, rutas y payloads.
- La elección de Front Door o gateway (o equivalente) está documentada con su justificación en el modelo de amenazas.
- Los campos de reasoning y passthrough están en una lista de permitidos; los desconocidos se descartan.
- La autorización se aplica en la ruta de reenvío, no solo filtrando en la interfaz.
- Las revisiones de seguridad empiezan por el proxy y después pasan a los prompts y a los controles del corpus.
Adáptalo antes de usarlo
Un proxy serio añade configuración y otro componente con responsable. Saltárselo mantiene rápidas las demos y les pone más fácil la brecha a los atacantes. Las listas de permitidos estrictas rompen los experimentos informales; el passthrough informal rompe las revisiones de incidentes. Igualar local y en vivo cuesta trabajo de fixtures; el desajuste cuesta sorpresas en producción. Las revisiones de seguridad que empiezan por el borde cuestan tiempo de calendario y ahorran tiempo de disculpas.
Referencias principales: la guía de seguridad de Azure Front Door y Application Gateway en Microsoft Learn, más tu ADR de autorización de la API. Acompaña los diagramas de red con las listas de permitidos de payloads para que las revisiones tengan artefactos.
Cierre
Nombra la frontera. Iguala local con en vivo. Elige el borde a propósito. Permite por lista lo que pasa. Aplica la autorización a la entrada. Empieza las revisiones por el proxy. El system prompt puede esperar su turno.
Relacionado
- Azure Custom Vision: ¿cómo entrenas y ejecutas clasificación de imágenes en una Azure Function? (la misma regla a pequeña escala: las claves de predicción se quedan detrás de la API de la app)