Case Management Agent Shadow Mode Won’t Save You From the Credit Bill

Customer service operations analyst reviewing AI case prediction dashboards

A Dynamics 365 Customer Service admin at a mid-size insurer recently asked a reasonable question in a planning meeting: if Case Management Agent can draft responses and reclassify inbound support email on its own, why not just turn it on for one team and watch what happens? The answer, as it usually is with autonomous case handling, is that “watching what happens” after the agent has already sent a reply or changed a case status is not watching, it’s cleanup. Case Management Agent shadow mode exists specifically to close that gap, and it reached general availability in May 2026. What it does not do is make that validation free, and the fine print around it is messier than the release notes suggest.

Shadow mode lets a case update rule generate everything Case Management Agent would normally act on: the identified customer intent, a drafted response, proposed field updates, and a recommended resolution path, without sending a single email or writing a single change to a live case. Administrators and CSR managers get a dedicated shadow results view where they can open a case, see what the agent would have done, and compare it against what a human agent actually did. That comparison is the entire point: it turns “we think the AI is ready” into a defensible, case-by-case answer before anyone flips the switch on autonomous handling for a whole queue.

Customer service operations analyst reviewing AI case prediction dashboards

What Case Management Agent Shadow Mode Actually Validates

The mechanics matter more than the marketing description. Shadow mode is enabled per case update rule, not per agent, per queue, or per line of business. On the Case creation and update page, under Case update by AI agent (any channel), you select an individual rule and choose Shadow mode from the toolbar; the rule’s status changes accordingly. That granularity is a feature and a trap in the same breath. It means you can pilot the agent’s behavior on a narrow slice of traffic, say, billing inquiries routed through one specific rule, without touching anything else. It also means that if your case management setup has a dozen rules covering different email types, languages, or business units, validating the agent properly means walking through each rule on its own rather than assuming one clean test covers the whole configuration.

Once a rule is running in shadow mode, reviewers pull up results through Review shadow runs, which surfaces old and new values side by side, grouped by case, with each case expandable to show every shadow response tied to it. For a technical team, this is genuinely useful data: you can see not just whether the agent’s classification matched reality, but whether its drafted response tone, its proposed field updates, and its resolution recommendation would have held up. That level of visibility is a meaningfully higher bar than most organizations apply before turning on any AI-driven automation, and it’s worth using deliberately rather than as a two-day formality before go-live.

The Cost Nobody Budgets For

Here is the detail that gets lost between the release plan bullet point and the actual rollout plan: shadow mode consumes Copilot or AI credits in exactly the same way live predictions do. Running a rule in shadow mode for three weeks across a meaningful volume of cases is not a free dry run, it is a second production workload layered on top of whatever else is drawing from the same consumption pool. Teams that budgeted AI credits for the automation itself, and treated validation as a rounding error, are the ones who get an uncomfortable surprise on the Azure bill partway through a pilot.

There’s a licensing prerequisite tied to this that’s easy to miss during a proof of concept. Shadow mode, like the broader autonomous case agent framework it belongs to, requires the Power Platform pay-as-you-go plan with Azure subscription consumption-based billing already configured. If your organization is running Dynamics 365 Customer Service on a standard licensing model without PAYG enabled, shadow mode is not a checkbox you flip in an afternoon. It’s a procurement and finance conversation that needs to happen before the technical team can even start the guided setup for Case Management Agent, which is itself a prerequisite for shadow mode to appear as an option at all.

Technology professional reviewing side-by-side data validation comparison on screen

A GA Feature Microsoft’s Own Documentation Still Calls Preview

This is the part worth flagging directly rather than glossing over. The 2025 release wave 2 plan lists shadow mode’s general availability date as May 2026, and it has been publicly available since then. But the current administrator documentation for enabling it states plainly that shadow mode “is a preview feature and isn’t meant to be used in production environments,” and ties usage to Microsoft’s supplemental terms of use for preview features rather than standard product terms. That is not a minor wording inconsistency. For a regulated organization (an insurer, a bank, a healthcare provider) the difference between a GA feature and a preview feature governs what a compliance or vendor-risk team will actually sign off on, and which support commitments apply if something goes wrong.

There are two ways to read this gap. One is that Microsoft’s release-plan GA date refers to the feature’s availability in the product, while the standing administrator guidance simply hasn’t been updated to match, which would not be the first time a fast-moving Copilot feature outpaced its own documentation. The other is that shadow mode genuinely still carries preview-level support and terms regardless of what the release plan says, and the GA label refers only to it no longer requiring a preview opt-in toggle. Neither interpretation is confirmed by anything Microsoft has published, and a team relying on shadow mode’s output to justify a production automation decision should treat that ambiguity as a real governance question, not a documentation typo to shrug off.

Pairing Shadow Mode With the New Classification Features

Shadow mode is most useful right now paired with the classification capabilities Microsoft shipped alongside it. Email classification into administrator-defined categories reached general availability on April 10, 2026, letting Case Management Agent tag inbound email based on subject and body content before anything downstream (unified routing, Automatic Record Creation rules, Power Automate flows, or reporting) ever touches it. That expanded into a full taxonomy of categories and subcategories on August 21, 2026, giving organizations a hierarchical structure instead of a flat list.

The practical implementation sequence follows from how much of the platform now depends on that category value. Because routing rules, ARC logic, and reporting all key off the classification attribute, a wrong category assignment doesn’t just mislabel one email, it can misroute a case, trigger the wrong automation, or quietly skew the metrics a supervisor is using to staff a queue. Running the classification rule in shadow mode first, and specifically checking whether the predicted category and subcategory match what a human agent would have assigned, is a more honest test of readiness than checking whether the agent’s drafted response reads well. A well-written response built on a wrong classification is still a routing failure waiting to happen.

What to Check Before You Rely on This

Before treating shadow mode results as sufficient sign-off, confirm three things. First, that the security role doing the review actually has CSR Manager or Customer Service Representative access, since the shadow results view isn’t exposed to every role by default. Second, that the guided setup for Case Management Agent has been completed correctly upstream, because shadow mode inherits whatever intent recognition and field-update logic that setup produced; a poorly configured agent will look exactly as unreliable in shadow mode as it would in production, which is the point, but only if the setup itself was done right. Third, that whoever owns the Azure consumption budget knows shadow mode is running and for how long, since a validation period with no defined end date is how credit consumption quietly becomes a permanent line item instead of a bounded pilot cost.

