Agent governance in Microsoft 365 on DR.365

Agent Builder, Copilot Studio or Foundry: who owns the risk?

Mon, 19 Oct 2026 07:00:00 +0200

Three requests arrive in the same week. HR wants an agent that answers questions about the travel expense policy. The service desk wants an agent that creates tickets in the ITSM tool. Legal wants an agent that checks supplier contracts against a clause library and flags deviations. All three are “an agent”, and in most tenants the same person could build all three on the same afternoon.

The governance questions behind them are very different, and the choice of tool answers many of them before anyone writes a policy. That is why this series starts here, before lifecycle, runtime controls and compliance. Microsoft recently described how it enables agent creation in its own tenant (Microsoft Inside Track). I use that guide as a starting point, but I read it from a different seat: that of an operator in a regulated environment, usually with several tenants and an IT service provider in the picture.

Three tools, three kinds of builders

Agent Builder in Microsoft 365 Copilot is for information workers. Its agents answer questions from content the user can already reach: SharePoint, OneDrive, email, Teams messages, Copilot connectors, Dataverse or the web. Code interpreter and image generation are built in, so “retrieval only” is not quite accurate. What Agent Builder cannot do is call external services. There are no actions, connectors or workflows, and Microsoft’s answer for those is to copy the agent to Copilot Studio (Microsoft Learn).

Copilot Studio is for makers, from trained business users to Power Platform developers. Agents reach other systems through connectors, run agent flows with approvals, react to triggers as autonomous agents and call other agents. Governance lives in Power Platform environments: data policies, separate development, test and production environments, and admin approval before an agent is published to the organization (Microsoft Learn).

Microsoft Foundry and the Microsoft 365 Agents Toolkit are for developers. In Foundry, the team picks the model, writes the orchestration and runs the agent as hosted code with its own Entra identity (Microsoft Learn). The Agents Toolkit in Visual Studio Code builds both declarative agents, which use the Copilot orchestrator just like Agent Builder agents, and custom engine agents with their own orchestration (Microsoft Learn). So the tool alone does not decide who carries the risk. The architecture does.

Who carries the risk?

Microsoft’s guide sorts the three tools by who owns the risk. Agent Builder has intrinsic governance: the platform carries the risk, because the agent stays inside existing Microsoft 365 boundaries. Copilot Studio has configurable governance: the administrator carries the risk, because connectors, flows and data movement need rules. Foundry has explicit governance: the organization carries the risk, because it decides on model, orchestration and architecture.

I find the distinction useful, with one caveat for the first model. “The platform carries the risk” describes the technical boundary. Agent Builder grants no new permissions and only uses content the user can already see (Microsoft Learn). The data risk stays with you: an agent on top of an overshared SharePoint site makes the oversharing easier to find. In addition, every user may share Agent Builder agents with the whole organization by default, and sharing an agent can share the underlying SharePoint files at the same time (Microsoft Learn). The platform sets the boundaries. Whether the data inside them is in order remains your job.

Microsoft’s zone model for Copilot Studio governance follows the same line: zone 1 for Agent Builder and SharePoint agents with read-only access, zone 2 for Copilot Studio, zone 3 for professional development with Foundry and Copilot Studio (Microsoft Learn). Part 2 builds on these zones.

Questions to answer before anyone builds

Microsoft’s guide lists questions for builders. I use a slightly different set, because operators need one more:

Goal: what should the agent achieve, and how will you notice that it works?
Data: which sources does it need, and are they personal, team or enterprise data? The classification matters as much as the location.
Mode: should it retrieve information, act in other systems or run on its own? Retrieval fits Agent Builder. Actions mean Copilot Studio at the latest. Autonomous agents without a signed-in user shift most of the risk into configuration.
Reach: an agent shared with five colleagues and one in the organization’s catalog are different products.
Operation: who runs the agent after go-live, and in which tenant? This is the question I see missing most often. It decides who keeps knowledge sources current, who reviews permissions and who switches the agent off.

The operator’s view

Microsoft describes one very large tenant with its own CISO office, an internal hub for builders and a team that measures maker friction. According to Microsoft, monthly active makers grew from about 2,000 to 20,000, about 150,000 personal development environments are under governance, and measured maker friction fell from roughly 50 to 5 percent (Microsoft Inside Track). These are figures from Microsoft’s own tenant. I would not use them as a benchmark for a utility with 3,000 employees.

In regulated environments with a service provider, three things change.

The administrator often works for someone else

Service providers usually hold admin roles in customer tenants through GDAP, scoped and time-bound. Microsoft now offers multi-tenant agent management in the Microsoft 365 admin center, currently in preview. With the AI Administrator role, a provider can view, install and block agents across all governed tenants from one place. Risk signals and activity data require Agent 365 licenses (Microsoft Learn). That helps, and it makes one question more pressing: if the configurable model puts the risk on “the administrator”, which administrator is meant?

The three models split between customer and provider

My working model, not Microsoft’s:

