Power Platform Agent Authentication Governance Reaches GA: What to Audit First

An IT administrator reviewing an agent identity and access governance dashboard on a large office monitor

A CISO at a mid-market manufacturer asked her Power Platform admin a simple question last month: how many Copilot Studio agents does the organization actually have running, and how many of them require anyone to prove who they are before they can use them? The admin came back three days later with a spreadsheet of 214 agents. Nineteen had “No authentication” configured. Four of those nineteen had access to a knowledge source containing vendor contract terms. Nobody remembered turning authentication off for any of them, because nobody had turned it on to begin with. It had simply never been set. That gap is exactly what Power Platform agent authentication governance, which reached general availability this month, was built to close.

Microsoft has been describing this exact scenario in its own guidance for a while. In a February 2026 security post, Microsoft described unauthenticated agents as a recurring pattern rather than an edge case: authentication gets “deactivated for testing, left in its default state, or misunderstood as optional,” and the result is an agent that anyone with a link can use, sometimes surfacing internal information through its topics, actions, or knowledge sources without anyone intending it to. The fix Microsoft has been building toward arrived this month, and it changes who is responsible for catching this problem before it reaches production.

What Power Platform Agent Authentication Governance Actually Does

The feature reached general availability on September 2, 2026, after a public preview that opened in late May. Listed in Microsoft’s release plan as “Manage agent security with enhanced admin controls,” it gives administrators a way to set authentication and access policy for agents centrally, at the environment or environment group level, inside the Power Platform admin center. Rather than relying on individual makers to choose the right authentication setting each time they build or republish an agent, an admin can now require Microsoft Entra ID authentication across a group of environments, permit a defined list of approved external identity providers for agents that genuinely need one, or block anonymous access outright.

The detail that matters most for a governance program is when these policies get enforced. This is not a design-time warning that a maker can dismiss and move past. Microsoft’s own documentation describes the policy as evaluated both when an agent is deployed and again at runtime, so a policy change made after the fact actually reaches agents that are already published, not just new ones being built going forward. That closes a gap that has existed in Copilot Studio governance for a while: DLP data policies could already restrict unauthenticated usage at the tenant level, but that control was blunt. It did not give admins a way to say, for example, that the environment group serving finance requires Entra ID, while a separate environment group hosting a public-facing customer service agent is allowed to run anonymously because that is the intended design.

That distinction is worth sitting with, because the instinct after reading a story like the manufacturer’s spreadsheet is to conclude that anonymous access is always the mistake. It isn’t. A number of legitimate agents, particularly ones embedded in Power Pages sites or public marketing properties, are supposed to be reachable without a sign-in. The problem in most organizations is not that anonymous agents exist. It is that nobody made a deliberate decision about which ones should, and the setting drifted in by default rather than by design.

Abstract illustration of glowing padlock and key icons connected in a network, representing agent identity and access governance

Why This Became Urgent Now

The timing lines up with a broader shift that most IT leaders are already tracking anecdotally even if they haven’t quantified it. Citizen-developer agent creation in Copilot Studio has grown faster than most organizations’ governance processes have kept pace with, and a maker publishing an agent from a template or a quick prototype rarely stops to think about identity architecture. Microsoft’s guidance on securing Copilot Studio deployments at scale describes a zoned model, where agents built by citizen developers are expected to carry the least privilege and the most constrained data access, and where authentication choices become progressively more deliberate as an agent moves toward professional development and broader distribution. Enforcement has lagged the model. Before this release, an admin who wanted to guarantee that zone boundaries actually held had to lean on DLP connector policies and manual audits, neither of which was built specifically to answer the authentication question.

There’s also a compliance dimension that will matter more to some organizations than others. Regulated industries, healthcare, financial services, and any company subject to a SOC 2 or ISO 27001 audit cycle have been fielding questions from auditors about AI agent access controls for a while now, often without a clean answer. A centrally enforced authentication policy, applied at the environment group level and demonstrably active at runtime rather than merely recommended at build time, gives those organizations something concrete to show. It is the difference between telling an auditor that agents are supposed to require authentication and showing them a Power Platform admin center screen where that policy is actually configured and enforced.

What to Audit Before You Roll This Out

The rollout sequence matters more than the feature itself, and getting it backwards creates its own incident. The first step is the one the manufacturer’s CISO already took: get a current inventory of every agent in the tenant and its existing authentication setting, broken down by environment. Most organizations doing this for the first time are surprised by the count, and a meaningful share of that surprise usually comes from test or proof-of-concept agents that were never decommissioned rather than from production systems.

Once the inventory exists, the harder work is deciding environment group boundaries before applying policy, not after. An environment group that mixes internal line-of-business agents with a customer-facing Power Pages chatbot forces an uncomfortable compromise: either weaken the policy to accommodate the anonymous agent or break a legitimate public integration. Splitting those into separate environment groups first, then applying a strict Entra ID requirement to the internal group and an explicit, reviewed exception for the external one, is the pattern that avoids both outcomes.

It is also worth coordinating this rollout with whoever owns DLP policy in the organization, since the two controls now overlap in purpose even though they operate at different layers. A tenant-wide DLP restriction on unauthenticated connector usage and an environment-group-level authentication requirement can either reinforce each other or produce confusing, hard-to-diagnose failures if they are configured without reference to one another. Treating this as a single governance conversation, rather than two separate admin tickets handled by different people, avoids that outcome.

Finally, this is a good moment to revisit whichever Center of Excellence process the organization uses to track agent inventory and ownership, since an authentication policy is only as good as the organization’s ability to know when a new agent shows up outside of it. The policy catches misconfiguration. It does not catch an agent nobody knew existed until the inventory audit runs again.

The Practical Takeaway

None of this requires a large project to act on immediately. A first pass, an inventory of current agents and their authentication settings, a decision about which environment groups genuinely need anonymous access and which don’t, and a staged policy rollout starting with the highest-risk internal environment group, is realistic within a normal sprint or two for most Power Platform admin teams. What changes with this GA release is that the tool for enforcing the decision now exists natively, rather than requiring a workaround built from DLP policies never designed for this specific job.