None of this argues against using shadow mode. It’s a genuinely better validation mechanism than most organizations had access to a year ago, and comparing predicted actions against real agent behavior on live cases is a far more honest test than a sandbox demo with curated examples. The point is that GA here does not mean settled. It means the feature works as described, the cost model is real rather than theoretical, and the documentation hasn’t caught up to tell you clearly which rules apply. Teams that have gone through a Dynamics 365 Customer Service rollout before recognize this pattern: the technical capability usually arrives before the governance conversation around it is finished, and treating the two as separate workstreams from the start avoids finding out the hard way which one was actually the bottleneck. This is the kind of gap Routeget Technologies typically catches during a pre-rollout technical review, before a client’s compliance team finds it first.

#CaseManagementAgent #DynamicsCustomerService #ServiceModules #AIGovernance #CopilotCredits #EnterpriseAI

Document Intelligence 4.0 Gave AI Builder Table Confidence Scores. Most Invoice Models Still Can’t Use Them.

Finance analyst reviewing an AI-extracted invoice line-item table with confidence indicators on a laptop screen

A Dynamics 365 Finance implementation team building an automated three-way match workflow ran into a strange gap last month. Their AI Builder model pulled line items off vendor invoices cleanly enough, quantities, unit prices, and extended amounts all landing in the right columns, but the confidence score field meant to flag shaky extractions for human review came back empty for every table row. The fields around the table had confidence values. The table itself did not. Nobody on the team had touched the model’s configuration since it went into production eight months earlier, so the assumption was a bug, or maybe a licensing issue. It was neither. It was a decision made on day one, buried in a dropdown most builders click past without a second thought: whether the model was trained as a Fixed Template document or a General document.

That distinction matters more than it used to, because AI Builder table confidence scores quietly became a real capability when Microsoft folded Azure AI Document Intelligence 4.0 into the document processing model, and that upgrade behaves differently depending on which training path a model took.

Finance analyst reviewing an AI-extracted invoice line-item table with confidence indicators on a laptop screen

What Document Intelligence 4.0 Actually Changed

Microsoft moved AI Builder’s document processing engine onto Azure AI Document Intelligence 4.0 in stages, with public preview starting December 12, 2024 and general availability landing April 30, 2025. For a lot of Dynamics 365 and Power Platform teams, that rollout came and went without much fanfare, since existing models kept working exactly as before. The upgrade wasn’t a forced migration. It was closer to a set of new tools sitting behind the same interface, available to anyone building or rebuilding a model from that point forward.

The practical additions are worth knowing because they change what’s realistic to automate. OCR accuracy improved, particularly on dense or low-quality scans, the kind that come off a fax gateway or a photographed receipt rather than a clean PDF. Layout detection got better at handling documents where content shifts position from one vendor to the next. Signatures became a taggable field type in their own right, not just background noise the model had to work around, which opens the door to processing signed contracts, lease agreements, and approval forms in ways the older engine handled poorly. And confidence scoring extended down to the table level: individual cells, not just whole fields, can now carry a numeric value a flow or canvas app can act on.

That last point is where the invoice team’s gap came from.

The Model Type Decision Behind AI Builder Table Confidence Scores

AI Builder’s document processing wizard offers three starting points: Fixed Template documents, General documents, and an option to extend the prebuilt Invoices model with custom fields. Fixed Template is built for layouts that don’t move, the same vendor sending the same invoice format every time, and it trains fast because the model only has to learn a small set of positions rather than reason about structure from scratch. General documents is built for the opposite case, varied formats, inconsistent layouts, documents that might come from dozens of different sources, and it trains more slowly because it has to learn structural patterns rather than fixed coordinates.

Here’s the part that doesn’t show up until you go looking for it: table and cell-level confidence scores are only available on models trained as General documents. A Fixed Template model can absolutely extract a table, and it can extract it accurately, but it will not return a confidence score for that table’s cells. Field-level confidence outside of tables works normally on both training types. It’s specifically the table data, line items, schedules, itemized charges, where the gap shows up.

For an accounts payable automation scenario built around Dynamics 365 Finance or Business Central, this is not a minor footnote. Line-item extraction is usually the whole point. A header field like vendor name or invoice total is easy to validate against a purchase order regardless of confidence scoring, but line-item quantities and unit prices are where a bad OCR read causes a real financial error, and they’re exactly the data a human-in-the-loop review queue needs a confidence threshold to triage. A team that chose Fixed Template because their vendor’s invoice format never changes gets faster training and solid extraction, but loses the one signal that would tell them which rows need a second look before they hit the general ledger.

Signatures Change What’s Worth Automating

The signature field type deserves its own mention because it shifts the category of documents worth running through AI Builder at all. Before Document Intelligence 4.0, a signed document was something the model either ignored or occasionally misread as stray marks corrupting a nearby field. Now a signature can be tagged, detected, and reported on as a discrete extraction result, true or false, with its own bounding box.

That matters for scenarios well outside invoice processing. A Project Operations team processing subcontractor agreements can now confirm programmatically whether a returned PDF actually carries a signature before routing it into an approval flow, rather than relying on someone opening every file. A procurement team validating vendor onboarding paperwork gets the same benefit. It’s a narrow capability, but it removes a manual verification step that previously had no automated equivalent in AI Builder at all.

Abstract 3D grid of data cells representing table confidence scoring in AI Builder document processing

Migrating an Existing Model Without Starting Over

Teams running an older model built before the Document Intelligence 4.0 rollout are not required to rebuild from zero to get these capabilities, and the upgrade path is more forgiving than the version number might suggest. According to Microsoft’s own documentation, re-tagging every training document is only necessary if you’re adding new fields, checkboxes, tables, or signature detection that the original model didn’t have, or adding new documents to a collection. If the goal is simply to move an existing, working set of tagged fields onto the newer engine, editing and republishing the model carries the upgrade forward without forcing a full retagging pass.