Model	Customer	Service provider
Intrinsic (Agent Builder)	Data risk: permissions, labels, what gets shared	The settings it manages under contract, such as sharing controls and registry reviews
Configurable (Copilot Studio)	Approval of agents and connectors, business ownership	Environments, data policies and connector rules, if it designs and runs them
Explicit (Foundry)	Purpose, data and acceptance	Model, code and release process, if it builds the agent

The second row is where contracts are usually vague. The service description should state who maintains data policies and how quickly a request to block an agent is executed. The third row has a regulatory side: a provider that builds an agent for a customer can end up in a provider role under the AI Act, depending on purpose and branding. Part 4 deals with that.

Shadow AI has a different weight

Microsoft argues that too much control does not remove risk, it pushes builders to unsanctioned tools and costs both productivity and visibility. I agree with the mechanism. In regulated environments, I draw the line by function rather than by tool. Zone 1 can stay open: Agent Builder agents on content people can already read, with org-wide sharing limited to a defined group. The hard boundary belongs where an agent acts in other systems or runs without a signed-in user. One argument also carries more weight under NIS2 than in Microsoft’s case: an agent that nobody has registered is missing from the asset inventory, and auditors ask for that inventory.

Five things to check tomorrow

Check who may share Agent Builder agents with the whole organization. Unless someone changed it, the answer is everyone.
Filter the agent registry by platform and count the agents per tool. That shows which risk model dominates your tenant.
List for each customer tenant who holds the AI Administrator and Power Platform administrator roles, the customer or the provider.
Add the operation question (who runs it, in which tenant) to your agent request form.
Check whether your Agent 365 licensing covers the tenants where you need risk signals. Without it, the registry shows the inventory but no risks (Microsoft Learn).

How the series continues

Part 2, lifecycle: how much lifecycle an agent needs, and how it differs between the admin center, Copilot Studio environments and a Foundry release process (part 2).
Part 3, runtime: whose permissions an agent uses when it calls tools and other agents, and where responsibility shifts along the way (part 3).
Part 4, compliance: who has to deliver evidence under the AI Act, GDPR, NIS2 and ISO 27001/42001, and how much of it Microsoft 365 provides (part 4).

Sources

Agent lifecycle: how much governance does a Copilot agent need?

Mon, 12 Oct 2026 07:00:00 +0200

📝 This series has been extended

In October 2026 this series gained an introductory part. This post was originally part 1 and is now part 2. Part 1 sorts Agent Builder, Copilot Studio and Foundry by who carries the risk.

Building an agent with Agent Builder in Microsoft 365 Copilot takes a few minutes. Getting rid of it takes forever in many tenants, because nobody feels responsible. The colleague who built an agent for the travel expense policy last spring has moved to another department. The agent keeps answering questions anyway, based on a policy that has been out of date since July.

That is the problem an agent lifecycle solves. In this post I describe how I would set up a lifecycle for agents built with Agent Builder and Copilot Studio, and which tools Microsoft now provides for it. My take: not every agent needs the full process. Every agent does need an owner, and that only works for agents that are registered. What does not show up in the agent registry cannot be assigned to a person, reviewed or switched off.

The lifecycle by platform

Part 1 covers which tool fits which builder and who carries the risk. For the lifecycle, the phases stay the same, but where they happen depends on the platform.

IT manages Agent Builder agents (intrinsic model, the platform sets the boundaries) in the Microsoft 365 admin center: visibility, sharing, owners, blocking and deletion. There are no versions and no environments, so the lifecycle here is mostly about sharing, ownership and cleanup.

Copilot Studio (configurable model, the administrator sets the rules) uses application lifecycle management with separate development, test and production environments. Data policies, connector rules and publishing approval are tied to those environments (Microsoft Learn).

Foundry (explicit model, the organization owns model and code) follows your own engineering process: versioning, evaluation and publishing run through the development team’s tools and pipelines (Microsoft Learn). Published Foundry agents appear in the agent registry, and admins can stop them there (Microsoft Learn). The rest of this post focuses on Agent Builder and Copilot Studio. Foundry goes through the same phases, implemented with conventional software engineering.

The bridge between Agent Builder and Copilot Studio is the copy feature: an agent from Microsoft 365 Copilot can be copied to Copilot Studio once it needs more than a personal helper can offer. In lifecycle terms, that is the moment an agent changes zones.

Three zones instead of one process for everything

A single approval process for every agent fails on two sides. An IT review is overkill for the personal agent that summarizes my own meeting notes. A click on “Share” is not enough for an agent that answers payroll questions for 3,000 employees.

Microsoft addresses this with a zone model (Microsoft Learn). In zone 1, anyone can build agents for personal or team productivity, grounded in content they can already access. In zone 2, makers approved by IT build agents for other teams. These agents go through an IT review and are deployed to environments that IT manages. Zone 3 is reserved for organization-wide agents that are treated like any other enterprise application. The current whitepaper Administering and Governing Agents is now structured along the same personal, team and enterprise levels.

