🔐 Copilot Studio bloquea publicar agentes que reutilizan credenciales del maker
🔐 Copilot Studio bloquea publicar agentes que reutilizan credenciales del maker
Microsoft ha añadido en Power Platform admin center un control de seguridad que permite impedir que un agente de Copilot Studio se comparta o publique cuando contiene una conexión configurada con credenciales del maker que otros usuarios no están autorizados a reutilizar.
El cambio es importante porque transforma una advertencia en una barrera de despliegue. El análisis de seguridad de Copilot Studio ya señalaba el uso de maker-provided credentials, pero el nuevo ajuste Sharing agents with embedded maker credentials puede bloquear la operación antes de que el agente quede accesible a usuarios finales.
La capacidad está en preview. Microsoft incorporó la configuración a la documentación de Power Platform el 4 de noviembre de 2026 y actualizó la guía de Copilot Studio el 5 de noviembre. No debe tratarse todavía como el único control de acceso ni como sustituto de DLP, autenticación, permisos del sistema de destino o revisión del agente.
Diagrama original. La política no elimina las credenciales del maker: evalúa si la conexión puede reutilizarse y bloquea compartir o publicar cuando infringe la política de uso compartido.
El riesgo que intenta cerrar
Una herramienta puede autenticarse con:
- credenciales del usuario final: cada usuario inicia sesión y la operación se ejecuta con sus permisos;
- credenciales proporcionadas por el maker: todos los usuarios invocan la herramienta mediante la conexión configurada por quien creó el agente.
La segunda ruta es necesaria en algunos procesos desatendidos, pero cambia el límite de autorización. Un usuario podría ejecutar una consulta o acción que su cuenta no permite si la conexión del maker sí tiene esos privilegios.
El nuevo control inspecciona las conexiones utilizadas por el agente. Si una conexión con credenciales del maker no puede compartirse o reutilizarse de acuerdo con la política de la organización, Copilot Studio puede impedir que el agente se comparta con usuarios finales y bloquear su publicación.
No analiza si la respuesta funcional es correcta ni aplica seguridad por registro dentro del sistema remoto. La autorización efectiva sigue siendo la de la identidad que utiliza la conexión.
Qué cambia exactamente
El ajuste se administra desde Power Platform admin center > Security > Threat detection > Sharing agent with embedded maker credentials y admite alcance por entorno o grupo de entornos.
La documentación publica dos opciones:
| Opción | Valor documentado | Resultado |
|---|---|---|
| Don’t let makers share agents with their own credentials embedded | Activada de forma predeterminada y recomendada | Evalúa las conexiones y bloquea compartir o publicar cuando una conexión del maker infringe la política |
| Let makers share agents with their own credentials embedded | Desactivada de forma predeterminada | Permite el uso compartido sin aplicar este bloqueo específico |
El control no declara que todas las conexiones del maker sean inseguras. La decisión depende de la capacidad y política de uso compartido de la conexión subyacente.
No es el mismo control que prohibir credenciales del maker
Power Platform ya dispone de Control maker credential options, que permite decidir si los makers pueden seleccionar credenciales de usuario final, credenciales propias o ambas. Ese ajuste cambia las opciones de autenticación disponibles para todas las herramientas del entorno o grupo.
| Control | Momento | Efecto |
|---|---|---|
| Control maker credential options | Autoría y ejecución | Puede eliminar por completo la opción de credenciales del maker y forzar inicio de sesión del usuario final |
| Sharing agents with embedded maker credentials | Compartir y publicar | Mantiene la posibilidad de configurar credenciales del maker, pero bloquea la distribución cuando una conexión no puede reutilizarse de forma segura |
| Automatic security scan | Antes de publicar | Advierte de configuraciones de riesgo; por sí solo no equivale a una política administrativa de bloqueo |
La diferencia es relevante para agentes autónomos. Prohibir credenciales del maker obliga a que exista un usuario interactivo y puede hacer fallar ejecuciones programadas o en segundo plano. El nuevo control permite conservar ese patrón donde sea necesario, pero impide distribuir un agente cuya conexión no cumpla la política.
Comportamiento durante el ciclo de vida
Al compartir
Cuando la validación detecta una infracción:
- no se puede conceder acceso de visor o usuario final al destinatario afectado;
- tampoco se puede compartir el agente con toda la organización;
- la experiencia de uso compartido muestra un error e identifica el destino afectado.
La documentación no afirma que el control revoque automáticamente accesos existentes. Debe verificarse el inventario y retirarse explícitamente cualquier acceso que ya no sea apropiado.
Al publicar
La publicación también puede bloquearse. Existe un matiz documentado para agentes autenticados:
- un agente que todavía no se ha compartido puede publicar aunque muestre la advertencia;
- si ya está compartido con otro usuario y la política detecta una conexión incompatible, la publicación queda bloqueada;
- cuando el bloqueo se detecta antes de publicar, el botón Publish no está disponible y el maker debe revisar Agent status.
No conviene convertir este matiz en una vía de evasión. Publicar un agente no compartido no autoriza después su distribución ni demuestra que sus conexiones sean seguras.
En Agent status y herramientas
Copilot Studio presenta la infracción en dos niveles:
- warning para un agente autenticado que todavía no se ha compartido;
- critical error cuando el agente ya está compartido.
Las herramientas afectadas aparecen como Blocked con el mensaje Sharing policy violation. Si una herramienta también incumple una política de datos, Copilot Studio muestra primero el mensaje de infracción DLP.
Configuración paso a paso
1. Inventariar agentes y conexiones
Antes de activar o confirmar la política, identifica:
- agentes compartidos o publicados;
- herramientas basadas en conectores, acciones integradas y flujos de Power Automate;
- conexiones configuradas con credenciales del maker;
- propietario, permisos y sistema de destino de cada conexión;
- agentes autónomos que no pueden solicitar un inicio de sesión interactivo.
El inventario debe incluir conexiones heredadas. La ausencia de un aviso en una prueba anterior no demuestra conformidad con la nueva política.
2. Clasificar el patrón de identidad
Para cada herramienta, decide cuál de estas rutas es correcta:
| Patrón | Cuándo usarlo | Control principal |
|---|---|---|
| Usuario final | La operación debe respetar los permisos individuales | End-user credentials, autenticación del agente y acceso al sistema de destino |
| Identidad técnica controlada | Proceso autónomo o compartido con permisos deliberadamente acotados | Cuenta o identidad dedicada, mínimo privilegio, rotación y monitorización |
| Credencial personal del maker | Prototipo temporal | Evitar en producción; sustituir antes de compartir |
Una conexión personal no se convierte en identidad de servicio por estar embebida en un agente.
3. Configurar el entorno o grupo
- Accede a Power Platform admin center con permisos administrativos.
- Abre Security > Threat detection.
- Selecciona Sharing agent with embedded maker credentials.
- Elige la pestaña Environment groups o Environments.
- Selecciona el grupo o entorno objetivo y pulsa Set up.
- Activa Don’t let makers share agents with their own credentials embedded.
- Guarda la configuración.
La documentación no publica un tiempo de propagación específico para este nuevo control. Incluye una espera y una nueva sesión de autoría en el plan de pruebas, en lugar de asumir aplicación inmediata.
4. Corregir las infracciones
La solución preferida, si la herramienta lo admite, es cambiarla a end-user credentials. Cada usuario crea o autoriza su propia conexión y la acción se ejecuta con sus permisos.
Si el escenario requiere ejecución autónoma:
- comprueba si la conexión admite una identidad técnica compartible;
- reduce los permisos al conjunto mínimo de operaciones y datos;
- separa agentes de prueba y producción;
- evita cuentas personales y propietarios únicos;
- documenta renovación, baja, monitorización y recuperación de la identidad;
- vuelve a validar Agent status antes de compartir y publicar.
No todas las herramientas admiten ambos modos de credenciales. La documentación no promete una conversión automática.
Arquitectura de defensa en profundidad
Este control debe formar una capa más del modelo de seguridad:
- autenticación del agente para identificar al usuario;
- límites de sharing para decidir quién puede usar o editar el agente;
- política de credenciales para impedir una delegación no autorizada de la identidad del maker;
- DLP para controlar combinaciones de conectores y movimiento de datos;
- permisos del sistema destino para limitar datos y acciones reales;
- auditoría y monitorización para detectar invocaciones anómalas.
La política de credenciales no compensa un conector con permisos excesivos. Tampoco garantiza que una acción de escritura sea idempotente, que exista aprobación humana o que la salida no exponga información sensible.
Seguridad y gobierno operativo
- Usa grupos de entornos para aplicar una regla coherente a desarrollo, prueba y producción, pero prueba el impacto antes de extenderla.
- Asigna propietarios alternativos y elimina conexiones vinculadas a makers que abandonan el equipo.
- Revisa las conexiones tras importar soluciones o cambiar herramientas del agente.
- Incluye una prueba negativa: un maker no debe poder compartir ni publicar un agente deliberadamente no conforme.
- Conserva evidencia del estado de la política y de Agent status para el proceso de release.
- No habilites la opción permisiva como corrección rápida de un bloqueo; corrige primero la identidad y los permisos.
Licenciamiento y disponibilidad
La función está documentada como preview y su interfaz puede cambiar. Microsoft no anuncia un SKU nuevo ni un cargo por activar el control. Siguen aplicándose las licencias de Copilot Studio, conectores, Power Automate y sistemas externos utilizados por el agente.
La documentación confirma configuración por entorno o grupo de entornos, pero no publica una matriz completa de regiones, nubes soberanas ni compatibilidad por tipo de harness. Valida el control en el tenant y harness concretos antes de incorporarlo como requisito obligatorio de producción.
Limitaciones conocidas
- Es una capacidad preview y no debe ser el único control de seguridad.
- Solo afecta a conexiones que usan credenciales del maker; las conexiones de usuario final siguen su propio flujo de autenticación.
- La conexión subyacente determina si puede compartirse o reutilizarse.
- Un agente autenticado y no compartido puede publicar con una advertencia; el bloqueo de publicación aparece cuando la distribución y la conexión entran en conflicto.
- DLP puede ocultar el mensaje de sharing con una infracción de política de datos más prioritaria.
- Microsoft no documenta una API, cmdlet o propiedad de solución para automatizar este ajuste.
- No se publica una garantía de retroactividad sobre accesos ya concedidos.
- No todas las herramientas permiten cambiar a credenciales del usuario final.
Matriz mínima de pruebas
| Caso | Configuración | Resultado esperado |
|---|---|---|
| Conexión de usuario final | Herramienta con end-user credentials | Compartir y publicar no se bloquean por esta política |
| Conexión del maker permitida | Conexión reutilizable conforme a la política | Distribución permitida |
| Conexión del maker no compartible | Agente sin compartir | Warning en Agent status; validar el matiz de publicación |
| Conexión del maker no compartible | Agente compartido | Critical error y publicación bloqueada |
| Compartir con un usuario | Conexión infractora | Error para el destinatario |
| Compartir con toda la organización | Conexión infractora | Operación bloqueada |
| Infracción DLP simultánea | Conector bloqueado por DLP y sharing | Se muestra la infracción de política de datos |
| Agente autónomo | Cambio a end-user credentials | Ejecución sin usuario debe fallar de forma controlada |
Recomendación práctica
Mantén activa la opción recomendada en nuevos entornos y conviértela en una validación de release. Antes de aplicarla a gran escala, clasifica los agentes autónomos y sustituye credenciales personales por identidades técnicas gobernadas o por conexiones del usuario final.
El valor del cambio no está solo en impedir un clic de publicación. Introduce un punto de control entre la identidad con la que se ejecuta una herramienta y la audiencia a la que se entrega el agente. Ese punto debe formar parte del diseño, no aparecer como sorpresa al final del despliegue.