That’s a lower bar than most people assume when they hear “new model version,” so the practical blocker for most teams isn’t technical effort. It’s the training-type decision made at the start, which can’t be changed after the fact. There’s no toggle that converts a Fixed Template model into a General documents model in place. If table confidence scores turn out to matter after production models are already live, the fix is a genuine rebuild, tagging documents again under the General documents path, not a settings change.

Getting Confidence Scores Into an Actual Review Workflow

Once a model is trained the right way, pulling confidence values into something a human reviewer or a flow can act on is straightforward. In a canvas app, a formula like First(FormProcessor1.Results.'Table 1').Amount.Confidence returns the score for a specific cell, and that value can drive conditional formatting, flag rows below a chosen threshold in red, or filter a gallery down to only the extractions that need eyes on them. In a cloud flow, the Extract Information from Documents action exposes the same values through dynamic content, which makes it possible to branch a flow so that high-confidence invoices post automatically while anything below the threshold routes to an approval step in Teams or a shared queue.

Setting that threshold is more art than science. Microsoft doesn’t publish a universal number, because the right cutoff depends on the cost of an error against the cost of unnecessary review. A finance team automating high-dollar vendor invoices will reasonably set a stricter threshold than a team processing low-value expense reports, and it’s worth running a batch of real historical documents through the Quick Test tool before committing to a number, since that’s where the actual confidence distribution for your document set becomes visible rather than theoretical.

Before You Build the Next One

The rebalancing lesson here isn’t that General documents is always the right choice. Fixed Template models train faster, tend to hit high accuracy sooner with fewer sample documents, and remain the right call for genuinely stable, single-format use cases where table validation isn’t part of the workflow. The mistake is making the training-type decision without knowing it also decides whether confidence scoring will be available on table data later, and finding that out only after a review process built around those scores comes up empty.

Anyone scoping a new document processing model, or auditing one already in production, should treat this as a five-minute check worth doing now rather than a surprise found in eight months. If line-item or table-level confidence scoring is part of the plan, even a future plan, General documents is the only path that supports it, and that has to be decided before the first sample document gets tagged.

At Routeget Technologies, this is the kind of gap we look for early in an automation build, not because the underlying capability is complicated, but because a wrong assumption made in a five-minute setup screen tends to surface eight months later, in production, exactly when it’s most expensive to fix.

#AIBuilder #DocumentIntelligence #InvoiceAutomation #AccountsPayableAutomation #PowerPlatform #EnterpriseAI

Dynamics 365 Copilot Capacity Budgeting Just Lost Its Calendar

A finance director and IT director review a cloud service capacity dashboard on a boardroom screen

A finance director we work with spent most of August putting together next year’s Copilot capacity budget for Dynamics 365 Sales the way her team always had: pull the spring release wave notes, pull the fall ones once they land, estimate how many new agent-driven features will touch the message pool, and set a prepaid capacity number that should hold until the next twice-yearly review. On August 25, that whole planning ritual stopped making sense. Microsoft announced it was retiring the release wave model entirely, and with it the predictable calendar that Dynamics 365 Copilot capacity budgeting has quietly depended on since agent-based features started billing by consumption instead of by seat.

If your organization runs Sales Qualification Agent, Sales Opportunity Agent, Sales Close Agent, or Recommended Actions Agent inside Dynamics 365 Sales, this is not a housekeeping change you can skim past. Those agents draw against the same shared Copilot Studio message capacity as every other AI feature on your tenant, and the mechanism Microsoft used to signal “new capability incoming, plan accordingly” just went away.

What Microsoft actually changed

For years, Dynamics 365, Power Platform, and Dataverse published a Release Wave 1 plan in the spring and a Release Wave 2 plan in the fall, each one a large, dated document listing what was coming and roughly when. Microsoft’s August 25 announcement folds all three product lines into the AI at Work roadmap, a single continuously updated destination that already covered Microsoft 365 Copilot and other AI capabilities. New features now get published individually, as soon as a plan is committed and ready to share, rather than batched into one of two annual releases. Each item on the new roadmap carries a status: In Development, Rolling Out, or Launched, and organizations can filter the view down to the products they actually run.

The transition runs through the back half of 2026. Existing release plan content with a preview or GA date of June 1, 2026 or later is migrating onto the new roadmap between September and November. The old Release Planner tool retires on November 15, 2026, though Microsoft says the historical plans will stay archived on Learn for reference rather than disappearing outright. Functionally, this means there will be no Dynamics 365 2026 release wave 2 as a discrete document. Capabilities that would have shipped under that banner are instead appearing on the AI at Work roadmap as they become ready, which for a CIO or IT director used to scanning one document twice a year is a meaningfully different rhythm to plan around.

Abstract illustration of a digital capacity gauge filling as streams of data particles flow into it

Why Sales Qualification Agent makes this concrete, not abstract

The reason this matters more for Sales and Customer Insights teams than for most other parts of Dynamics 365 is billing mechanics. Sales Qualification Agent, which researches inbound leads against a defined target customer profile and, in its research-and-engage mode, autonomously sends outreach and evaluates BANT criteria before handing qualified leads to a seller, does not bill per seat. Neither do its siblings. All four of the consumption-based Sales agents draw down Copilot Studio messages, the same billing unit Microsoft uses across its agent portfolio, and message consumption scales with how complex each interaction is rather than with how many users are licensed.

That capacity is purchased two ways, and most enterprise tenants end up running both at once. Prepaid capacity comes as message pack subscriptions bought through the Microsoft 365 admin center or a partner, assigned to a Power Platform environment, then linked to the Dynamics 365 Sales environment that will actually consume it. Pay-as-you-go billing charges for whatever gets used beyond that, provided the tenant has an Azure subscription linked to Power Platform. Prepaid capacity is always drawn down first, with pay-as-you-go picking up the overflow, and when both run dry the AI capabilities simply stop working. Dynamics 365 Sales does send in-app notifications as quota runs low, but by the time a seller notices Sales Qualification Agent has gone quiet, the qualification and outreach work it was doing has already stalled.