Microsoft now maps tools to zones more tightly: zone 1 for Agent Builder and SharePoint agents, zone 2 for Copilot Studio, zone 3 for Foundry and Copilot Studio in professional development. I still allow Agent Builder agents in zone 2 as long as they only read content the team can already access. For me, reach decides the zone, not the tool.

For the lifecycle, the zone decides how many phases an agent goes through and how strict they are. An agent in zone 1 takes the short path. As soon as its reach, data access or criticality grows, it moves to the next zone and into a stricter process.

The seven phases at a glance

The diagram builds on a lifecycle model that has been circulating online. I extended it with the zones, the specific Microsoft tools for each phase and a separate decision gate.

1. Identify

Everything starts with a real problem. Ideas go into a backlog, for example a SharePoint list or a Planner board. Each idea gets a short profile with the problem, the target audience and an accountable owner. Without an owner, the idea goes no further.

2. Assess and prioritize

This is where the most important decision of the whole lifecycle happens: which zone does the agent belong in? I look at value and effort, but mostly at the data. Which knowledge sources will the agent use, who is allowed to read them, and should the agent trigger actions in other systems? The answers also determine the tool. Agent Builder covers many zone 1 and 2 scenarios. Once actions, connectors to line-of-business apps or a broad rollout come into play, the path leads to Copilot Studio. If the agent needs its own model or orchestration, it ends up in Foundry and in the development team’s process.

3. Design and prototype

Success criteria come before building. What does the agent need to answer, and how will I know it does that well? Only then does a prototype take shape: directly in Agent Builder for zone 1, in a Copilot Studio development environment for zones 2 and 3. Microsoft recommends environment routing to send makers to personal developer environments automatically, so not everything ends up in the default environment (Microsoft Learn).

4. Validate and decide

This phase finally has a proper tool. Agent Evaluation in Copilot Studio has been generally available since the end of March. It lets you create test sets, choose evaluation methods and repeat runs across agent versions. A Power Automate connector and a REST API (currently in preview) make it possible to include evaluations in CI/CD pipelines (Microsoft Learn).

Security and data protection belong in this phase too: which data can the agent see, which identity does it run under, and do its permissions match the intended audience? If the agent calls other agents or tools, add a second question: do they act with the user’s permissions or with their own, possibly broader credentials? In Copilot Studio this is set per tool, and a connected agent does not inherit the setting of the agent that calls it. The phase ends with a deliberate decision.

The gate: Go, Change, Hold or Stop

The decision after phase 4 has four possible outcomes. Go leads to production. Change sends the agent back to phase 3 because quality or design still fall short. Hold parks it in the backlog, for example because a data source is not yet properly permissioned. Stop ends the idea in a controlled way.

Many organizations underestimate Stop. An agent that fails its tests should not stay in the tenant as a half-finished prototype.

5. Deploy and scale

In zone 3, nobody edits an agent directly in production. Microsoft recommends packaging agents as managed solutions and promoting them from development through test to production with Power Platform pipelines (Microsoft Copilot Blog). That gives you versioning, an auditable change history and the option to roll back.

Publishing to the organization runs through the Microsoft 365 admin center, where admins can approve or reject submitted agents. A gradual rollout follows. User training belongs in the same plan, otherwise even a good agent goes unused.

6. Operate and monitor

Operations is about usage, quality and cost. Copilot Studio provides analytics, Purview covers audit and data protection, and since May 2026 Agent 365 adds a dedicated control plane for agents. Copilot Studio agents appear in its agent registry once they are made available in Microsoft 365. The same agent can show up more than once, for example as a shared and as a published version (Microsoft Learn). Governance actions are logged in Purview.

Two things are a fixed part of operations for me: keeping knowledge sources current so the agent does not answer from outdated documents, and recertifying permissions on a regular schedule. Anyone working with customers in regulated industries knows this principle from identity management. It applies to agents in the same way.

7. Evolve or retire

Every agent ends at some point, either as a new version or through retirement. New versions go through the lifecycle again, starting at phase 2 or 3 depending on the scope of the change.

The admin center now includes the most important actions for retirement (Microsoft Learn). Admins can assign a new owner to Agent Builder and Copilot Studio agents, even when an agent is already ownerless. The new owner gets full edit and delete permissions plus access to the previous owner’s files, and the previous owner loses all access. Agent Builder agents can now have several owners, which admins can add or remove. Agents without a future can be blocked and deleted, with a 30-day window to restore them.

Microsoft’s Zero Trust workshop sums up the idea well: a lifecycle policy that nobody enforces remains a document (Zero Trust Workshop). Without this cleanup, the number of agents only ever grows.

Guardrails across all phases

Underneath the cycle sit six topics that apply in every phase and every zone: identity and ownership, data protection and compliance, permissions and sharing, environments and ALM, inventory and transparency, and quality and cost. In the diagram I mapped each topic to the tools available for it today, from Entra Agent ID through Purview to the agent registry.

Where it still falls short

The picture is not complete yet. Agent Builder agents have no real ALM with environments and versions. If you want to run one of them seriously, moving it to Copilot Studio is hard to avoid.