Routeget Technologies has been walking clients through Copilot Studio governance reviews since well before this feature existed, largely because the underlying problem, agents accumulating faster than anyone tracks their authentication posture, predates any specific Microsoft release. The general availability of centralized agent authentication governance does not solve that problem by itself. It gives the teams already paying attention to it a real lever to pull, and it gives the teams who haven’t started yet a clear, specific reason to.

#CopilotStudio #PowerPlatformGovernance #AgentAuthentication #AIGovernance #EnterpriseAI #DataLossPrevention

Why Your AI Builder Default Model Keeps Changing Without Warning

An IT governance leader reviewing an AI model version timeline on a widescreen office display

A finance team at a mid-size distributor built a Power Automate flow eighteen months ago that reads incoming vendor contracts, pulls out payment terms and renewal clauses with an AI Builder prompt, and routes a short summary to the approver queue. The flow still runs every morning. Approvals still clear. Nobody who built the flow works there anymore, and nobody currently on the team could tell you which language model is actually answering the prompt today. It is not the one that answered it when the flow went live, and there was no meeting, no change ticket, and no line in a release note that told anyone it had changed.

That gap is not a one-off. It is how AI Builder’s generative AI prompts are designed to work, and it is worth understanding before the next swap happens rather than after a downstream process quietly starts behaving differently.

AI Builder’s prompt capability, the “Create text using a prompt” action available in Power Automate and Power Apps, runs on the same Prompt Builder infrastructure Microsoft also surfaces inside Copilot Studio. Unless a maker deliberately pins a specific model, every one of those prompts runs against the AI Builder default model, and Microsoft’s own documentation is explicit that this default is “periodically upgraded as new, more capable models become generally available.” The upgrade happens on Microsoft’s schedule, not the customer’s, and it happens without a change request landing on anyone’s desk.

Why the AI Builder default model keeps changing

The churn is not hypothetical. Microsoft’s published model availability record for Copilot Studio and AI Builder prompts shows GPT-4o and GPT-4o mini retired in July 2025, replaced by GPT-4.1 and GPT-4.1 mini. The o1 reasoning model retired the same month in favor of o3, which was itself retired on December 4, 2025 and replaced by GPT-5 reasoning. As of the current documentation, GPT-4.1 mini is the default model behind AI Builder prompts. Sitting just behind it in experimental status, available in limited regions ahead of a wider rollout, are GPT-5.3 chat, GPT-5.2 reasoning, Claude Sonnet 4.6, Claude Opus 4.6, and Grok 4.1 Fast. Experimental status is where every prior default model spent its final months before becoming the new standard, so this list is a reasonably good preview of what gets promoted next.

This is not even the first time the underlying mechanism itself has changed. The original AI Builder GPT feature, announced in December 2023 on GPT-3.5-Turbo, was itself deprecated in favor of the current Prompt Builder architecture. Teams that built early automation on that first action had to migrate the action type entirely, not just adjust to a new model version answering the same call. The lesson from that history is that the platform underneath these prompts has changed twice already, and there is no reason to assume it stops changing now.

Abstract illustration of glowing spheres arranged in a rotation cycle, representing AI model versions turning over

Thirty days is the entire window

When Microsoft promotes a new default, the model it replaces does not disappear immediately. Documentation for Copilot Studio confirms that a retired model stays usable for up to one month after retirement, and there is a setting, buried under an agent’s Settings page in the Model section, called “Continue using retired models,” that lets a maker keep running the outgoing version during that window while testing against the new one. It is a genuinely useful control. The problem is that it lives inside Copilot Studio’s authoring surface, and most of the people who built and now maintain a production flow in Power Automate or an app in Power Apps have never opened Copilot Studio at all. The setting exists. Whether the person responsible for a given prompt even knows to look for it is a separate question, and for most organizations right now, the honest answer is no.

The practical risk is not that the new model performs worse. Often it performs better on the metrics Microsoft optimizes for. The risk is that a model swap can shift output length, formatting, tone, or how confidently it phrases an uncertain answer, and none of that shows up as an error. A prompt that used to return a clean three-sentence summary might start returning five sentences with a caveat clause, and if a downstream Power Automate step parses that output into a fixed-width field or feeds it into a condition check, the flow keeps running successfully while quietly producing something different from what was tested and signed off.

What bring-your-own-model actually fixes, and where it does not

Microsoft’s answer to this is a real one: since September 15, 2025, AI Builder and Copilot Studio prompts have supported bringing your own model from Azure AI Foundry instead of relying on the shared default. An organization deploys its own model in its own Foundry resource, connects the deployment’s chat completion endpoint inside the prompt editor, and from that point forward it owns the version, the region, and the retirement timeline. Nobody upgrades it out from under them. For a prompt that feeds a regulated process, or one where consistent output structure genuinely matters, this is the correct fix, and it has been generally available for a full year.

It comes with two limits worth knowing before anyone builds a governance policy around it. First, a bring-your-own model connected through Prompt Builder can only be used inside prompt actions themselves. It cannot serve as the primary orchestration and planning model for a Copilot Studio agent, so it solves the AI Builder prompt problem specifically rather than every generative AI surface in the platform. Second, GPT-5-class models are not currently supported for bring-your-own connections at all. An organization that has already standardized its Azure AI Foundry deployments on GPT-5 cannot yet point an AI Builder prompt at that same deployment, which means the newest, often best-governed model choice is precisely the one this workaround does not yet cover.

There is also a licensing wrinkle that changes how a team should think about where a prompt lives in the first place. AI Builder credits are consumed when a prompt runs inside Power Apps or Power Automate, but the same prompt running inside Copilot Studio does not draw down those same credits. Two functionally identical prompts can carry meaningfully different cost profiles purely based on which product surface invokes them, which is easy to miss when a finance team is estimating consumption ahead of a rollout.

The governance moves worth making now