The detail that should worry a budget owner more than the billing model itself is that this message capacity is shared across the entire Power Platform environment, not ring-fenced for Sales. If your Customer Service team turns on a new Copilot capability, or someone in IT stands up an unrelated agent in the same environment, it draws from the identical pool that Sales Qualification Agent depends on to keep researching and engaging leads. Under the old wave model, at least you knew twice a year, in one document, roughly what new capacity-hungry features were about to land across the whole product family and could size your purchase accordingly. Under the always-on model, that visibility has to be built by your team instead of handed to you on a schedule.

What changes in Dynamics 365 Copilot capacity budgeting

None of this means the AI at Work roadmap is worse information than the old release plans. If anything, seeing individual features move through In Development, Rolling Out, and Launched stages in near real time is more accurate than a document that was often stale within a few months of publication. What changes is the operating rhythm your finance and IT teams need around it. A capacity budget that gets set once or twice a year and left alone until the next wave review was already a rough approximation. Now that the calendar cue for “review it again” is gone, treating capacity planning as a periodic project rather than a standing operational discipline will let gaps accumulate quietly until a quota depletion notice arrives at an inconvenient moment.

The practical fix is to move ownership of Dynamics 365 Copilot capacity budgeting from an annual or semi-annual planning exercise to a monitored, recurring process, and to assign it explicitly rather than assuming it falls out of the old wave cycle by habit. The Power Platform admin center already shows Copilot Studio message capacity and consumption at the environment level, and pay-as-you-go usage can be tracked and bounded with spending limits in Azure Cost Management. Neither tool is new. What is new is that nobody is going to hand you a twice-yearly reminder to go look at them.

Three changes are worth making before the Release Planner actually shuts down in November. First, subscribe to the AI at Work roadmap’s filtered view and RSS feed for the specific products your tenant runs, rather than relying on someone remembering to check a bookmark that no longer gets updated on a predictable schedule. Second, replace the biannual capacity review with a monthly or quarterly one, sized to how quickly your Sales, Service, and any other Copilot-consuming teams are actually adding agent capability, since a tenant running only Sales Qualification Agent has a very different burn rate than one that has also turned on Recommended Actions Agent and a Customer Service copilot in the same environment. Third, make sure whoever owns the Azure Cost Management budget for Power Platform pay-as-you-go spend is the same person, or is at least in the same room, as whoever owns the Dynamics 365 Sales rollout plan, because the two decisions are now effectively one decision made in two different admin portals.

We’ve helped clients rebuild exactly this kind of monitoring cadence after a licensing or capacity surprise forced the issue, and it is far less painful to set up deliberately than to reconstruct after an outage. The underlying lesson from Microsoft’s roadmap change is not that anything about Sales Qualification Agent or its sibling agents got worse. It is that a planning habit built around a fixed calendar just lost its calendar, and the tenants that notice first will be the ones that already treat capacity as something to watch continuously rather than something to budget for twice a year and forget.

#DynamicsSales #CopilotCapacity #SalesQualificationAgent #PowerPlatformGovernance #AIatWorkRoadmap #EnterpriseAI

Power Platform Connector Certification Just Got Faster. Your DLP Policy Still Has a Gap It Doesn’t Close.

An IT governance leader reviewing a connector security and data classification dashboard in a modern office

An IT Director at a mid-size manufacturer recently found herself trying to explain, in a security review, why the company had eleven custom connectors feeding Copilot Studio agents and Power Automate flows, and why only three of them could be governed with any real precision. The other eight sat in a tenant-level policy bucket, classified by a URL pattern someone had written eighteen months earlier, long before anyone imagined an agent would be reading from that endpoint autonomously. Nobody had done anything wrong. The tooling simply hadn’t caught up to how fast custom connectors were multiplying once agentic AI entered the picture.

That gap between what Microsoft’s first-party and certified connectors can be governed with, and what a homegrown custom connector can be governed with, has existed for years. It matters more now because Copilot Studio agents lean heavily on custom connectors to reach line-of-business systems, and every one of those connectors is a new surface for a data loss prevention (DLP) policy to either control precisely or wave through by default. Microsoft’s overhaul of Power Platform connector certification, now routed through Partner Center, is worth a close look, not because it makes publishing easier (though it does), but because of what certification actually changes about how a connector can be governed afterward.

The governance gap custom connectors created

Power Platform’s DLP model treats connectors in three tiers: Business, Non-Business, and Blocked, with a rule that data can’t move between a Business-tier connector and a Non-Business one in the same flow or app. Certified and Microsoft first-party connectors slot cleanly into that model at the environment or tenant level. Custom connectors do too, technically, but the mechanics are cruder. At the environment level, an admin classifies each custom connector individually by name. At the tenant level, classification runs on URL pattern matching against the connector’s host address, using ordered allow and deny rules that end in a wildcard catch-all. It works, but it asks a governance team to maintain URL pattern lists by hand, and it treats a connector’s trustworthiness as a function of its address rather than anything Microsoft has actually reviewed.

Advanced Connector Policies (ACP), the newer and stricter allowlist model Microsoft has been rolling out for tenant-wide connector governance, makes the distinction sharper. ACP applies to certified connectors. Custom connectors and HTTP-based connectors, including the generic HTTP connector and HTTP Webhook triggers that many home-grown integrations depend on, are explicitly not supported in ACP as of this writing and still require classic DLP policies or connector endpoint filtering. In practice, that means a company standardizing on ACP for its governed estate is, by definition, leaving its custom connectors in a separate, less rigorous governance lane, no matter how business-critical those connectors have become.

What actually changed in Power Platform connector certification

Microsoft’s new certification pathway moves connector and Copilot plugin submissions into Partner Center, tied to enrollment in the Microsoft 365 and Copilot program. The prior process required manual review that partners reported taking two to five weeks, with limited visibility into where a submission stood or what specifically had failed if it was rejected. The Partner Center path automates the review, gives submitters real-time status and error detail, and covers four scenarios: new custom connectors built in Power Automate, version upgrades to already-certified connectors, custom connectors paired with an associated Copilot plugin, and version upgrades to that paired combination.