Copilot Studio has gaps as well. The built-in evaluations live in the cloud, not in source control, which makes automated quality gates in a pipeline harder than in classic software development. In an ESPC webinar, Stephan Bisser presented a CLI tool that versions test cases as YAML files to close that gap.

Finally, licensing: many registry features are available in the admin center. Risk signals in the registry and the advanced security and compliance capabilities of Agent 365 require Microsoft 365 E7 or an Agent 365 license (Microsoft Learn). Clarify this before you roll out.

Five things you can check tomorrow

Open the agent registry in the Microsoft 365 admin center and filter for agents without an owner.
Check whether environment routing sends Copilot Studio makers to their own developer environments, or whether everyone builds in the default environment.
Define the criteria that move an agent from zone 1 to zone 2, and write them down.
Create a first test set in Agent Evaluation for your most important agent.
Decide who takes over the agents of people who leave the organization.

What happens when an approved agent calls tools and hands work to other agents at runtime is the topic of part 3.

Sources

Runtime agent governance: whose permissions does a delegated agent use?

Sat, 17 Oct 2026 07:00:00 +0200

An employee asks the HR agent on the intranet how many vacation days they have left. The HR agent knows the leave policy but has no numbers, so it hands the question to a connected payroll agent that another team built. The payroll agent queries the HR system through a connector. That connector was set up with the account of the person who built the payroll agent, and that person can read every employee’s record. Whether the answer contains only the employee’s own balance or a colleague’s as well is now up to the language model.

On paper, nothing is wrong here. Both agents have an owner, both are registered and approved. The question of whose permissions the second agent uses only comes up at the moment of the call, and that moment is what this post is about.

Design time and runtime

Part 2 covered governance at design time: three zones, seven phases, an owner for every agent and a Go, Change, Hold or Stop decision. Those decisions are made once, before an agent goes into production.

At runtime, the agent decides with every request which tool to call, which other agent to involve and what data to pass along. A language model makes those decisions. For me, runtime governance means that identity, policy, authorization and logging apply at each of these hand-offs, whatever the model suggests.

Part 1 maps the tools to three models: with Agent Builder the platform carries the risk, with Copilot Studio the administrator, with Foundry the organization. At runtime that mapping becomes concrete, and in places it shifts. Agent Builder agents do not call external services, so their runtime risk is the user’s permissions. In Copilot Studio, responsibility arises at every single tool. A maker who enters their own credentials takes part of the risk off the administrator’s desk and onto their own. With Foundry, the organization builds the controls itself, for example guardrails that inspect tool calls and tool responses (preview) (Microsoft Learn). This post focuses on Copilot Studio, because that is where most hand-offs can be configured.

Signing in to the first agent is not enough

A user signing in to the HR agent tells you nothing about what the payroll agent two steps further down may do. The user’s identity has to travel all the way to the business system. In Copilot Studio, each tool decides this on its own: it uses either the end user’s credentials or the maker’s. End-user credentials are the default, and the automatic security scan warns the maker before publishing if they switch it (Microsoft Learn).

Admins can turn off maker-provided credentials per environment or environment group in the Power Platform admin center (Microsoft Learn). Every action then runs as the person who is asking. The trade-off is real: autonomous agents that start on a schedule or an event without a signed-in user fail in those environments. I would enforce the setting in production environments for zone 2 and zone 3 agents and give autonomous agents a separate environment with its own rules.

Entra calls the same pattern on-behalf-of. The agent exchanges the user’s token for a new one issued for the target resource, and Conditional Access evaluates that exchange (Microsoft Learn). The agent also has an identity of its own. Since May 2026, new Copilot Studio agents get a Microsoft Entra Agent ID automatically: at creation in the standard harness, on first publish in the GitHub Copilot harness. The agent owner is added as its sponsor (Microsoft Learn).

Keep enforcement out of the prompt

The model picks the next tool, and a crafted email or a poisoned document in a knowledge source can influence that choice. A rule that only lives in the agent’s instructions (“never return salary data”) is therefore a request to the model. Enforcement has to happen somewhere the model cannot talk its way past.

Microsoft 365 offers several layers for this. Data policies in the Power Platform admin center define which connectors an agent may use, and the connector platform checks them again on every call (Microsoft Learn). Conditional Access evaluates tokens for agent identities. Microsoft Defender can inspect and block tool calls from Copilot Studio agents in real time, currently in preview (Microsoft Learn). Under the hood, the agent asks an external service for a verdict before each tool call. If no answer arrives within one second, Copilot Studio allows the call by default. In a regulated environment I would switch the error behavior to block (Microsoft Learn).

Limit context on purpose

What an agent passes on matters as much as what it retrieves. In Copilot Studio, a child agent always receives the parent’s context. For a connected agent you can turn off passing the conversation history, so it only receives the specific task (Microsoft Learn). That is what I would do in the example. The payroll agent needs the question about vacation days. It has no business seeing the earlier part of the chat where the employee may have mentioned being ill.

