Organizations have spent the past few years trying to get people building with AI. That effort is working: Agents are moving beyond experimentation and into real business processes.

For IT teams, this kind of successful adoption creates a new set of questions.

• What agents exist across the organization? Who owns them and what systems and data can they access?
• How are they being used, and what do they cost to operate?
• Are they healthy?
• And how do you know when an agent’s risk profile or behavior changes?

These questions get harder as the agent estate of an organization grows. Agents may be built by different teams or on different platforms. Some may operate outside the Microsoft ecosystem entirely. Their capabilities can also change as they connect to new data and tools.

We’ve been thinking a lot about this challenge as we prepare for the Microsoft Power Platform Conference (PPCC) in October 2026. One idea comes up again and again: Scaling agents doesn’t just mean governing more things. It requires changing how governance itself works.

Inventories, reviews, and administrator controls remain important. But they need to become part of a more continuous operating model. I see that evolution in three parts: observe continuously, respond proportionately, and automate where appropriate.

Observe continuously

You can’t govern what you can’t see. And when it comes to agents, visibility means more than maintaining an inventory. It means understanding each agent in context: its ownership, identity, access, usage, health, and behavior.

It is important to note that that context isn’t static. A maker or admin could give an agent access to a new tool or data source. They could change the agent's owner. The way people use it in production may reveal something about the build that wasn’t apparent during development. And, of course, usage of that agent (hopefully) will grow over time. That makes observability, defined as visibility into agent activity and behavior through telemetry, an ongoing requirement.

Then, at enterprise scale, there’s the question of coverage. In my experience, many enterprises plan to build agents in multiple places. They may be built with Microsoft platforms like Copilot Studio, third-party platforms, and/or custom development.

This is where cross-platform management layers like Microsoft Agent 365 become especially important. A shared agent control plane—that is, a common layer for managing and governing agents across platforms—makes observability actionable across the agent estate, rather than leaving signals isolated within individual platforms. IT can use those signals to detect changes such as risk, usage, cost, and health over time.

At PPCC, the Agent 365: Securely Managing and Governing Agents at Scale workshop will go deeper into the controls and operating practices behind this model. If these are questions you’re working through in your organization, I hope you’ll join us there.

Respond proportionately

Once you have signals, the next question is what you do with them.

Not every agent represents the same level of risk. An agent that answers employee questions from approved internal documentation is very different from one that can access sensitive data and take actions in a production system. They shouldn’t necessarily go through the same governance process.

At enterprise scale, treating every agent identically creates problems in both directions. Too little oversight introduces unnecessary risk. Too much can create bottlenecks for scenarios that fit established policies.

A more scalable approach is to align the response with the risk. Identity, permissions, data access, autonomy, and available actions all provide useful context. Organizations can use that content to determine which policies apply and where additional review is appropriate.

For example, imagine an agent gains access to a new data source. That change is a signal. What’s the appropriate response?

If the new access falls within established policies and risk boundaries, the agent may not need additional intervention. If it introduces a higher level of risk—such as access to sensitive data—it could trigger stronger controls or human review. This type of program might look something like this:

The important shift seen with this approach is that governance becomes less dependent on applying the same manual process to every agent. Instead, organizations can establish patterns for different levels and types of risk. That makes governance more predictable for builders, too. Teams know the boundaries they’re working within, while higher-risk agents can receive additional scrutiny.

We’re applying this principle inside Microsoft as well. At PPCC, How Microsoft Does IT: Managing and Governing Agents with Risk-Aligned Oversight will share how we’re approaching risk-aligned agent governance across Copilot Studio, Agent 365, Microsoft Defender, and Microsoft Purview.

Automate where appropriate

Once you can observe changes and determine the appropriate response, the next question is: Does a person need to execute that response every time? At enterprise scale, the answer increasingly needs to be no.

Many governance decisions are repeatable. Organizations already know the policies they want to enforce, the boundaries agents should operate within, and the conditions that require additional review.

This is where I think governance starts to become agentic, too. One useful way I’ve found to think about it is as a continuous loop: Observe → assess → act → escalate

At a high level, this loop represents how a more automated governance framework can work.

Basically, in such a framework: The governance system detects a relevant signal and evaluates it against the context and policies the organization has established. When the appropriate response is clear, an automated control can act. When the situation falls outside those boundaries or requires judgment, it can be escalated to a person.

The goal isn’t to automate every governance decision, but rather to automate the decisions we already know how to make. People will continue to be responsible for setting policies, defining risk tolerances, and deciding where human judgment is required. The objective here is to let automation handle more of the repeatable work inside those boundaries.

In practice, that changes the job of IT teams and Centers of Excellence (CoEs). Instead of inspecting and configuring agents one at a time, they can spend more of their effort designing how governance operates: defining trusted patterns, establishing risk thresholds, and deciding when human intervention is required.

You can see some of this shift from visibility toward action at PPCC. The Agentic Governance: Secure, Govern, and Operate Your Power Platform at Scale session will explore real-time inventory and telemetry alongside automated controls and security, using the Power Platform API as an extensibility layer for enterprise governance.

Governance must evolve with the agent estate

The goal isn’t a future where people disappear from agent governance. It’s one where their attention is used more deliberately.

As agents become more capable, the systems around them need to become better at sensing change. As the estate grows, oversight needs to reflect actual risk. And as routine governance work increases, organizations need to decide what can be handled through established policy and what needs human judgment and accountability.

That is the shift I mean when I say governance is becoming agentic, too. And we’re only beginning to explore what that operating model can look like at enterprise scale.

If you’re working through these questions in your own organization, we’ll be digging into them throughout PPCC. Here are a few sessions and workshops I recommend:

Sessions

• Governance of All Your Agents at Scale
• How Microsoft Does IT: Managing and Governing Agents with Risk-Aligned Oversight
• Observability and Governance for Your Third-Party Agents with Minimal Configuration and Maximum Control
• Secure by Design: Preparing Agents for Production and Scale
• Governance First, Agents at Scale: How Wells Fargo Built Copilot Studio Agents in a Regulated Bank

Workshops

• Agent 365: Securely Managing and Governing Agents at Scale
• Mastering Governance at Scale: Unlock the Full Potential of Your Power Platform and Agent Estate
• Nobody Knows How Many Agents You Have

3.0.0-beta.3 (2026-09-16)

Features Added

• Added ProjectsRealtimeClient and ProjectsRealtimeSessionClient to work with voice agents. AIProjectClient.ProjectsRealtimeClient gets a ProjectsRealtimeClient; calling StartSessionAsync(model, intent, options, cancellationToken) on it -- the same method used with OpenAI's own RealtimeClient -- connects a ProjectsRealtimeSessionClient to the named voice agent's realtime endpoint (/agents/{agentName}/endpoint/protocols/voice). Pass store=true/store=false via options.QueryString to control whether the session's conversation is persisted. ProjectsRealtimeClient is also available when AIProjectClient is constructed from an AIProjectClientSettings whose credential resolves a token provider.

Breaking Changes

• MaxSamples member was removed from DataGenerationJobOptions.
• AIProjectClient.GetProjectsRealtimeSessionClient(string, string) and its replacement GetProjectsRealtimeSessionClientAsync(string, string, bool?, CancellationToken) were both removed in favor of AIProjectClient.ProjectsRealtimeClient.StartSessionAsync(string, string, RealtimeSessionClientOptions, CancellationToken), reusing OpenAI's own RealtimeClient.StartSessionAsync method rather than introducing a separate one.
• ProjectsRealtimeSessionClient's public constructor was removed. An instance constructed through it could never become connected (its ConnectAsync override is only reachable through ProjectsRealtimeClient.StartSessionAsync), so it offered no working standalone use; call AIProjectClient.ProjectsRealtimeClient.StartSessionAsync to obtain an already-connected instance instead.

Sample Updates

• Added Sample_VoiceAgent, showing how to create a voice agent and exchange a realtime text turn with it, and Sample_VoiceAgent_ReadConversation, showing how to persist a realtime session's conversation with store: true and read it back afterward through BetaVoiceAgentsConversations.

Internal dependency updates only — this prerelease contains no user-visible SDK changes since v1.0.15-preview.0. The only changes are automated Copilot CLI snapshot updates for internal testing.

Full Changelog: v1.0.15-preview.0...v1.0.15-preview.1

network:
  allowed:
    - defaults
    - "github.com"

Generated by Release Notes Generator · copilot · auto · 42.6 AIC · ⌖ 5.58 AIC · ⊞ 9K

2026-09-22

• Add optional OSC 777 terminal notifications for direct Ghostty and WezTerm sessions.
• Text selection now works in bottom-anchored dialogs, including login device codes
• Preserve /allow-all during managed-settings refresh failures, and remember exact session approvals for missing paths without granting their parent directory; exact grants are visible in /list-dirs and cleared by /reset-allowed-tools
• Sandboxed network denials from proxy tunnel failures now show bypass guidance
• Custom-agent startup now distinguishes model-list load failures from an empty catalog, preventing false unavailable warnings and silent required-agent deselection
• Pressing Enter in freeform ask_user prompts adds a new line; submit with Ctrl+Enter or Ctrl+S as a fallback
• A custom agent's reasoning-effort now applies when the agent is selected, instead of only its model. An explicit --reasoning-effort still wins, and a level the selected model does not offer is reported and left unapplied
• Deferred MCP tools whose registered name needed sanitizing or shortening are now listed under that name, so tool search can find them, and deferred MCP tools with no resolvable server name are now listed with the other tools instead of being left out of the reminder
• Prompt mode now warns when it stops waiting for background tasks and explains how to change the timeout limit.
• Resuming sessions no longer stalls when MCP permission prompts are pending
• MCP tools recover more reliably from transient listing, connection, and OAuth failures
• Hook commands without an explicit cwd again run in the project root instead of the session's current directory, so repo-relative hook scripts still resolve from a subdirectory.
• Enterprise managed settings now apply to sessions opened in ACP mode (copilot --acp), by AHP hosts (copilot --ahp-host), and by the published --server session, which previously ran with no managed MCP, permission, or plugin policy.
• GitHub MCP scope escalation now uses the CLI OAuth app's registered /callback redirect URI
• Agents from a plugin mounted with --plugin-dir now appear in server-mode sessions
• Session and subagent start hooks combine successful additional-context contributions within the hook-output limit
• Cached MCP tools stay scoped to environment-resolved server addresses and headers
• Session resume preserves pending conversation events when saving fails and explains that retrying is safe
• Support namespaced custom skills and ignored skill directories during skill discovery
• MCP and plugin views show server display names and plugin descriptions for clearer status.
• Resuming large local sessions keeps transcript memory bounded for smoother CLI performance.
• Prompt to update GitHub authorization when Connectors need reauthorization
• Indexed search supports glob filtering and --files listings with accurate ripgrep fallback behavior.
• Run /fork during active turns to branch work without waiting.
• In the Sessions tab, rows you can dismiss now take x then x again to confirm: a local session is permanently deleted, while a session backed by a server is only closed and its conversation is left on the server. The footer says which of the two the highlighted row will do, and shows no x hint for rows that cannot be dismissed.