Once certified, a connector stops being a homegrown artifact and becomes a standard connector in Microsoft’s catalog. It shows up in the same list as first-party connectors in Power Automate, Power Apps, and Logic Apps, and if it has an associated plugin, that plugin becomes available for admins to enable through the Microsoft Admin Center for Copilot for Microsoft 365. For an enterprise that built an internal connector purely to reach an ERP or CRM system from a Copilot Studio agent, and never intended to publish it externally, this is the detail that matters most: certification is not only a go-to-market lever for ISVs, it is a path out of the custom connector governance lane described above.

Illustration of a digital padlock connecting through a certification gateway, representing connector certification and security governance

What certification does, and does not, fix

It would be a mistake to read this as Microsoft closing the governance gap entirely, and a CIO evaluating whether to push a critical connector through certification should go in with accurate expectations. Certification moves a connector into the standard three-tier DLP classification that Business and Non-Business connectors already use, replacing the name-based or URL-pattern approach reserved for custom connectors. That is a genuine improvement in precision, and it makes a connector eligible for ACP’s stricter allowlist model instead of being permanently excluded from it.

What certification does not do is retroactively fix the connectors an organization decides not to certify, and it does not extend ACP support to HTTP or HTTP Webhook connectors, which remain governed under classic DLP regardless of certification status elsewhere in the estate. A company with a mixed environment, some certified connectors under ACP and a long tail of custom and HTTP connectors under classic DLP, is still running two governance models side by side. Certification narrows that split. It does not eliminate it.

There is also a real cost to weigh. Certification requires standing up a Partner Center account, completing verification materials, and enrolling in the Microsoft 365 and Copilot program, none of which is a five-minute administrative task. For a connector built and used entirely inside one business unit with no reuse potential, that overhead is unlikely to pay for itself. For a connector that a dozen teams route sensitive financial, HR, or customer data through, or one that sits underneath a production Copilot Studio agent making autonomous decisions, the calculus is different.

Deciding which connectors are worth the investment

The practical question for an IT Director or CIO is not whether to certify every custom connector in the tenant. It is which ones justify the enrollment overhead and the ongoing maintenance of keeping a certified version current as the underlying API changes. Three characteristics are worth screening for. First, does the connector back a Copilot Studio agent or automated flow that acts on data without a human reviewing every step, since that is precisely the scenario where blunt, address-based DLP classification is riskiest. Second, is the connector reused across more than one business unit or environment, since URL-pattern tenant policies were never designed to express nuance across multiple consuming teams with different data sensitivity needs. Third, does the connector touch data categories, financial reporting, payroll, customer records, that already sit under stricter internal data handling policy, where a coarser custom-connector classification is a harder position to defend in an audit.

Connectors that fail all three tests, a one-off integration built by a single team for an internal utility with no agent dependency, probably do not need to go through Partner Center at all. The classic DLP tools, applied deliberately rather than left on default settings, are adequate for that tier. Where the calculus shifts is in exactly the kind of estate the manufacturer’s IT Director was trying to defend: a small number of connectors that carry disproportionate risk because of what they connect to and what increasingly autonomous agents do with that access.

Where this fits in a broader governance plan

None of this replaces the fundamentals. A tenant that has not yet adopted DLP custom connector parity, the capability that lets custom connectors be classified individually rather than only by URL pattern, should do that first, since it is available today at no additional cost and requires no Partner Center enrollment. Certification is the next step up for the specific connectors where individual classification still is not precise enough, and where eligibility for ACP’s allowlist model is worth the administrative investment.

Routeget Technologies has walked several clients through exactly this kind of connector inventory exercise, mapping which integrations sit behind agentic workflows and which ones are candidates for certification versus tighter classic DLP rules. The pattern that keeps showing up is not that organizations have too many custom connectors. It is that almost none of them have ever been ranked by actual risk, which is what makes the certification decision harder than it should be. Microsoft has removed the excuse that certification takes too long. The remaining work, deciding which connectors actually warrant it, is squarely a governance decision, not a technical one, and it belongs on the same review calendar as any other access control question in an increasingly agent-driven Power Platform estate.

#PowerPlatformGovernance #CustomConnectors #DataLossPrevention #CopilotStudio #EnterpriseAI #ConnectorCertification

Copilot Studio MCP Server Authentication Isn’t a Checkbox. It’s a Governance Decision.

Solution architect reviewing an authentication and identity security dashboard on a large monitor, representing Copilot Studio MCP server authentication decisions

Copilot Studio MCP server authentication looks like a minor setup screen right up until it isn’t. A solution architect wires a custom MCP server into a Copilot Studio agent during a proof of concept, picks API key authentication because it takes ten minutes to configure, and moves on to the parts of the demo that actually need attention. Six weeks later the same agent is heading into a security review before production rollout, and the reviewer asks a question the architecture can’t answer: which specific user pulled which record through that tool call last Tuesday. With API key auth, the answer is nobody, or rather, everybody, because the key authenticates the connection, not the person using it. The rebuild that follows isn’t a settings change. It’s a different authentication architecture, registered with a different set of Entra ID app registrations, and it usually lands in the same week the go-live date was supposed to be locked.

This is a pattern worth naming because Copilot Studio MCP server authentication makes the wrong choice look reasonable in the moment. When you connect an agent to a custom Model Context Protocol server, whether that server exposes an ERP system, a proprietary data warehouse, or an internal API nobody else has touched, the platform hands you three authentication paths with almost no friction between them: none, API key, and OAuth 2.0. Only one of those paths gives you per-user identity, auditability, and the kind of least-privilege access that a governance team will actually sign off on. Picking correctly the first time saves a rebuild; picking correctly also means understanding a few implementation details that the onboarding wizard doesn’t surface until something breaks.

Solution architect reviewing an authentication and identity security dashboard on a large monitor, representing Copilot Studio MCP server authentication decisions

What Copilot Studio MCP Server Authentication Actually Offers

When you add a custom MCP server as a tool through the agent’s Tools page, using either the MCP onboarding wizard or a Power Apps custom connector built from an OpenAPI schema, Copilot Studio asks you to pick an authentication type for that connection. “None” skips authentication entirely, which is fine for an internal sandbox and indefensible for anything touching production data. API key authentication sends a static credential in a header or query parameter, and every user of the agent shares that same credential. It’s fast, it works, and it’s the reason so many pilots quietly graduate into unauditable production integrations: nobody revisits an auth decision that isn’t currently causing a visible problem.