On the data side, the familiar controls apply. Copilot Studio only returns content the user can access, and for files encrypted by a sensitivity label the user also needs the EXTRACT usage right (Microsoft Learn). That protection depends on the query running with the user’s permissions. A tool that uses maker credentials sees whatever the maker sees.

Treat an MCP server like an API

The Model Context Protocol (MCP) defines how an agent discovers and calls tools. Authorization is explicitly optional in the specification. When a server implements it, the server acts as an OAuth 2.1 resource server: it must check that a token was issued for it and must not accept or pass on any other tokens (MCP specification). Whether a given server actually does that depends on its code. So I treat every MCP server like a third-party API and ask who runs it, what data it sees, how it authenticates and who approves it.

Copilot Studio connects MCP servers through a wizard that offers no authentication, an API key or OAuth 2.0. Because access runs through Power Platform connectors under the hood, data policies cover MCP servers too (Microsoft Learn). Agent 365 adds a second layer. Under Agents > Tools in the Microsoft 365 admin center, admins can block an MCP server for the whole organization. For supported servers, individual tools can be switched off as well, for example write and delete operations, while read operations stay available. This tool-level control is still rolling out and is enforced at runtime by the Agent 365 Tooling Gateway (Microsoft Learn).

The control plane: registry, identity, protection, audit

The tools so far live in several portals. The agent registry in the Microsoft 365 admin center pulls them together. Agent 365 has been generally available since May 1, 2026, and is licensed per user (Microsoft Learn). The registry lists agents from all platforms, including those registered in Entra, and with the right license it consolidates risk signals from Purview, Entra and Defender for each agent (Microsoft Learn).

Entra Agent ID provides the identity, with a sponsor, Conditional Access and ID Protection for agents. Purview captures prompts and responses in the unified audit log and surfaces them in DSPM for AI. For Agent 365 that explicitly includes agent-to-tool and agent-to-agent interactions (Microsoft Learn). Check licensing carefully. Conditional Access for agents requires Microsoft 365 E7, or Agent 365 together with at least Entra ID P1 or Microsoft 365 E3 (Microsoft Learn). Licensing terms change often, so verify the current version before you roll out.

Delegation without inherited permissions

Back to the payroll agent. Microsoft’s own guidance on multi-agent patterns says that a connected agent might have access to things the parent agent doesn’t, and that calling it should be treated like any other powerful action (Microsoft Learn). I turn that into three rules.

First, every tool in a connected agent uses end-user credentials unless there is a documented reason not to. Second, the setting “Let other agents connect to and use this one” stays off unless an agent is explicitly meant to be a building block. By default, any agent in the same environment can connect to it (Microsoft Learn). Third, agents with their own identity receive permissions through access packages with an expiry date. The sponsor is notified before access expires and has to request an extension actively. This is still in preview (Microsoft Learn).

Human approval for high-impact actions

Some actions no agent should take alone: payments, changes to master data, deleting records, changing permissions. Agent flows in Copilot Studio include human-in-the-loop actions for approvals and requests for information (Microsoft Learn). Multistage approvals combine manual stages with AI stages and conditions in between, but they are still in preview (Microsoft Learn). An AI stage can pre-sort routine cases. For high-impact actions I would always end with a human stage, so that the decision belongs to a named person.

Where the approval sits matters most. It belongs in the flow that performs the action. If it only exists in the agent’s instructions, the model decides once again whether to ask at all.

What this means for regulated environments

Organizations in scope of NIS2 in Germany must, under section 30 of the BSI Act (BSIG), among other things set up access control concepts and use multi-factor or continuous authentication (§ 30 BSIG). The law does not mention agents. I see no reason to treat an agent that reads from the HR system differently from a service account that does the same. That is my professional view, not legal advice.

For traceability, every action has to answer three questions: which user triggered it, which agents were involved, and under which identity the business system was called. The unified audit log covers a large part of this. Connected agents, however, produce separate transcripts that you have to correlate through identifiers in the telemetry (Microsoft Learn). If you may have to report an incident on a short deadline, build that query before you need it.

For recertification, agent identities belong in the same review cycle as service accounts. Sponsors and access packages with an expiry date make that possible in Entra, without anyone maintaining a spreadsheet.

A service provider adds one more question: who operates the runtime controls? Data policies, Conditional Access for agents and Defender real-time protection rules often sit with the provider, while approvals in agent flows sit with the customer’s business owners. Defender can, for example, block a tool call that would send email to an unsafe domain (Microsoft Learn). Who sees that alert at night, and who may then block the agent, has to be settled in advance. Multi-tenant agent management in the Microsoft 365 admin center (preview) makes blocking across tenants technically easy (Microsoft Learn). The authority to do it belongs in the contract.

Where Microsoft still has gaps

Conditional Access on the agent identity is currently evaluated only when a Copilot Studio agent runs in Microsoft Teams. Other channels still call connectors through the existing Power Platform flow (Microsoft Learn). On top of that, custom connectors, MCP servers and REST tools add no API permissions to the agent ID, so the Entra view is incomplete exactly where MCP comes in. Agent Builder agents get no agent ID at all.