None of this requires a large program to address, but it does require someone to own it deliberately rather than let the platform default apply by omission. Start with an inventory of every production flow or app using a Prompt Builder action, and flag which ones are pinned to a specific model versus riding the default, since only the latter is exposed to the thirty-day retirement clock at all. For anything feeding a regulated, financial, or customer-facing process, evaluate whether bring-your-own-model through Azure AI Foundry is worth the setup cost given its current limits. At the environment level, the Power Platform admin center lets administrators disable the “Preview and experimental AI models” feature and lock that setting tenant-wide through environment group rules, which is a low-effort way to keep makers from quietly adopting an experimental model that has not been through any review. Because AI Builder sits inside the Dataverse connector for data loss prevention purposes, existing DLP boundaries already extend to prompt outputs, so that control is worth confirming rather than assuming.

The technology here is not the risk. A rolling default model, upgraded on a vendor’s schedule with a one-month grace period, is a reasonable design for a platform serving millions of makers. The risk is that most organizations have not assigned anyone to watch that clock. The AI Builder engagements Routeget gets pulled into to troubleshoot rarely trace back to a broken prompt. They trace back to a model decision nobody revisited since the day the flow was built, quietly drifting further from what the business actually validated.

#AIBuilder #PowerPlatformGovernance #CopilotStudio #AIModelGovernance #AzureAIFoundry #EnterpriseAI

Microsoft Agent 365 Governance Is GA. Is Your Copilot Studio Fleet Ready?

IT director reviewing an AI agent governance dashboard on a large office monitor

When a mid-market manufacturer’s IT Director asked her Power Platform administrators for a simple headcount this spring, how many Copilot Studio agents actually exist across the organization, the answer took three weeks to assemble and still arrived with an asterisk. Some agents had been built by finance analysts using maker licenses nobody remembered granting. A handful had default connections into Dataverse tables holding customer payment history. Nobody could say with confidence who owned any of them once the person who originally built them changed teams or left the company. That scramble is becoming a familiar story across Dynamics 365 and Power Platform shops, and it is exactly why Microsoft Agent 365 governance has become a live budget conversation since the platform reached general availability on May 1, 2026.

IT director reviewing an AI agent governance dashboard on a large office monitor

Agent 365 is Microsoft’s control plane for observing, governing, and securing AI agents across an enterprise, regardless of where those agents were built. It applies to prebuilt Microsoft 365 Copilot agents, agents built in Microsoft Foundry, and, most relevant to this audience, agents built in Copilot Studio. For IT Directors and CIOs who have spent the last eighteen months watching Copilot Studio adoption spread from a handful of IT-sanctioned bots into dozens of business-unit-built agents, Agent 365 is the first serious attempt at a single inventory and policy layer that sits over all of it. Whether it is worth the licensing commitment depends less on the feature list and more on how much organizational work a rollout actually requires, which is the part vendor briefings tend to gloss over.

What Agent 365 governance actually covers

The platform’s job splits into three functions: observing agent activity across apps, endpoints, and cloud services; governing agents through policy-based controls and lifecycle management, meaning admins can install, publish, block, or reassign ownership of an agent directly from a central registry; and securing agents against threats such as over-privileged actions or misuse of connected data sources. Microsoft Defender now assesses the security posture of Foundry and Copilot Studio agents specifically, flagging risky configurations, including agents wired up to Model Context Protocol tools that could open a path to privilege escalation, and surfacing prioritized recommendations rather than a raw vulnerability dump.

The governance layer also introduces a formal approval and publication flow. Before an agent built in Copilot Studio reaches end users, an admin can review its data access, permissions, and security posture from the registry, rather than relying on the maker’s own judgment about what the agent should be allowed to touch. For any IT Director who has inherited a Copilot Studio environment where publication controls were an afterthought, this is the feature that closes the gap between having a data loss prevention policy on paper and actually enforcing it before an agent goes live.

One capability worth flagging separately is shadow AI discovery. Agent 365 uses Microsoft Defender and Intune to identify locally running agents on Windows endpoints that were never provisioned through any sanctioned platform. At GA, this covers agents built on the OpenClaw framework, with support for GitHub Copilot CLI and Claude Code agents promised to follow. It is a genuinely new capability, since most governance conversations to date have focused on what happens inside Copilot Studio or Power Platform, not on the coding agents developers are quietly running on their own laptops. That said, it is worth treating Microsoft’s framing of how widespread this problem actually is with some skepticism. The prevalence figures behind the “agent sprawl” narrative are Microsoft’s own positioning, and no independent study has confirmed how common unmanaged local agents really are on a typical enterprise fleet. Before budgeting for this specific control, it is reasonable to ask your own security team whether they have actually observed it as a problem.

The licensing math is per person, not per agent

Agent 365 is priced at $15 per user per month as a standalone add-on, or bundled at no additional cost inside Microsoft 365 E7, which lists at $99 per user per month and also includes the Entra Suite. The billing model is worth understanding precisely: one Agent 365 license covers every agent that person owns, sponsors, manages, or interacts with, so deploying more agents does not by itself increase the license count. You are licensing the humans accountable for agents, not the agents themselves, which is a more forgiving model than the per-seat-per-bot pricing some competitors use.

The complication is prerequisites. As of June 1, 2026, Agent 365 requires a specific underlying license foundation: Microsoft 365 E5 on its own, or E3 combined with both the Defender and Purview suites, with equivalent tiers defined for frontline, SMB, and education licensing. For an organization still running E3 without the add-on security suites, the real cost of Agent 365 is not the $15 line item. It is the E5 upgrade, or the Defender and Purview additions, that have to happen first. Run the math both ways before presenting a number to finance: E5 plus Copilot plus Agent 365 lands around $105 per user, while E7 covers the same ground at $99. For organizations already leaning toward E5 or E7 for other reasons, Agent 365 is close to free. For organizations still on E3, it is a licensing tier change dressed up as a governance purchase, and that distinction changes who needs to sign off on it.

Abstract illustration of a network of AI agents protected within a security shield, representing agent governance

Governance is an operating model, not a toggle

