Copilot Managed Runtime (I): todo por un clic

ℹ️ En colaboración con Ana Estigarribia

Un día cualquiera de trabajo.

Un maker abre Copilot Studio, y ahí está, ese botón nuevo que dice ‘Aplicación’, enviando un mensaje a su subconsciente, «pincha, pincha, pincha», y al final… pues pincha, total… «¿qué puede salir mal?»... Y de paso se lo cuenta a otros makers.

Ese mismo día, la persona responsable del gobierno de Power Platform (si es que en la organización existe ese perfil), accede al centro de administración y…¡SORPRESA! Los entornos de desarrollo personal (PDE) se han reproducido por arte magia.

¿El resultado? 🚨PANIC ON : «¿De dónde ha salido todo esto?». 

Pero… ¡que no cunda el pánico! Admins, ¡pasen y vean! ¡Demos la bienvenida a Copilot Managed Runtime (CMR)! Vamos por partes…

¿Qué es Copilot Managed Runtime?

Copilot Managed Runtime, o CMR, actualmente en preview, es la plataforma administrada por Microsoft sobre la que se alojan y ejecutan las nuevas aplicaciones administradas. Estas aplicaciones utilizan la identidad de Microsoft Entra, están sujetas a las políticas de gobierno del tenant y aparecen en el inventario de aplicaciones del centro de administración de M365 (MAC) y en el inventario de recursos del de Power Platform (PPAC) para que puedan supervisarse y gestionarse.

Donde los makers ven una experiencia sencilla para construir una aplicación, los admins ven una nueva superficie que deben gobernar. Porque detrás de esa experiencia aparentemente sencilla aparecen identidad, entornos, routing, conectores, servidores MCP, políticas de datos, uso compartido, capacidad, consumo e inventario. Ahí es donde entra CMR.

Estas aplicaciones deben crearse dentro del marco de gobierno de la organización, de modo que el equipo administrador pueda aplicar controles y mantener una visión centralizada. Para ello, CMR comprueba una serie de medidas de gobierno y, si no están configuradas en el tenant, aplica una configuración predeterminada. Pero ¿se ajusta esa configuración a las necesidades de tu organización?

Microsoft pone una base; nosotros seguimos teniendo que decidir quién puede crear, dónde lo hará, qué podrá utilizar y cuánto estamos dispuestos a consumir (porque no es gratis).

Así que si somos la persona encargada de administrar la plataforma, nos surgirán preguntas como:

• «¿Permitimos el botón Aplicación en Copilot Studio?»

• «¿Qué ocurre realmente después de que alguien lo pulse?»

• «¿Cómo vamos a incorporar esto a nuestro modelo de gobierno?»

Bueno, pues preparad la lupa y vamos a buscar esas respuestas.

Distintas puertas de entrada, un mismo runtime

Nuestro maker del ejemplo solo pulsó un botón en Copilot Studio. ¿Eso es todo? Pues no, porque tenemos varios puntos de entrada para crear estas aplicaciones: Cowork, Copilot Studio, Copilot Code y SDK/CLI de CMR. Todas estas vías convergen en el CMR. El maker crea su aplicación desde uno de esos puntos de entrada y a partir de ese momento, la plataforma tiene que decidir dónde va a construir. Y el lugar elegido es: su Personal Developer Environment (PDE).

Volviendo a nuestra escena inicial: los PDE no se habían reproducido por arte de magia.

Detrás estaba Environment Routing haciendo de las suyas.

Environment Routing: de un clic a un PDE

Llegados a este punto puedes preguntarte: «¿Por qué se activa en enviroment routing si no lo hemos habilitado en nuestro tenant?»

Si al pulsar el botón el maker ya tiene un PDE, se reutiliza. Si no, la plataforma aprovisiona uno nuevo siguiendo las reglas de Environment Routing de la organización, y si no las has configurado, automáticamente se activa una regla predeterminada. Estos PDE son entornos administrados y sin Dataverse (se puede añadir después).

Así que nos enfrentamos a dos escenarios:

Si no existen reglas de Environment Routing

Si no hay reglas de Environment Routing, CMR crea una para Everyone, dirige a cada maker a su PDE y aplica el gobierno predeterminado mediante un Environment Group.

Por tanto, no configurar Environment Routing no implica que no exista routing, sino que se usa el definido por Microsoft. Puede ser válido, pero debe asumirse conscientemente: la regla para Everyone solo puede eliminarse tras configurar otra con el mismo scope.

Si ya existen reglas de Environment Routing configuradas

Si ya habías hecho los deberes y tenías configurado el environment rounting en tu tenant, CMR conserva las reglas existentes, su prioridad y los Environment Groups de destino. Cuando un maker coincide con una regla, crea o reutiliza su PDE en el grupo correspondiente. Si no coincide con ninguna, no se crea su PDE y no podrá crear aplicaciones administradas hasta quedar cubierto por una regla.

El gobierno que viene de serie

CMR incorpora un gobierno predeterminado desde el primer momento. Las aplicaciones heredan una política que controla con qué pueden conectarse, hasta dónde pueden compartirse y cómo se comportan durante su ejecución. Este gobierno se aplica junto con las políticas de Power Platform que ya tenga configuradas la organización, no las sustituye.

El baseline se basa en cuatro reglas:

Routing

Determina quién obtiene un PDE, a qué Environment Group se dirige y qué reglas hereda.

El routing sitúa al maker, las demás reglas definen qué puede hacer.

Conectores y servidores MCP

Una Advanced Connector Policy (ACP) que se aplica al Environment Group que se crea por defecto, establece una lista predeterminada de conectores y servidores MCP de Microsoft que las aplicaciones pueden utilizar.

Aquí hay un matiz importante: permitir un conector no significa permitir todas sus acciones. Algunas acciones como realizar peticiones HTTP, ejecutar scripts o invocar determinadas operaciones de plataforma, permanecen bloqueadas aunque el conector esté permitido, aunque un administrador puede controlar tanto los conectores disponibles como las acciones concretas que pueden ejecutar las aplicaciones.

Así que pregúntate: ¿Necesitamos el conector completo o solo algunas acciones?

Sharing

La regla de sharing define para el Environment Group si los makers pueden compartir las aplicaciones dentro de la organización y con invitados. Los valores por defecto son:

• Cualquier persona en la organización puede abrir la aplicación a través del vínculo compartido

• Deshabilitado para usuarios invitados

  
  

Y un punto muy importante. Compartir una aplicación no concede acceso automático a los datos que utiliza: son permisos independientes. Para que una persona pueda usarla, también debemos gestionar su acceso a esos datos.

Content Security Policy

La Content Security Policy (CSP) controla desde dónde carga recursos la aplicación y dónde puede integrarse. El baseline restringe scripts, imágenes, fuentes, conexiones, formularios y contenido embebido, aunque un administrador puede autorizar orígenes concretos.

La CSP admite dos modos:

• Enforced: bloquea los recursos que incumplen la política.

• Report-only: no los bloquea, pero informa de cuáles rechazaría.

  
  

Report-only permite evaluar el impacto antes de bloquear y evita que un cambio mal ajustado interrumpa la aplicación.

Y hasta aquí la parte I: nos quedamos con makers que pueden construir aplicaciones administradas dentro de un perímetro gobernado sin que un administrador defina todo desde cero.

Pero recuerda, el gobierno predeterminado no tiene por qué ser el más adecuado para tu organización. Optar por mantenerlo tal cual, es en sí misma una decisión de gobierno, pero esa decisión la toma el producto por nosotros.

Continuará…