The documentation does not describe how identity is passed from a parent agent to a connected agent. For the standard harness it only says that, depending on the authentication setup, you might need to share the connected agent with the end users as well. I would test this in my own tenant before relying on it. Several of the runtime controls above are also still in preview or rolling out, including Defender real-time protection for Copilot Studio, multistage approvals and tool-level blocking for MCP servers.

Five things you can check tomorrow

Check in the Power Platform admin center whether your production environments still allow maker-provided credentials. The agent inventory shows in the connectionProvider field (preview) which connector operations use them.
For your most important agent, list every connected agent and child agent and find out whether each one receives the conversation history.
Open Agents > Tools in the Microsoft 365 admin center and block every MCP server whose operator you don’t know.
Check in the Microsoft Entra admin center that every agent identity has a sponsor.
Pick one high-impact action an agent can perform today and put an approval into the flow in front of it.

Which frameworks you have to prove agent governance against, and who delivers which evidence, is the topic of part 4.

Sources

This post was prompted by a LinkedIn post from Rajeev Yadav.

AI Act, GDPR, NIS2 and ISO: which controls for Microsoft 365 agents count more than once

Thu, 29 Oct 2026 07:00:00 +0100

📝 As of October 2026

This post is not legal advice. It maps obligations from laws and standards to technical evidence in Microsoft 365. Whether your organization is in scope is a question for your legal team, data protection officer or counsel. English terms for German law are my own translations.

HR builds an agent in Copilot Studio that reads incoming applications, compares them with the job profile and suggests a ranking. Technically, that is an afternoon’s work. From a regulatory point of view, it has little in common with the travel expense helper from part 2.

The AI Act explicitly lists AI systems that analyze and filter job applications or evaluate candidates as high-risk (Annex III, point 4(a)). The exemptions in Article 6(3) for narrow or purely preparatory tasks do not apply once a system performs profiling (Regulation (EU) 2024/1689). Ranking people by their documents is likely to be exactly that. At the same time, the agent processes personal data, runs in a tenant that in regulated industries is often in scope for NIS2, and has to fit into the existing ISO 27001 certification. This fourth and final part of the series is about turning that into one set of shared controls rather than five separate projects.

Laws, standards and evidence

Gökhan Adamhanoglu describes AI regulation in the EU as a system with two layers: laws define what an organization owes, standards describe how it operates and proves it. For organizations that build and run agents in Microsoft 365, I add a third layer. Auditors and regulators ultimately ask for evidence: who approved the agent, what did it do and when, who reviewed its output? That evidence comes from the tenant: the agent registry, the audit log, Entra and Defender.

An example: the AI Act requires deployers to keep the logs of a high-risk system for at least six months. A management system standard requires the organization to define such rules and monitor them. Purview Audit provides the actual records. Once the three layers are connected, the same evidence serves several frameworks.

Which frameworks matter for M365 agents

The AI Act distinguishes providers, who develop an AI system, from deployers, who use it under their authority. All deployers have to address AI literacy (Article 4), and the transparency obligations in Article 50 have applied since 2 August 2026. The deployer obligations in Article 26 only cover high-risk systems, and the Digital Omnibus on AI, Regulation (EU) 2026/1744, moved them to 2 December 2027 for Annex III.

The GDPR requires a data protection impact assessment (DPIA) where processing is likely to result in a high risk. Article 35(3)(a) explicitly names systematic and extensive evaluation of personal aspects, including profiling, on which decisions are based (GDPR). As I read it, an agent that pre-sorts candidates falls under that.

In Germany, NIS2 has applied since 6 December 2025 through the revised BSI Act (BSIG) (BSI). AI is not mentioned, but Section 30 BSIG requires risk management for the IT systems an entity uses for its services, Section 32 sets out reporting obligations and Section 38 makes management accountable. I treat an agent with access to the HR system like any other IT system that reads from it (my professional view).

ISO/IEC 27001 and ISO/IEC 42001 are management system standards. ISO builds them on a common harmonized structure with the same core clauses so they can be integrated (ISO). If you run an ISMS under 27001, an AI management system under 42001 can extend it. 42001 adds AI-specific requirements, such as assessing an AI system’s impact on the people affected.

The Data Act, the Cyber Resilience Act and the Machinery Regulation don’t matter for most readers. The Cyber Resilience Act covers products made available on the market in the course of a commercial activity, which an internal agent is not. The Data Act is mostly about data from connected products and switching between cloud services, the Machinery Regulation about physical machines. If you sell agents or build them into products, look again.

Deployer or provider?

Under Article 3(3) of the AI Act, a provider is anyone who develops an AI system and places it on the market or puts it into service under its own name. Putting into service explicitly includes own use (Article 3(11)). Under Article 25, a deployer also becomes a provider by putting its name on a high-risk system, modifying it substantially, or changing the intended purpose of a system, including a general-purpose AI system, so that it becomes high-risk.