Microsoft’s own internal rollout, described in its IT organization’s implementation notes, is the most useful data point for what a realistic deployment looks like. Microsoft Digital currently manages more than 500,000 agents across its environment, and the team is candid that its operating model is still incomplete. Their starting point was not turning on policy enforcement. It was building an accurate, centralized inventory, capturing each agent’s name, lifecycle status, type, ID, owner, creation platform, and where it is actually used, with the registry auto-ingesting metadata from Copilot Studio, Power Platform, SharePoint, and Azure AI Foundry.

Just as significant is the administrative structure Microsoft settled on. Rather than assigning agent governance to a single owner, the organization split responsibility across an AI administrator role overseeing the full tenant inventory and lifecycle, an Agent Identity administrator managing identities through Entra Agent ID, and security and compliance teams defining the actual guardrails and approval thresholds. Internally, Microsoft describes agent governance as needing a cross-functional weekly rhythm among IT, security, identity, product, and business unit stakeholders, framing it explicitly as a team sport rather than a single admin’s checklist. Notably, the company also acknowledges that much of its own approval and escalation workflow is still manual, and that programmatic automation is an ongoing engineering effort rather than something that ships finished on day one.

For a CIO evaluating Agent 365, the practical takeaway is to separate the licensing decision from the operating model decision. The license question is a spreadsheet exercise: check your current Microsoft 365 tier against the June 2026 prerequisite list, and compare standalone Agent 365 pricing against an E7 upgrade if you are close to that threshold anyway. The operating model question is harder and cannot be solved by procurement. It requires naming an accountable owner for the agent inventory, deciding who plays the Agent Identity administrator role, and establishing the recurring cross-team review Microsoft itself says was the actual unlock, before the count of Copilot Studio agents in your tenant grows past the point where anyone can govern it from memory.

Routeget Technologies has walked several Dynamics 365 and Power Platform clients through exactly this kind of governance stand-up, usually starting with the same inventory exercise that surprised the IT Director in the opening example. The tooling question tends to resolve quickly once the organizational one is answered honestly.

#Agent365 #CopilotStudio #AIGovernance #ShadowAI #AgenticAI #EnterpriseAI

The Dynamics 365 Sales MCP Server Isn’t the Whole Picture

Solution architect reviewing a Dynamics 365 Sales AI agent integration architecture diagram on a monitor

A solution architect on a recent Dynamics 365 Sales engagement did what the documentation told him to do: he pointed a GitHub Copilot session in VS Code at the newly GA’d Dynamics 365 Sales MCP server, asked it to pull up a stalled opportunity, and watched it come back with a clean summary and a suggested outreach email. Then he asked it to update the opportunity’s close date. Nothing happened. No error, no record change, just a polite explanation that the tool wasn’t available. He had connected the right server. He just hadn’t connected both of them.

That gap trips up more than one team standing up agent access to Dynamics 365 Sales for the first time, because the Dynamics 365 Sales MCP server, which reached general availability in February 2026 after a preview that started in mid-2025, was never designed to be the only door into the system. It is a purpose-built layer that exposes a narrow set of sales-specific actions: retrieving a lead summary, qualifying a lead into an opportunity, generating an outreach email, listing leads assigned to a seller. Anything that looks like ordinary create, read, update, or delete work against Dataverse records sits behind a separate, general-purpose Dataverse MCP server. Architecting AI access to Sales properly means treating these as two components of one system, not as interchangeable options.

What the Dynamics 365 Sales MCP server actually exposes

The Sales MCP server groups its tools into three functional clusters that mirror existing Copilot experiences inside the app: Sales Qualification Agent tools, Sales Opportunity Agent tools, and the broader Copilot in Sales tool set. In practice this means an MCP client authenticated against this server can list a seller’s leads, pull a structured summary of a specific lead or opportunity, move a qualified lead into an opportunity record, and draft or send an outreach email using the same generative logic that powers Copilot inside the Sales workspace. These are opinionated, workflow-shaped actions. They encode the same business rules a seller would hit clicking through the UI, which is exactly the point: an external agent gets sales-process guardrails for free instead of raw table access.

What it deliberately does not expose is a general write path. There is no “update any field on any opportunity” tool here, and that is not an oversight so much as a design choice that keeps the blast radius of an agent request contained to well-understood sales actions.

Where Dataverse MCP fills the gap

For anything outside that workflow shape, whether it’s a custom Power Apps process reading a related quote table or an agent that needs to write directly to a Dataverse entity, the connection point is the separate Dataverse MCP server, reachable at https://<OrgURL>/api/mcp. It exposes four core operations: read_query, create_record, update_record, and describe, the last of which lets a client inspect table and column schema before it attempts a write, which matters a great deal in a Dataverse environment where customizations can mean the “standard” schema an agent expects has drifted from what is actually deployed.

One detail worth building into any design review: the Dataverse MCP server is enabled by default for Microsoft Copilot Studio but disabled by default for every other client. If a team is connecting GitHub Copilot, a custom agent, or any third-party MCP-compliant tool, an admin has to go into the Power Platform admin center, open the target environment’s Settings, navigate to Product > Features, and turn on “Allow MCP clients to interact with Dataverse MCP server,” then explicitly allow-list each client under Advanced Settings. Nothing connects by accident, which is a reasonable default for a capability that can write to production data, but it also means a “why isn’t this working” support call is often really a “did anyone flip this switch” question.

Abstract illustration of two connected server nodes representing the Sales MCP server and Dataverse MCP server architecture

Configuring both servers side by side

For a VS Code or other mcp.json-driven client, the practical setup is two separate server entries pointed at two different endpoints rather than a single unified connection string. The Sales server entry targets the Agent 365 service path scoped to the environment and the Sales MCP server registration, something like https://agent365.svc.cloud.microsoft/mcp/environments/<EnvironmentID>/servers/msdyn_SalesMCPServer, while the Dataverse entry targets the organization’s own API surface directly. Both are declared as HTTP-type MCP servers. Getting an agent to feel like it has coherent access to “Dynamics 365 Sales” as a single system is really a matter of configuring both endpoints correctly and letting the client route each request to the appropriate one, which most MCP-aware clients handle transparently once both connections are live.