OAuth 2.0 is where the real architecture decision sits, and Copilot Studio actually gives you three variants of it, not one. Dynamic Discovery is the simplest to configure on the Copilot Studio side, but it depends on the MCP server supporting OAuth 2.0 Dynamic Client Registration with a discovery document, so the burden shifts to whoever builds the server. Dynamic mode supports DCR without a discovery mechanism, which means you supply the authorization and token URLs by hand but the client still registers itself with the identity provider. Manual configuration is the fallback most teams end up using with an existing enterprise identity provider like Microsoft Entra ID: you supply a client ID, client secret, authorization URL, token URL, refresh URL, and optional scopes, and Copilot Studio generates a callback URL that has to be registered with that identity provider before the connection will work.

The reason Manual OAuth 2.0 is worth the extra setup time is the delegation model underneath it, not the configuration effort itself. Done correctly, the MCP server acts on behalf of the signed-in user rather than as an anonymous service account, which means access is bounded by what that specific person is entitled to see and every call can be traced back to an identity. That’s the difference between an integration a Center of Excellence team can approve and one it has to escalate.

Building the Delegated Flow Correctly

The Manual OAuth path requires two separate Entra ID app registrations, and skipping this distinction is where most first attempts go wrong. The first registration belongs to the MCP server itself, configured as an OAuth 2.0 resource server: you expose an API on that registration, set an Application ID URI, and add a scope such as access_as_user that supports both admin and user consent. The server’s own configuration then needs the tenant ID, client ID, and that scope so it can validate incoming tokens and, if it needs to call something like Microsoft Graph downstream, do so through an on-behalf-of flow rather than its own service identity.

The second registration belongs to Copilot Studio, acting as the OAuth client. This registration needs delegated permission to call the server’s access_as_user scope, and here’s the step that trips up teams building this for the first time: Copilot Studio doesn’t generate the redirect URI until after you’ve created the internal custom connector, and that URI, in the format https://global.consent.azure-apim.net/redirect/[id], has to be manually added back into the client app registration’s authentication settings afterward. Miss that step and the OAuth handshake fails at the consent screen with an error that doesn’t obviously point back to a missing redirect URI. Admin consent for the scope is optional; without it, every individual user gets prompted to consent the first time they trigger the tool, which is usually the right default for a least-privilege rollout but worth deciding deliberately rather than discovering in front of end users.

Illustration of a digital key passing through a secure gateway into a server, representing an OAuth 2.0 delegated authentication flow for an MCP server

The Token Refresh Problem You Should Test Before Rollout

Here’s the detail that doesn’t show up in the setup documentation and genuinely affects production reliability: multiple teams building Manual OAuth 2.0 connections against MCP servers fronted by Azure API Management have reported that Copilot Studio does not silently refresh an expired access token the way other MCP clients do. Instead of a background token refresh, users get a reconnection prompt asking them to open the connection manager and re-authenticate, even though the refresh URL is configured and API Management logs show no request ever reaching the token endpoint. Microsoft staff responding on the official Q&A forum acknowledged the documentation describes refresh URL support without fully documenting how automatic refresh is supposed to behave, and as of this writing there’s no confirmed, universally reproducible fix. Some teams report improvement after explicitly requesting the offline_access scope and ensuring it carries admin consent in the Entra app registration, including through an on-behalf-of token exchange if that pattern applies, while others have tried the same configuration in similar API Management and Dynamics 365 scenarios without resolution.

The practical implication isn’t to avoid Manual OAuth 2.0. It’s to test token expiry deliberately, before go-live, rather than discovering it from a support ticket after users start hitting reconnection prompts mid-conversation with the agent. Set a short token lifetime in a test environment, let it lapse mid-session, and watch what actually happens to the user experience. If your identity provider and MCP server both support Dynamic Discovery, it’s worth evaluating as an alternative specifically because it removes a layer of manual refresh-URL plumbing that you’d otherwise be responsible for getting right yourself, though it doesn’t eliminate the need to validate refresh behavior end to end.

Governance Doesn’t Stop at the Connection

One detail that often gets missed in the rush to get a tool call working: MCP connections in Copilot Studio still respect the Power Platform connector data policies your organization has already configured, and they require the agent to be running on the standard harness rather than the classic one. That means a Data Loss Prevention policy that blocks a connector for other reasons will also block it here, which is good news for governance teams worried about a new class of integration bypassing controls they’ve already invested in, and worth confirming explicitly during design rather than assuming.

What This Means for the Next MCP Integration You Build

Treat the authentication model for a custom MCP server as an early design decision, not an implementation detail to finalize after the demo works. If the agent will ever touch data that someone will ask “who accessed this and when” about, plan for Manual OAuth 2.0 with delegated permissions from the start, budget time for the two-app-registration setup and the redirect URI step that has to happen after connector creation, and build token expiry testing into your pre-production checklist rather than treating a reconnection prompt as a surprise. The extra hour spent on the identity model up front is consistently cheaper than the week spent explaining to a security review why a proof-of-concept shortcut is now the production architecture. Routeget Technologies has walked several clients through exactly this kind of MCP and Copilot Studio authentication design during Power Platform governance engagements, and the pattern holds every time: the auth decision made in week one is the one everyone lives with, for better or worse, long after the pilot is forgotten.

#CopilotStudio #MCPServer #OAuthSecurity #AgenticAI #PowerPlatformGovernance #EnterpriseAI

Power Apps’ Model App-Builder Skill Just Reached GA. The Approval Step Needs a Real Definition.

IT director reviewing an AI-generated model-driven app blueprint on a monitor

An IT director at a mid-sized distribution company got a message last week that would have been unthinkable two years ago: a business analyst on the finance team had built a complete case-management app, tables, forms, a security role, and an approval workflow included, in an afternoon, by describing what she needed in plain English. No developer was involved. No ticket sat in a backlog. The app worked on the first try. The IT director’s reaction was not relief. It was a question nobody on her team could immediately answer: who actually checked what that security role grants access to? The tool behind the app, it turned out, was the newly generally available Power Apps Model App-Builder Skill.