My reading of the wording: using Microsoft 365 Copilot to summarize email makes you the deployer of a system Microsoft provides. Building your own candidate screening agent in Copilot Studio means developing an AI system with an Annex III purpose and putting it into service under your own name. There is a good case that the organization is then both provider and deployer of a high-risk system. The Commission’s guidelines on classification are only available as a draft. Until they are final, I would document the role for every agent with an Annex III purpose and have legal review it.

Providers need, among other things, a quality management system, technical documentation, a conformity assessment and registration (Article 16). For Annex III point 4, conformity assessment is internal control without a notified body (Article 43(2)). Since 14 October 2026 there is a harmonized standard for the quality management system: EN 18286:2026 is cited in the Official Journal through Implementing Decision (EU) 2026/2274 and gives a presumption of conformity. Often the cheaper control is to scope the agent so it stays out of Annex III. An agent that answers candidates’ questions about the hiring process evaluates no one and, in my view, is outside Annex III point 4.

The fundamental rights impact assessment under Article 27 only applies to public bodies, private entities providing public services and deployers of certain Annex III point 5 systems (creditworthiness, life and health insurance). For a typical company’s HR agent, the DPIA remains the key document. Where Article 27 applies, the Omnibus allows cross-references to the DPIA (new Article 27(4)).

Where the frameworks overlap

The matrix is my own mapping: a filled dot for an explicit requirement, a ring for an indirect one.

Inventory and ownership. The GDPR requires a record of processing activities, Section 30(2) no. 9 BSIG asks for concepts for managing ICT systems, ISO 27001 for an inventory of assets. The AI Act assumes one: you can only meet deployer obligations for systems you know about. One entry per agent with owner, purpose, zone, Annex III classification and role as deployer or provider covers all four.

Risk assessment. The DPIA, the risk analysis under Section 30(2) no. 1 BSIG and both ISO risk assessments ask largely the same questions. Article 26(9) of the AI Act requires deployers to use the provider’s information for the DPIA. I keep one document per agent with a shared core and short sections per framework.

Logging. At least six months under Article 26(6), plus the data you need for a report under Section 32 BSIG. Purview Audit (Standard) keeps records for 180 days, which is right at the minimum. Audit (Premium) supports retention policies of up to one year, and up to ten years with an add-on license (Microsoft Learn).

Human oversight. Article 26(2) requires natural persons with the necessary competence, training and authority, and Article 22 GDPR restricts decisions based solely on automated processing. The approval belongs in the flow that performs the action, as described in part 3. Add a named role that reviews the ranking and may reject it.

Data protection and access. Access control appears in Section 30 BSIG, Article 32 GDPR and ISO 27001. The AI Act requires deployers to ensure that input data under their control is relevant and representative (Article 26(4)). In M365 that means end-user credentials, sensitivity labels and DLP.

Incident reporting. Three paths: Section 32 BSIG with an early warning within 24 hours, Article 33 GDPR with 72 hours, and Article 26(5) of the AI Act, which requires informing provider and authority without undue delay after a serious incident. A shared incident process therefore asks early whether an agent was involved.

Informing affected people. Workers’ representatives and affected employees must be informed before a high-risk system is used at the workplace (Article 26(7)), and so must people the system helps make decisions about (Article 26(11)). Add the GDPR information duties and Article 50(1): the provider of an agent that talks to people has to make that recognizable.

Training and AI literacy. Under the revised Article 4, providers and deployers have to take measures to support the AI literacy of their staff, without any specific level being required. Section 30(2) no. 7 BSIG requires training, Section 38(3) regular training for management, and both ISO standards require evidence of competence. One training for agent makers and owners serves all three.

Which M365 tool provides which evidence

Part 3 covers registry, identity and runtime protection in more detail. For evidence, what counts is this: the agent registry in the Microsoft 365 admin center holds the inventory, with the owner rules from part 2 (Microsoft Learn). Entra Agent ID with a sponsor shows who is accountable (Microsoft Learn).

Purview provides most of the evidence. Prompts and responses from Copilot Studio agents land in the unified audit log, DSPM shows data risks in AI interactions, and DLP and sensitivity labels apply to agents (Microsoft Learn). Compliance Manager has premium templates for the EU AI Act, ISO/IEC 42001, ISO/IEC 23894 and the NIST AI RMF, plus a template for ISO/IEC 27001:2022 (Microsoft Learn). For the DPIA there is Priva Privacy Assessments, currently in preview (Microsoft Learn).

Defender keeps its own agent inventory and groups agent alerts into incidents, which feeds a Section 32 report (Microsoft Learn). For human oversight, the approvals in agent flows from part 3 remain the tool.

Microsoft holds an ISO/IEC 42001 certification for Copilot, Copilot Chat, Copilot Studio and Foundry. Customers may use it in their own assessment, but their own implementation needs its own audit (Microsoft Learn). In supplier management the certificate is useful evidence, but it says nothing about your own HR agent.

Who delivers the evidence

The three models from part 1 also decide who has to produce which evidence.