It’s worth noting explicitly for architects scoping this work that Claude Desktop is not on Microsoft’s list of supported clients for the Sales MCP server as of this writing; Copilot Studio, GitHub Copilot in VS Code, and other MCP-compliant clients are. That’s a constraint worth confirming before a client commitment gets made in a statement of work.

Security enforcement isn’t a separate layer, it’s the same one

The question every security-conscious stakeholder asks first is whether an AI agent connected through MCP can see or touch more than the person who authorized it could. Microsoft’s own documentation is direct on this point: the Dataverse MCP server respects existing Dataverse security roles and row-level security, meaning a connected agent can only access the tables and records that the authenticated user’s security role already permits. There is no parallel permission model to reason about, no separate access control list to maintain for agent traffic. The security model an organization has already built for its human users through business unit hierarchies, field-level security, and role-based table access extends automatically to MCP-connected agents acting on that user’s behalf. That’s a meaningfully simpler governance story than a lot of teams expect walking into this, and it’s worth stating plainly to a CISO who assumes agent access requires a whole new access-control project.

What isn’t yet documented in detail is rate limiting or granular audit logging specific to MCP calls, and that’s a fair gap to flag rather than paper over. Teams putting this into production should validate logging behavior in their own tenant and treat detailed throttling behavior as something to test empirically rather than something to design around from a published number that doesn’t exist yet.

The licensing detail that changes the cost conversation

Since December 15, 2025, Dataverse MCP tool calls made by AI agents built outside Microsoft Copilot Studio are billed against Copilot credits, unless the organization already holds qualifying Dynamics 365 Premium licensing or a Microsoft 365 Copilot User Subscription License, in which case that usage is included. Agents built inside Copilot Studio are exempt from this particular charge model. The Sales MCP server has its own credit consumption structure layered on top, with different tool categories, such as basic text and generative AI tools versus generative answer tools, billed at different Copilot Studio credit rates. For an architecture that mixes a Copilot Studio-native agent with a custom VS Code-based developer tool hitting the same environment, that means two different cost models are running in parallel, and a licensing conversation that used to be a single line item now needs to account for which client is making which call.

What to check before this goes into a proposal

Confirm which specific tools a client actually needs before assuming both servers are required. A workflow that only needs lead qualification and outreach drafting may never need Dataverse MCP write access at all, which simplifies both the security review and the licensing conversation considerably. Where write access genuinely is required, treat the admin center toggle and client allow-listing as a discrete deployment step with its own change ticket, not an assumed side effect of installing an MCP client. And build the Copilot credit cost of both servers into a pilot’s budget from day one, since credit consumption for generative tools scales with usage in a way that a fixed per-seat license does not.

Teams at Routeget Technologies have walked several clients through exactly this two-server design decision over the past few months, mostly because the documentation, while accurate, spreads the full picture across three or four separate Learn pages that don’t obviously reference each other. Getting the architecture right the first time saves a rework cycle that otherwise shows up a few weeks into a pilot, right around the point someone asks the agent to actually change a record instead of just describing one.

#DynamicsSalesMCP #DataverseMCP #AIinCRM #CopilotStudio #EnterpriseAI #D365SalesArchitecture

Embedding Copilot Studio Agents in Power Pages: Why Authentication Comes First

A solution architect reviewing a web portal authentication architecture diagram with a chat interface panel on a monitor in a modern office

A solution architect building an external vendor portal in Power Pages gets asked, midway through the project, to add “a chat assistant that can actually answer supplier questions using our own data.” The instinct is to treat this as a UI task: drop in a chat component, point it at Copilot Studio, ship it by Friday. That instinct is the wrong one, and the mistake rarely surfaces on day one. It shows up three weeks later, when the agent works fine for logged-in partners but loops anonymous visitors through a login prompt they were never supposed to see, or when someone in security asks who approved the delegated permissions an agent is now holding on behalf of every anonymous site visitor. The single decision made when adding an agent to a Power Pages site, specifically which authentication model it runs under, quietly determines how it behaves for anonymous users, how much session state it shares with the rest of the portal, and how much rework is waiting the first time that same agent gets published to Teams or Microsoft 365 Copilot alongside the portal. Embedding Copilot Studio agents in Power Pages got considerably more capable in March 2026, and the expanded capability came with a wider set of ways to get the underlying architecture wrong.

A solution architect reviewing a web portal authentication architecture diagram with a chat interface panel on a monitor in a modern office

The Mechanics of Embedding Copilot Studio Agents

Power Pages has offered some form of Copilot-powered chat for a while, but the March 2026 updates changed what that actually means. Microsoft’s own Power Platform blog describes two related capabilities: an Agent API that lets a site’s own custom code build a tailored chat experience against a Copilot Studio agent rather than accepting the default widget, and expanded support for embedding any Copilot Studio agent, using any authentication type the platform supports, directly into a site through the setup workspace. That second piece matters more than it sounds. Previously, a site’s chat experience was tied fairly closely to a narrow generative-answers configuration. Now a maker can either let Power Pages provision a default site agent automatically, or attach a custom agent that was built and tuned independently in Copilot Studio, complete with its own topics, connectors, and orchestration logic.

The setup workflow itself is short. From Power Pages’ setup workspace, under AI Assistance, a maker toggles Site agent on and a generative-answers agent gets created automatically, or selects Add agent to bring in an existing custom one. Either way, the agent then needs web roles assigned before it becomes visible to any site visitor, the same mechanism Power Pages already uses to gate pages and forms. Multiple agents can coexist on one site, each scoped to a different role: a public FAQ agent open to anonymous traffic, say, alongside a case-lookup agent restricted to authenticated partner accounts. Before any of this works, a tenant admin has to enable the “Publish Copilots with AI features” setting in the Power Platform admin center, and the environment’s HTTP connector can’t be blocked, since the agent relies on HTTP nodes to communicate with the site.

The Authentication Fork That Shapes Everything Downstream