That scenario is no longer hypothetical. Microsoft’s September 2026 Power Platform update confirmed general availability for the Power Apps Model App-Builder Skill, a capability that lets makers use AI coding tools such as GitHub Copilot CLI or Claude Code to generate an entire model-driven app from a natural-language description, including Dataverse tables, forms, views, sitemaps, security roles, business process flows, and business rules. This sits alongside the already-GA generative pages capability, which handles individual pages inside a model-driven app the same way. Put together, the distance between “someone wrote a paragraph describing an app” and “a production business process exists in Dataverse” has collapsed to something close to zero.

For a CIO or IT director already managing a Power Platform footprint, the interesting part isn’t the productivity story. That part is straightforward: fewer requests stuck behind a scarce pool of Dataverse developers, faster turnaround for genuinely simple line-of-business apps, and a natural entry point for citizen developers who previously needed a professional developer just to get a security role configured correctly. The interesting part is what happens between the prompt and the deployment, because Microsoft did build a checkpoint into this workflow. The question worth asking before turning it on broadly is whether that checkpoint checks the things an organization actually needs checked.

What the Power Apps Model App-Builder Skill Actually Generates

The documented workflow follows a pattern Microsoft has used elsewhere in its AI code generation tools for Power Apps: a planner agent reads the natural-language requirement and proposes a plan describing what it intends to build, the maker reviews that plan and can ask for adjustments, the maker confirms once the plan matches intent, and only then do specialized agents generate the artifacts and deploy them. Some workflows in this family include an optional verification pass using automated browser testing before the app goes live. Microsoft’s own guidance is candid about where responsibility lands afterward: the tools make “a best-effort attempt to generate complete, production-ready code with accessibility and security best practices,” but the maker is ultimately responsible for validating what gets produced.

That single sentence is worth sitting with, because it reframes what “the app worked on the first try” actually means. It means the functional description matched. It does not mean the security role’s field-level permissions match the organization’s data classification policy, or that the generated business rule doesn’t create a downstream conflict with an existing plugin, or that the sitemap navigation doesn’t expose a table that shouldn’t be visible to that user’s role. A business analyst confirming a plan in the reviewer step is answering “does this do what I described,” which is a different question from “is this safe to run in production,” and most of the people who will use this tool are, by design, not the people equipped to answer the second question.

Abstract illustration of an AI-generated application blueprint with tables and workflow icons being approved by hand

Not Every Piece of This Carries the Same Guarantee

There’s a second nuance worth flagging before any organization treats “Model App-Builder Skill: GA” as a blanket green light. The broader family of AI code generation tools for model-driven apps includes capabilities at different maturity levels within the same feature set. Microsoft’s own documentation for the related generative pages capability, for instance, states plainly that connector support for reaching data outside Dataverse is a preview feature, and adds the standard caution that “preview features aren’t meant for production use and may have restricted functionality.” That distinction matters in practice: a maker building a generated page or app that only touches Dataverse tables is working with generally available functionality, while a maker who extends that same generation flow to pull data through a connector has quietly stepped into preview territory without necessarily realizing it, since the interface doesn’t force that distinction on them.

The practical lesson isn’t that this capability is unready. It’s that GA status attached to a feature name in a release announcement doesn’t automatically extend to every path a user can take through that feature. Anyone signing off on a broad rollout should ask, capability by capability, which specific paths are GA and which are still preview, rather than accepting the headline classification at face value.

Where the Business Case Genuinely Holds Up

None of this argues against adopting the capability. The economics are real. Organizations running Power Platform at any scale already carry a backlog of small, well-understood app requests that never justify a professional developer’s time: an approval tracker for a regional office, a case log for a compliance team, an intake form tied to a simple review workflow. These are exactly the apps this tool is suited to generate, and getting them built by the people who understand the business process, without a six-week wait for developer capacity, is a legitimate efficiency gain. The plan-review step, imperfect as a security control, is also a genuine improvement over the alternative most organizations had before AI-assisted building existed, which was citizen developers hand-configuring security roles inside the maker portal with even less structured oversight than a mandatory plan review provides.

What to Put in Place Before Turning This On Broadly

The fix isn’t to block the capability. It’s to extend existing Power Platform governance so it explicitly accounts for AI-generated artifacts rather than assuming manually built and AI-generated apps carry the same risk profile by default. A few specific steps hold up in practice. First, the plan-review step needs a defined second reviewer for any app that generates a new security role or business process flow, someone who understands the Dataverse security model and can evaluate a generated role’s actual grants, not just the person who requested the app confirming it matches their description. Second, generated apps should flow through the same promotion gate as manually built ones before reaching a production environment, meaning a Managed Environment with rules that don’t exempt AI-generated solutions from the review and testing stages already required for everything else. Third, generated solutions should be identifiable as such, through naming convention or solution metadata, so a Center of Excellence audit can actually find and review them as a distinct population rather than discovering one during an incident. Finally, before authorizing broad use, someone on the platform team should walk through which specific capabilities inside this tool family are GA and which remain preview, since that boundary will keep shifting as Microsoft continues to expand it through 2026 release wave 2 and beyond.

None of this is a reason to slow-walk adoption. It’s a reason to make sure the governance conversation happens at the same speed as the feature rollout, rather than six months after the first generated security role turns up somewhere nobody expected it. The tools that let a business analyst build a working app in an afternoon are genuinely useful, and organizations that get the review discipline right early will capture that speed without absorbing the risk that comes from treating a functional plan review as if it were a security review. Routeget Technologies has been helping clients extend Center of Excellence frameworks to explicitly cover AI-generated Power Platform artifacts as this category of tooling matures, and the pattern holds across nearly every engagement: the technology is ready faster than the governance process is, and closing that gap deliberately is cheaper than closing it after something ships that shouldn’t have.

#PowerApps #ModelDrivenApps #AIAppBuilder #PowerPlatformGovernance #CitizenDevelopment #EnterpriseAI

Sales Research Agent Fabric Lakehouse Connections Don’t Grant Access. They Borrow Yours.

Solution architect reviewing a cloud data security and permissions dashboard on a large monitor in a modern office