In the intrinsic model (Agent Builder), Microsoft provides the evidence for the platform, such as the ISO 42001 certificate. Your organization documents what happens in the tenant: inventory and owners in the registry, the sharing settings and the permissions on knowledge sources.

In the configurable model (Copilot Studio), whoever configures the platform documents the configuration: environments, data policies, publishing approvals and pipeline history. If that is the service provider, this evidence is part of its service, for example as a regular report the customer can review without admin access of its own.

In the explicit model (Foundry), the organization provides almost everything itself, from model choice and evaluations to technical documentation. Compliance Manager can pull evaluation results from Foundry into an assessment automatically (Microsoft Learn). If the agent falls under Annex III, the provider obligations from the section above apply on top.

The service provider itself shows up in several frameworks. Section 30(2) no. 4 BSIG requires measures for supply chain security, explicitly including relationships with service providers. For managed service providers that are themselves in scope for NIS2, Section 30(3) BSIG refers to the technical requirements in the Commission’s implementing act. A provider that processes personal data on the customer’s behalf must, under Article 28(3)(h) GDPR, make available all information needed to demonstrate compliance and allow audits. And under Article 3(3) of the AI Act, a provider is also whoever has an AI system developed and puts it into service under its own name. If a service provider builds the candidate-ranking agent on behalf of a customer, my reading is that the provider role stays with the customer as long as the agent runs under the customer’s name. The contract should then define which documents the service provider supplies for the technical documentation.

Deadlines deployers should know

AI literacy has been an obligation since 2 February 2025, in its revised form since the Omnibus took effect on 27 July 2026. NIS2 has applied in Germany since 6 December 2025 without a general transition period, Article 50 since 2 August 2026. 2 December 2026 matters little for deployers: two new Article 5 prohibitions apply, plus a transition deadline for providers of generative systems on machine-readable marking.

For the HR agent, 2 December 2027 counts. From then on the Annex III high-risk obligations apply, including Article 26. AI in regulated products under Annex I follows on 2 August 2028. Under Article 111(2), high-risk systems put into service before that date are only covered after significant changes to their design. For agents whose instructions and knowledge sources change all the time, I would not rely on that.

What Microsoft doesn’t take off your plate

Microsoft provides tools and evidence. Responsibility for operating an agent lawfully stays with you. The Compliance Manager templates describe measures someone still has to implement and prove, and they consume premium licenses. Automated agent assessments in Compliance Manager are built on Microsoft Foundry, and Microsoft doesn’t describe a comparable integration for Copilot Studio agents.

Several building blocks are still in preview, including threat detection for agents in Defender and Priva Privacy Assessments. Agents built with Agent Builder don’t get an Entra Agent ID. Some things happen in no portal at all: deciding whether an agent falls under Annex III, informing workers’ representatives, management accountability under Section 38 BSIG, and the question of who in the organization can carry provider obligations.

Five things you can check tomorrow

Go through the agent registry and flag every agent that evaluates, ranks or helps make decisions about people.
For those agents, document whether your organization is the deployer or the provider, and have legal review it.
Check in Purview how long audit records for Copilot and agent interactions are kept, and whether 180 days is enough for you.
See which Compliance Manager templates you are licensed for, and extend your existing ISO 27001 assessment with the template for the AI Act or ISO 42001.
Add two things to your incident process: the question whether an agent was involved, and the GDPR and AI Act reporting paths next to Section 32 BSIG.

Agent governance in Microsoft 365 on DR.365

Agent Builder, Copilot Studio or Foundry: who owns the risk?

Three tools, three kinds of builders

Who carries the risk?

Questions to answer before anyone builds

The operator’s view

The administrator often works for someone else

The three models split between customer and provider

Shadow AI has a different weight

Five things to check tomorrow

How the series continues

Sources

Agent lifecycle: how much governance does a Copilot agent need?

The lifecycle by platform

Three zones instead of one process for everything

The seven phases at a glance

1. Identify

2. Assess and prioritize

3. Design and prototype

4. Validate and decide

The gate: Go, Change, Hold or Stop

5. Deploy and scale

6. Operate and monitor

7. Evolve or retire

Guardrails across all phases

Where it still falls short

Five things you can check tomorrow

Sources

Runtime agent governance: whose permissions does a delegated agent use?

Design time and runtime

Signing in to the first agent is not enough

Keep enforcement out of the prompt

Limit context on purpose

Treat an MCP server like an API

The control plane: registry, identity, protection, audit

Delegation without inherited permissions

Human approval for high-impact actions

What this means for regulated environments

Where Microsoft still has gaps

Five things you can check tomorrow

Sources

AI Act, GDPR, NIS2 and ISO: which controls for Microsoft 365 agents count more than once

Laws, standards and evidence

Which frameworks matter for M365 agents

Deployer or provider?

Where the frameworks overlap

Which M365 tool provides which evidence

Who delivers the evidence

Deadlines deployers should know

What Microsoft doesn’t take off your plate

Five things you can check tomorrow

References