Here is where the real architectural decision sits. A default site agent, the one Power Pages provisions automatically, runs on generic OAuth 2 authentication with token pass-through by default. Practically, that means it inherits whatever identity providers the site already has configured, works for anonymous visitors without additional setup, and can tailor its answers based on a visitor’s web role with no extra configuration required. For a straightforward FAQ or knowledge-lookup agent, this is genuinely the easier path, and it is the one most teams will land on without thinking hard about it.

A custom agent added from Copilot Studio, on the other hand, can use any authentication type Copilot Studio itself supports, including direct Microsoft Entra ID authentication rather than the site’s own identity provider. That flexibility exists because some agents need to do more than answer questions from a knowledge source; a topic might need to call back into Dataverse, an external API, or another Microsoft 365 service using a token that carries the visitor’s own delegated permissions. Microsoft’s guidance frames this as a choice between an “Authenticate with Microsoft” option, simple to configure but without token access for topics, and an “Authenticate manually” path that enables token pass-through at the cost of setting up the OAuth registration and scopes correctly.

This is also the point where community reports, appropriately treated as anecdotal rather than confirmed platform behavior, start to matter for planning purposes. A recurring complaint in practitioner discussions is repeated login prompts appearing when a site’s own session and the agent’s authentication flow diverge, often traced back to a token exchange configuration that assumes a session the agent can’t actually see. It is a testable problem, not an unfixable one, but it is the kind of thing that is far cheaper to catch in Copilot Studio’s own testing pane, which now supports validating both the conversation and the authentication flow together, than to discover after a portal has gone live for external users.

Abstract illustration of a glowing padlock merging with a chat bubble and network nodes, representing secure AI agent authentication

Governance Multiplies Across Channels

The authentication decision doesn’t stay contained to Power Pages for long. An agent built once in Copilot Studio is frequently published to more than one surface: the portal, a Teams channel, possibly the Microsoft 365 Copilot app as well. Each channel can carry a different authentication context, which means a topic’s logic that checks for a delegated token, something like a User.AccessToken value, may find it present in one channel and absent in another. A topic written and tested only against the Power Pages experience can behave inconsistently the moment the same agent gets reused somewhere else, and that inconsistency tends to surface as a support ticket rather than a caught bug.

Practically, this argues for treating an embedded agent as a governed asset from the moment it is scoped to more than one channel, not as a Power Pages feature that happens to also work elsewhere. That means a named owner spanning the Copilot Studio author, the Power Pages maker, whoever administers identity for the tenant, and security, rather than assuming the person who built the topic also understands every channel’s authentication quirks. It also means treating the security surface honestly: an agent with broad delegated scopes, reachable from an anonymous-facing portal, is a more attractive target for OAuth consent-phishing style attacks than an internal-only agent would be, and the mitigations worth reviewing (narrower scopes, existing DLP policies, and in higher-sensitivity cases, a backend token-brokering pattern instead of direct client-side pass-through) are worth deciding on before launch, not after an incident review.

What to Confirm Before You Flip the Switch

A few items are worth confirming explicitly rather than assuming. First, decide the authentication model on purpose: the default token pass-through is fine for a lookup-and-answer agent, but anything calling back into Dataverse or another system with delegated permissions needs the manual path, planned for from the start rather than retrofitted. Second, map web roles to agents before enabling anything, since an agent provisioned without a clear role assignment can end up more broadly visible than intended. Third, use Copilot Studio’s own testing capability to validate the authentication flow itself, not just conversation quality, since that is now possible in one place rather than requiring a separate round of manual portal testing. Fourth, budget for consumption: agents provisioned through Power Pages start in a trial period and convert to capacity-based Copilot Studio billing once that period ends, drawing from the same quota pool used by every other Copilot Studio agent in the tenant, so a busy public-facing agent can compete with internal ones for capacity if nobody planned for it.

None of this makes embedding an agent in a Power Pages site a bad idea. It makes it an architecture decision rather than a component you drop onto a page, which is really the same lesson every other Power Pages capability with a security dimension has already taught: the web role model, the table permission model, and now the agent authentication model all reward being decided deliberately in week one. At Routeget, the Power Pages engagements that add agent-powered assistance now start with a short authentication and governance workshop before a single topic gets built, precisely because that conversation is inexpensive early and considerably less so after a portal is already live for external users.

#PowerPages #CopilotStudio #PowerPlatform #AgentAuthentication #PortalGovernance #EnterpriseAI

Copilot Studio Harness Billing: The Free Pilot Period Just Ended

Finance director reviewing cost dashboards for Copilot Studio agent billing

A finance team at a mid-size distributor spent the summer letting two developers experiment with autonomous agents in Copilot Studio: one to triage vendor invoices, another to reconcile shipping exceptions against purchase orders. Nobody logged the hours. Nobody tracked the credits, because there were none to track. Then, on September 1, 2026, Copilot Studio harness billing changed for exactly this kind of pilot, and both agents started drawing against the tenant’s Copilot Credit pool without a single line of configuration having moved. The invoice for October will look different than the one for September, and the person who approves it may have no idea why.

This is not a hypothetical. Microsoft’s own admin guidance for this change tells organizations to go looking for agents they may have forgotten existed, which is a reasonable ask only if someone already knows to look. For CIOs, CFOs, and IT directors who greenlit a handful of “let’s just see what this can do” pilots earlier in the year, the practical question is no longer whether Copilot Studio’s most capable harness is worth adopting. It is whether the agents already running under it are quietly becoming a budget line nobody planned for.

What Copilot Studio harness billing actually changed on September 1

Copilot Studio ships three distinct harnesses, and the distinction matters more than most licensing conversations acknowledge. A harness, in Microsoft’s own framing, is the runtime layer that sits between an agent’s design and the underlying model: it decides when to call the model, what to hand it, how to interpret what comes back, and which tools to invoke on the agent’s behalf. The Standard harness is deterministic. It follows predefined topics and prompts and behaves the same way every time, which is exactly what you want for a help desk bot answering a known set of questions. The Copilot Chat harness is narrower still, built to ground Microsoft 365 Copilot Chat in an organization’s own content for internal, employee-facing scenarios.