A VP of sales operations at a mid-size manufacturer asks the new Sales Research Agent a simple question: “Are we tracking to quota this quarter across the East region?” The lakehouse holding quota, backlog, and actuals data has been live for months, built by the FP&A team specifically so questions like this could be answered without another spreadsheet cycle. The agent comes back with nothing useful, a vague answer built entirely from Dataverse pipeline data with no mention of quota or backlog at all. IT checks the lakehouse. The tables are there. The data is current. Nobody on the support call can explain why the agent can’t see what is plainly sitting in front of it.

The explanation, once you find it, is almost always the same: the person asking the question doesn’t have permission to the lakehouse item itself, only to the workspace it lives in, and the agent will not go around that. This is the part of a Sales Research Agent Fabric Lakehouse setup that trips up architects who have configured plenty of Power BI reports and Dataverse connections but have not internalized that this feature behaves nothing like either of those.

What a Sales Research Agent Fabric Lakehouse connection actually is

Dynamics 365 Sales’ Sales Research Agent reached general availability on April 30, 2026, after a public preview that started in mid-February, and it does something genuinely useful: it lets sales and revenue operations teams ask natural-language questions that span CRM pipeline data, finance and quota data sitting in a Microsoft Fabric lakehouse, and ad hoc files like a CSV export or a PDF board deck, all from one research canvas instead of three separate tools. The predefined insights it ships with cover attainment against quota, pipeline coverage relative to revenue goals, and variance between forecast, actuals, and invoiced results, which is exactly the kind of cross-system reconciliation that used to require a dedicated analyst and a Tuesday afternoon.

The part worth slowing down on is how the lakehouse connection is architected. It is not a data integration in the ETL sense, where an admin authorizes a service principal once and everyone downstream inherits access to a curated dataset. It is closer to a live pass-through: the agent authenticates to Fabric using the requesting user’s own Entra ID identity, via the same credentials they already use to sign into Dynamics 365. Whatever that person can see in the lakehouse through normal Fabric permissions is what the agent can see on their behalf, and nothing more. The agent never elevates privileges, and it never caches a broader view of the data than the user asking the question is entitled to.

The permission layers people forget

That single-sign-on design means two separate permission checks have to pass before a query against Fabric data will return anything at all. First, the user needs at least Viewer access at the workspace level, since Contributor and Admin also satisfy this but nothing less does. Second, and this is the one that catches people, workspace access alone does not imply access to a specific lakehouse item inside that workspace. Fabric enforces item-level permissions independently, so a user can be a workspace Viewer and still be denied at the lakehouse itself if nobody has explicitly granted them access to that item. Most Dataverse-oriented admins are used to security roles being the single gate; Fabric’s layered model means there are effectively two gates, and skipping a check on the second one is the most common reason a rollout stalls in the first week.

Abstract illustration of a digital identity key passing through a security gate to access layered data lake tables

If the lakehouse data is organized through shortcuts pointing to another OneLake location or to Azure Data Lake Storage Gen2, there is a third layer: the user also needs read access on whatever the shortcut actually targets, since Fabric will not silently grant that just because the shortcut itself is visible. And if the organization has applied row-level or column-level security through a semantic model sitting in front of the lakehouse tables, that policy is enforced automatically for every query the agent runs. A regional sales director and a national VP asking the identical question through the agent can legitimately get different, both-correct answers, filtered by whatever RLS scope already applies to their account. That is a feature, not a bug, but it needs to be explained to end users before launch, or the first person who gets a narrower answer than a colleague will assume the tool is broken.

Getting the rollout right

The practical fix is to treat the Fabric connection as an access review project before it is a feature-enablement project. Before turning this on for a sales operations team or a broader analyst group, pull the actual list of who has workspace and item-level access to the relevant lakehouse, compare it against who is expected to use the agent, and close the gap deliberately rather than reactively. It is worth testing with a genuinely representative non-admin account rather than an admin’s own credentials, since an admin will almost always have blanket access that masks exactly the permission gaps a normal seller or ops analyst will hit.

Data quality inside the lakehouse matters just as much as access does, because the agent leans heavily on table names, column headers, and any descriptive metadata attached to them to figure out what a natural-language question is actually asking for. A table named tbl_fct_rev_q3 with undocumented columns will produce worse, less trustworthy answers than one named clearly with business-friendly column labels, even though the underlying numbers are identical. Where the schema can’t be renamed because other systems depend on it, the agent supports adding plain-language business context separately, and that extra half day of documentation work consistently pays for itself in answer quality once real users start asking open-ended questions instead of the handful you tested with.

One more subtlety worth building into a QA pass: currency handling is straightforward for native Dynamics 365 Sales data, since the agent uses the environment’s base currency automatically, but for lakehouse and uploaded-file data it has to infer currency from context. For a domestic single-currency organization this is a non-issue. For anyone with multi-entity or multi-currency operations feeding that lakehouse, it is worth deliberately testing a few currency-sensitive questions before general rollout rather than discovering the inference was wrong when a regional forecast number looks off by an exchange rate.

Budgeting for consumption, not just configuration

Access to the agent itself runs through a dedicated Sales Research Agent Reader security role, which is a clean, familiar Dataverse-style control and easy to scope correctly. What is less familiar is that every question run through the agent consumes Copilot Studio credits, so a rollout to an entire sales organization without any usage guardrails or monitoring can turn into a licensing conversation nobody budgeted for, especially once people realize they can ask it anything rather than just the handful of predefined insights it ships with. Treat the credit consumption model as part of the initial deployment plan, not an afterthought discovered on next quarter’s invoice.

None of this makes the Fabric integration a bad design. A pass-through model that never elevates permissions is the right security posture for a tool that reasons across finance and CRM data simultaneously, and the alternative, a broadly privileged service account with its own access to everything, would be a much worse outcome from a governance standpoint. But the security model only works as intended when the access review happens before launch. Organizations that have gone through this rollout carefully, treating the Fabric permission audit as a real workstream rather than a footnote, are the ones whose first week of feedback is about the quality of the answers rather than a flood of tickets asking why the agent can’t see obviously available data. That is the pattern we walk clients through at Routeget when a Sales Research Agent deployment is on the table: get the access model right first, and the rest of the rollout tends to go quietly.

#SalesResearchAgent #FabricLakehouse #Dynamics365Sales #DataGovernance #CopilotStudio #EnterpriseAI

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