The GitHub Copilot harness is a different animal entirely. It reasons autonomously toward a goal rather than following a script, breaks a task into steps on its own, retries and reroutes when something fails, and can read, edit, and reason over Word, Excel, PowerPoint, and PDF files as part of completing a task. It also supports skills and persistent memory, and runs in a secure sandbox designed for multi-step business processes: an accounts payable agent that reads an invoice, matches it to a purchase order, and routes an exception is the kind of thing Microsoft built this harness to handle. It reached general availability on August 3, 2026, and from that date forward, the billing model was unambiguous: authoring, testing, and evaluating an agent all consume Copilot Credits, not just its published, end-user traffic. The meter starts the moment someone starts building.

What was less obvious is what happened to agents and workflows that existed before that date, built during an earlier preview window when this kind of usage did not consume credits at all. Microsoft’s answer arrived on September 1: those pre-GA agents and workflows, including anything sitting in a Dev or Trial environment, now consume Copilot Credits too, for both the ongoing authoring work a maker does on them and their runtime execution. Standard harness and Copilot Chat harness agents are unaffected. This is specifically about closing the gap between agents that got a free head start during preview and the GA billing model everyone built after August 3 has already been living under.

Why this is a governance problem before it is a cost problem

The credit economics themselves are not exotic once you understand them. Copilot Credits can be drawn from prepaid capacity, priced at roughly $200 per month for 25,000 credits, or purchased pay-as-you-go through an Azure subscription at $0.01 per credit, a rate that runs about 25 percent higher than the prepaid tier. Microsoft’s admin tooling in the Power Platform admin center lets you set a monthly consumption ceiling per agent, with two guardrails: a notification as usage approaches the limit, and a hard stop that disables the agent once it’s reached. Overages beyond an agent’s allocation can either draw from a shared tenant pool or bill against a linked pay-as-you-go plan, and a monitoring dashboard shows month-to-date billed credits per agent alongside a twelve-month trend.

Laptop screen showing an administrative usage and credit consumption dashboard

None of that is the hard part. The hard part is that the September 1 change makes cost visibility retroactive for a category of agent that, by design, was never supposed to need it. A pilot built in July to test whether autonomous reasoning could handle exception routing was, at the time, a genuinely low-stakes experiment. Nobody assigned it an owner with a mandate to monitor consumption, because there was nothing to consume. That agent may still be running today, quietly reprocessing the same exceptions it was built to test, and as of this month it is drawing against the same credit pool as anything built deliberately for production. Multiply that by however many “quick pilot” agents a mid-size enterprise typically accumulates across finance, HR, and operations teams over six months, and the exposure is not a single line item. It is an unknown number of them, some of which may not even have an active business owner anymore.

What to check before the next invoice arrives

Microsoft’s own recommendation is a reasonable starting point: pull historical, non-billed Copilot Credit consumption data from the Power Platform admin center to understand what these agents were actually doing before billing applied to them, and use that history to identify which GitHub Copilot harness agents and workflows exist across every environment, including the Dev and Trial environments that pilots tend to live in and get forgotten in. That inventory step matters more than it sounds like it should, because Dev and Trial environments are exactly where governance attention typically does not reach; they are treated as sandboxes precisely because nothing in them used to cost money.

Once that inventory exists, the decision for each agent is binary and should be made deliberately rather than by default. An agent that proved its value during the pilot period should be formally adopted: given an owner, a consumption ceiling with both guardrails enabled, and a place in whatever ALM process governs production agents. An agent that was built to answer a question that has already been answered, or that nobody has looked at since July, should be retired outright rather than left running under the assumption that “it’s probably fine.” The cost of leaving a stale pilot alive is no longer zero, and the credit allocation and access controls that make sense for a small number of intentional, production-grade autonomous agents do not scale gracefully to an undefined number of forgotten ones.

There is a broader lesson in how this rolled out. Microsoft made the GA billing model clear from day one for anything built after August 3, and it gave organizations a full month, not a surprise cutover, before extending that model backward to preview-era agents. That is a fair way to manage a transition. But it also means the responsibility for knowing which agents exist and what they’re doing sat with each tenant the entire time, and plenty of tenants were not positioned to carry it. As autonomous, credit-metered agents become a bigger part of how Dynamics 365 and Power Platform environments get extended, the organizations that treat agent inventory and consumption governance as a standing discipline, not a one-time reaction to a billing announcement, are the ones that won’t be surprised by the next change like this one. Routeget Technologies has been walking clients through exactly this kind of Copilot Studio environment audit over the past several weeks, and the pattern holds: the agents nobody remembers building are almost always the ones costing the most to leave running.

#CopilotStudio #AgenticAI #GitHubCopilotHarness #CopilotCredits #ITCostGovernance #EnterpriseAI

Configuring the Scheduling Operations Agent in Dynamics 365 Field Service

Field Service dispatcher reviewing an AI-generated schedule optimization on a control room display with map routes

A dispatcher watching a Field Service schedule board on a Tuesday afternoon knows the pattern well. A technician calls in sick, three appointments need to move, and the promised arrival windows on two of them are already tight. The old workflow is manual triage: scan the board, check who’s nearby, check who has the right certification, and start dragging bookings around while the phone keeps ringing. Microsoft’s answer to that specific moment is the Scheduling Operations Agent, and as of this month it’s rolling out wider public preview capability inside Dynamics 365 Field Service, built to sit on top of Resource Scheduling Optimization rather than replace it.

For technical teams supporting Field Service deployments, the agent is worth understanding now, before it reaches general availability in March 2027 and before dispatchers start asking why their schedule board has a Copilot side pane suggesting changes. This is a configuration and tuning guide aimed at the people who will actually turn it on: solution architects and Field Service administrators who need to know what it touches, what it costs, and where it will quietly produce bad suggestions if the underlying data isn’t clean.

What the Scheduling Operations Agent Actually Does

Standard Resource Scheduling Optimization has existed in Field Service for years as a batch engine: define a scope of resources and requirements, set objectives like minimizing travel time, and let the solver produce a schedule. The Scheduling Operations Agent extends that same underlying optimization logic into two modes that behave very differently in practice.

Interactive optimizations run in the moment. A dispatcher selects one or more resources from the schedule board, the resource list, or the Copilot side pane, and the agent proposes a revised schedule for just those resources, ready for review before anything is applied. This is the mode built for the sick-technician scenario: fast, scoped, and reversible. Batch optimizations are closer to classic RSO, asynchronous runs across a defined scope, goal, and plan, with results either reviewed before applying or applied automatically depending on how the plan is configured. The agent can also be scheduled to run on a recurring basis, which matters for organizations that want a standing overnight optimization pass rather than only reactive adjustments.

What makes this an agent rather than a scheduling report is the layer that interprets what the dispatcher is asking for through natural language in the Copilot pane, and then translates that into a scope, a goal, and a set of objectives and constraints under the hood. The optimization math is the same solver logic Field Service has used for RSO; what’s new is the interface and the ability to trigger narrow, ad hoc runs without building a saved schedule first.

Field Service dispatcher reviewing an AI-generated schedule optimization proposal on a schedule board with a map view

Prerequisites and Licensing That Change the Rollout Math

Before enabling anything, confirm the environment is on Field Service version 8.8.133.214 or later and Universal Resource Scheduling 3.12.149.15 or later, with location and map settings turned on. The feature itself is off by default and gets enabled from Resources, then Scheduling Parameters, then Resource Scheduling, then the Agents tab, where a single toggle turns on both interactive and batch optimizations together. There’s no way to enable one mode without the other, which is worth flagging to a dispatch manager who might want to pilot only the batch side first.

The part that catches architects off guard is billing. Unlike the RSO add-in, which runs as part of the Field Service license, the Scheduling Operations Agent consumes Copilot Studio messages, and those are billed separately through either prepaid capacity purchased as a message pack in the Microsoft 365 admin center, or pay-as-you-go consumption tied to an Azure subscription linked to the Power Platform environment. Both models can run side by side in the same environment, with prepaid capacity drawn down first. A single optimization request consumes messages roughly in proportion to how many resources are included in the run, so a dispatcher who gets in the habit of running interactive optimizations against ten technicians at a time burns through capacity noticeably faster than one running narrow, two-or-three-resource adjustments. Anyone budgeting a rollout should treat message consumption as an operating cost line item, not an afterthought, and set up consumption alerts in the Power Platform admin center before dispatchers get access.

Security Roles and Data Access

Two new security roles govern the feature: Scheduling Operations Agent Administrator, which allows creating, editing, and deleting scopes, goals, and plans, and Scheduling Operations Agent User, which allows running optimizations and viewing results. Administrators typically get the first role, dispatchers the second, and both need a standard Field Service dispatcher role layered on top for baseline access to scheduling tables. There’s a detail here that’s easy to miss during setup: the agent itself runs as an application user inside a Scheduling Operations Agent Team, and that team needs security roles matching what dispatchers have, including any field security profiles in play for column-level security. Skip that step and the agent will silently fail to see the fields it needs to evaluate, producing incomplete or nonsensical suggestions with no obvious error pointing back to the permissions gap.

Tuning Goals, Objectives, and Booking Statuses

Getting useful output out of the agent depends heavily on configuration work that has nothing to do with the agent itself and everything to do with how the environment’s scheduling data is set up. Every booking status needs an explicit optimization method: Optimize for bookings that can be moved or deleted, Do Not Move for anything in progress or with a committed arrival time, and Ignore for canceled bookings the agent should be free to write over. Leave a status unconfigured and it defaults to Do Not Move, which quietly limits what the agent can touch without anyone deciding that on purpose. The same discipline applies to priority values: every priority needs a numeric value from 1 to 100, and Microsoft’s own guidance is to keep the range narrow and distinguishable, something like 1 for low, 10 for medium, and 100 for emergency, rather than spreading values across extremes that cause the solver to fixate on emergency work at the expense of everything else. Notably, the agent ignores the Level of Importance field entirely, so any organization that has been using that field as a proxy for priority needs to migrate that logic into Priority Value before expecting sensible results.

On the goal side, the practical approach is to start narrow: a small resource set, a short time range, and a plan set to review-before-apply rather than auto-apply, so nothing changes on the live schedule while weights are being tuned. Objectives like completing more high-priority work, reducing travel time, and minimizing idle time each take a weight, and the temptation to crank one objective far above the others produces exactly the failure mode you’d expect, schedules that chase priority scores while generating long drives and large idle gaps between bookings. Microsoft’s own tuning guidance recommends starting with similar weights, changing one at a time, and comparing runs before widening scope. That iterative loop, not a one-time configuration, is what actually determines whether dispatchers trust the suggestions enough to keep using the tool past the first week.

Solution architect configuring scheduling optimization goals and constraints in a Dynamics 365 Field Service admin interface

Where It Still Breaks

The agent works online only, with no offline fallback, and prompt detection in the Copilot pane has been tested in English, so multilingual dispatch teams should verify language support before rolling this out broadly rather than assuming parity with other Copilot experiences. Large batch optimizations that pull in thousands of open requirements will run slower and are more likely to hit truncation limits, so requirement views scoped by territory or skill group consistently perform better than one broad query covering the whole operation. And because the agent still respects promised time windows over Do Not Move status, a booking locked to protect it can still get removed if its promise window has already expired, which is a nuance worth documenting for dispatchers who assume “locked” means permanently untouchable.

None of this makes the Scheduling Operations Agent a plug-and-play replacement for dispatcher judgment, and Microsoft is explicit that it’s preview functionality not intended for production reliance yet. What it does offer, for teams willing to do the configuration work now, is a testable path toward faster same-day rescheduling without waiting for the next major RSO batch run. Routeget Technologies has been walking Field Service clients through exactly this kind of pre-GA configuration work, mapping booking status and priority data into a state the agent can actually reason about before the March 2027 general availability date arrives and dispatch teams are expected to already know how it behaves.

#FieldServiceDispatch #SchedulingOperationsAgent #ResourceScheduling #DynamicsFieldService #CopilotStudio #AgenticAI