Evaluate security and governance considerations

An administrator changes a data policy on Friday afternoon. On Monday a maker opens a Copilot Studio agent that has been live for months and finds the Publish button greyed out, an error banner across the top, and a knowledge source that still looks perfectly configured. Nothing in the agent changed. A control two levels above the agent moved, and the agent is now out of compliance with it.

That is the shape of almost every governance surprise in Copilot Studio, and the way out of it is to know where each control lives. Microsoft publishes the map itself: Copilot Studio governance is applied at three levels, the tenant, the Power Platform environment, and the agent, and each level has its own set of feature controls and its own set of maker access controls (Implement a zoned governance strategy^[1]). Tenant controls decide whether a capability exists in your organization at all: whether agents that use generative AI can be published, and who may reach the Copilot Studio authoring experience in the first place. Environment controls decide which of those capabilities reach one container of work, and who is even a member of it. Agent controls are the ones you hold as a builder: agent authentication, web channel security, and how the agent is shared.

The figure below stacks the three levels with the controls this page cares about at each.

A Power Platform environment is the unit that most of this hangs from. Microsoft describes environments as logical containers that define data boundaries, security roles, data policies, and lifecycle separation, and an environment determines where the agent's data lives, who can build or edit it, which connectors and integrations are allowed, and how development, testing, and production are isolated (Implement a zoned governance strategy^[1]). Every agent you build sits inside exactly one.

The second question: design time or runtime

Knowing the level tells you who can change a control. A second question tells you when it bites. Power Platform's own vocabulary for this is design-time versus runtime: design-time experiences are the maker experiences, and they limit which connectors a maker can interact with, so a blocked connector means the maker cannot save the app, flow, or agent that uses it. Runtime experiences are the ones where something is actually executing, and there the same policy change shows up as a broken connection and a failing call (Data policies^[2]).

That split matters because the two failures look nothing alike. At design time you get an error banner and a blocked publish. At runtime you get a live agent that suddenly cannot reach a system it reached yesterday. Every control on this page should be read twice: what does it stop me building, and what does it stop the agent doing once it is running.

What this page owns, and what its siblings own

Three neighbouring pages in this domain deliberately stop where this one starts. Plan an agent identity strategy settles who the agent thinks the caller is and whose credentials travel outward: the three agent authentication options, the two tool authentication values, and the sign-in point in the conversation. This page assumes that decision is made and asks a different question: given the identity plan, is the whole solution defensible enough to release. Plan channels and deployment owns channel security, the Direct Line secret and Direct Line token that decide which hosts may embed a published agent. That is a control on connecting clients, not user authentication, and this page does not re-teach it. Plan a responsible AI strategy owns content moderation and grounding quality; here, content moderation appears only as one tile in a status dialog.

Two pieces of Power Platform fluency ride through this page without being re-taught: solutions as the container that carries components between environments, and Dataverse security roles as the thing that grants privileges inside one. Both appear below only where a security decision hangs off them.

One boundary is worth stating plainly because it decides how much of this article is your job. Creating data policies, provisioning environments, attaching security groups, and configuring Microsoft Purview are Power Platform admin center and Microsoft 365 admin center tasks performed by an administrator. A builder's work is the other half of each seam: recognizing which control produced a symptom, proving it with the evidence the product gives you, testing the whole runtime path after a change, and asking for one specific adjustment rather than a general exemption. Everything below is written from that seat.

A data policy is a Power Platform guardrail that classifies connectors and forbids data moving between the classifications. Administrators create them in the Power Platform admin center, and the classification has exactly three values: Business, Non-business, and Blocked (Configure data policies for agents^[3]). The rule that follows from the classification is the one to memorize: within a data policy, connectors must be in the same data group, because data cannot be shared among connectors that are in different groups. A connector is therefore not only blockable, it is also incompatible with a connector filed under a different group, and both outcomes stop an agent that needs the pair.

Two defaults do most of the damage in practice. First, connectors introduced after 2019, which includes surfaces such as Chat without Microsoft Entra ID authentication in Copilot Studio and Direct Line channels in Copilot Studio, are likely to land in the default Non-business group, and in many organizations the Non-business group is automatically blocked. Second, enforcement is no longer optional anywhere: since early 2025 data policy enforcement is in effect for all tenants, agent exemption is no longer supported, and agents that were previously exempted are all subject to enforcement. An agent that has been running for two years carries no grandfather clause, so "it published fine last year" is not a design assumption you can make.

Copilot Studio's connectors are mostly not connectors

Most of what a data policy controls in Copilot Studio is not a wrapped API. Power Platform calls these virtual connectors: entries that appear in data policies for administrators to control but are not based on a RESTful API, and Microsoft provides several of them specifically for governing Copilot Studio (Data policies^[2]). Blocking one turns a Copilot Studio feature off rather than cutting a data path.

That is why the list of things a data policy can stop reads like a list of agent capabilities rather than a list of services. Blocking Chat without Microsoft Entra ID authentication in Copilot Studio forces every agent in scope to use Authenticate with Microsoft or Authenticate manually, because No authentication stops being selectable. Blocking Knowledge source with SharePoint and OneDrive in Copilot Studio, Knowledge source with public websites and data in Copilot Studio, or Knowledge source with documents in Copilot Studio removes those knowledge types. Blocking the HTTP connector stops the HTTP request node. Skills with Copilot Studio blocks skills, the per-channel entries block publication to Microsoft Teams + Microsoft 365 Channel in Copilot Studio, Direct Line channels in Copilot Studio and the rest, and blocking the Microsoft Copilot Studio connector itself stops event triggers (Configure data policies for agents^[3]). That set is the documented list of common use cases rather than the full inventory; Microsoft notes that the supported connector list in the admin center covers a few more.

Two of these have knock-on effects worth carrying into a design review. Blocking Power Platform connectors as tools also blocks access to tools in connected Model Context Protocol (MCP) servers, because those rely on Power Platform connectors for connectivity. And if makers do not configure a channel that is not blocked, or administrators do not allow any channel at all, agents cannot be published. There is also a softer option than blocking: for SharePoint, public websites, and HTTP, endpoint filtering lets an administrator allow or deny specific endpoints instead of removing the capability, which is usually the change worth asking for.

What actually happens when the policy changes

A policy change is not instant and it is not only about you. Power Platform runs a defined sequence: the configuration is saved, cascaded to every environment in the tenant, and then resources in each environment periodically check for updated policy configurations. When a change is detected, every app, flow, and chatbot is evaluated against the policy; anything that violates it is put into a suspended or quarantine state so it cannot operate; connections are scanned and set to disabled where the whole connector is blocked; and anything already running that tries to use an inactive connection, action, trigger, or MCP server fails at runtime (Data policies^[2]). The figure below traces that sequence.

The timing is the part that catches teams out. Microsoft states that in most cases full enforcement lands within an hour, and that in the most extreme cases the latency is 24 hours. So a clean test run shortly after an administrator saves a policy proves very little, and a release plan that schedules "verify after the policy change" thirty minutes later is scheduling a false pass. Against that, Copilot Studio supports data policy enforcement in real time in the authoring experience, so makers and users see error messages for a violation as soon as it is enforced for them.

The takeaway for a builder is small and firm. You do not author the policy, but you own two things: knowing which capability each block removes, so you can name the connector you need rather than asking for an exemption that no longer exists, and re-validating after any policy change rather than assuming the old result still holds.

The single most useful skill on this objective is reading a violation report instead of guessing. When a data policy blocks something your agent uses, Copilot Studio shows an error banner with a Details button; on the Channels page you expand the error link and select Download, and the details file contains one row describing each violation (Configure data policies for agents^[3]). While a violation stands, the Publish button becomes unavailable. That file is the artifact to take to the administrator, and it is also what tells you whether you are looking at one problem or five.

A policy can block a dependency anywhere in the path

The reason to download the file rather than reason from the symptom is that a data policy can reach many different parts of an agent's runtime path, and those parts fail independently. Work the whole path deliberately:

• Agent settings. With unauthenticated chat blocked, No authentication and some manual authentication options simply stop appearing in the Authentication configuration page, and the agent will not publish until it uses Authenticate with Microsoft or Authenticate manually.
• Knowledge sources. Removing a blocked source from the Knowledge page is not always enough. The violation file records a row for the knowledge source and a row for each generative answers node that uses that knowledge source, so a node still pointed at the removed source keeps the publish blocked.
• Tools. A Tool node built on a blocked Power Platform connector fails validation when you try to publish, and blocking those connectors also blocks tools in connected MCP servers.
• Agent flows and HTTP. A violation is recorded if the HTTP connector is blocked, if it sits in a different data group from the other connectors in the policy, or if the connector is allowed but the specific endpoint is denied by endpoint filtering. Three different causes, one symptom.
• Channels. If a channel is blocked you cannot publish to it, and if no channel is available the agent cannot be published at all.
• Triggers. A blocked Microsoft Copilot Studio connector produces a detailed message in the Triggers section of the Overview page naming the data policy, and it also stops automated evaluations that run under an authenticated account.

Why the test pane is not the check

The obvious way to confirm an agent still works is to type a few questions into the Test your agent pane (Microsoft's docs also call this surface the Test panel; one thing, and this page uses the first name throughout). It is a weak test for policy impact for two reasons that both come back later on this page. It exercises only the topics you happen to try, so a blocked dependency in an untouched branch stays invisible. And it runs as you, the signed-in maker, which is a different identity with different access from the people who will use the agent. Microsoft states the second point directly for one case: users who do not have access to flows in a shared agent can still run those flows by using the Test panel in Copilot Studio (Share agents with other users^[4]). A pane that can succeed where a real user would fail cannot be the thing that clears a release.

So treat a policy change as a trigger for re-validation, not as a notification. Re-check every knowledge source, tool, agent flow, and channel the agent depends on, re-publish, and re-test in the channel the audience actually uses. And because full enforcement can take up to 24 hours to cascade, run that pass after the change has settled rather than immediately after the administrator clicks save. Documenting a prohibited connector in the project wiki while leaving it available in the environment is the version of this that fails silently: the wiki is not enforced, the policy is, and only one of them will stop the next maker.

Microsoft's recommendation for a governed Copilot Studio project is unusually specific: manage user access to environments through Microsoft Entra ID groups, and only agent authors and just-in-time administrators should have access to your environments and data stores; manage security role assignment through Microsoft Entra ID group teams, using group teams inside each Dataverse environment to assign security roles to users; and assign licences to users through Entra ID groups rather than individually (Secure your Copilot Studio projects^[5]). Three separate recommendations, all pointing at the same idea, and they are easy to blur into one. They are not one. They are two layers that have to line up.

Layer one: membership

An environment security group is a Microsoft Entra security group associated with a Power Platform environment, and it decides which licensed users become members of that environment at all. The behaviour is worth learning as a set of rules rather than a description, because each one shows up as a different surprise (Control user access to environments with security groups and licenses^[6]):

• Adding a user to the group adds them to the environment; removing them from the group disables them in the environment.
• Associating a group with an environment that already has users disables every user in that environment who is not a member of the group.
• If an environment has no associated security group, all users with a Dataverse licence are added and allowed in it.
• Security groups cannot be assigned to default and developer environment types, and Microsoft recommends removing one if you already added it, because the default environment is intended to be shared with all users in the tenant.
• Members of a nested security group are not pre-provisioned or automatically added to the environment. They can be brought in by creating a Dataverse group team for the nested group.

That last rule is the first place the two layers touch. The second is sharper still, and it is the most common way a correct-looking configuration grants nothing: if your environment has a security group, you must add the group team's Microsoft Entra group as a member of that security group for the group team's users to be able to access the environment (Manage group teams^[7]). A group team whose Entra group sits outside the environment security group is a role assignment attached to people who are not members of the environment.

Layer two: authorization

A group team is a Dataverse team backed by a Microsoft Entra group. It can own records and can have security roles assigned to it, and team members are derived dynamically, added and removed when they access the environment, based on their Entra group membership. Both Entra group types, Security and Microsoft 365, can be used, with membership type Assigned or Dynamic User; Dynamic Device is not supported (Manage group teams^[7]).

The operational payoff is exactly the one a rotating project team needs. Once the group team and its security role exist in an environment, a new person needs only to be put in the Entra group and given the licence; they can access the environment immediately, without an administrator adding them or assigning a role individually. When someone is removed from the group they lose their access rights the next time they access the environment. Two details keep this honest rather than magical. Privileges are derived at run time from the group team's role, and the member's Entra group memberships are cached at sign-in, so a membership change is not reflected until the next sign-in or until the cache refreshes after eight hours of continuous sign-in. And the member list shown for a group team displays only users who have actually accessed the environment, not everyone in the Entra group, so a short list is not evidence of a short group.

The figure below shows the two layers side by side and the rule that joins them.

Which security role

Membership and role assignment settled, the remaining question is which role. To author agents, assign the Environment Maker role; if a person needs a different set of permissions, use another predefined role or a custom one. Microsoft publishes a role-to-privilege mapping across the three Dataverse tables Copilot Studio uses; five of its seven rows are the ones that matter here, and the interesting column is the last one (Secure your Copilot Studio projects^[5]):

Security role	Copilot	Copilot Subcomponent	Conversation Transcript
System Administrator	Organization (CRUD)	Organization (CRUD)	Organization (CRUD)
System Customizer	Organization (CRUD)	Organization (CRUD)	None
Environment Maker	User (CRUD)	User (CRUD)	None
Bot Transcript Viewer	None	None	User (Read)
Bot Contributor	User (Read)	User (CRUD)	None

Environment Maker carries no access to conversation transcripts at all, which is the separation the last section of this page builds on. Note also that when you create an agent, Copilot Studio creates a team and shares the agent and its subcomponents with that team. That team is an ordinary Dataverse team for one agent, not a group team: nothing about it is bound to a Microsoft Entra group. Transcripts are implicitly shared with the parent agent's team, but only users with read access on the Conversation Transcript table can actually reach them. Finally, and separately from all of the above, every licensed user still needs at least one security role in an environment before they can access data there, whether or not they are in the security group.

The shape to carry away: access here is granted twice and lost twice. The environment security group decides who exists in the environment; the group team's security role decides what they may do once inside. Break either link and the person is locked out, which is why a correct-looking role assignment can still grant nothing.

A healthy application lifecycle management (ALM) strategy includes at least three environments: development, test, and production. A developer changes the agent in development and promotes it to test; if testers find bugs, the fix happens in development and the agent is promoted again; once testing passes, it is deployed to production (Establish an Application Lifecycle Management (ALM) strategy^[8]). Two configuration facts go with that shape: production is configured as a production type environment while every other environment, development and test included, is configured as a sandbox type; and every environment is secured by applying an environment security group to limit access to its members.

That second point is why the default environment is the wrong home for a governed project, and the reason is mechanical rather than stylistic. Security groups cannot be assigned to default and developer environment types, and the default environment is intended to be shared with all users in the tenant (Control user access to environments with security groups and licenses^[6]). Every access control in the previous section therefore has nothing to attach to. The fact that components in the default environment can still be added to a solution makes it look like a viable development environment; it is a packaging capability, not an isolation boundary, and the two are unrelated.

What travels, and what you rebuild

Solutions transport artifacts and customizations across environments, environment variables carry environment-specific settings, and connection references carry environment-specific connections and credentials. Microsoft's ALM golden rules for Copilot Studio are short enough to keep in your head: do not customize outside a development environment; always work in the context of solutions; use a custom publisher and prefix; create separate solutions only when components need to deploy independently; use environment variables for settings and secrets that change across environments; export and deploy solutions as managed, except when setting up a development environment; and consider automating ALM for source control and automated deployments (Establish an Application Lifecycle Management (ALM) strategy^[8]).

The governance-relevant half of ALM, though, is the exception list. Copilot Studio has several items that are not solution-aware, do not follow the normal solution deployment process, and require post-deployment steps in the downstream environment: Azure Application Insights settings, manual authentication settings, Direct Line and web channel security settings, deployed channels, and sharing, whether with other makers or with end users. The figure below shows the promotion path with that exception list attached.

Read that list as a security checklist, not a deployment inconvenience: every item on it is a control. Promote an agent to production and its channel security does not come with it. Its manual authentication configuration does not come with it. Neither does its sharing. If nobody re-applies them, production is running with whatever was configured there before, or with nothing. This is the specific reason a promotion is not a release: the solution moved the agent, and every governance setting that is not solution-aware still has to be set, checked, and recorded in the target environment.

The deployment mechanism is a separate choice with three sanctioned options, in rising order of setup cost: Pipelines in Power Platform for Copilot Studio, GitHub Actions for Power Platform, and Azure DevOps. Create an ALM solution and Parameterize agent environments cover solution structure and environment variables; what belongs here is the governance consequence. Deploying changes from development to test to production should require reviews and be part of a gated process, and data policy configuration is expected to differ by stage: strict policies in personal development environments, more relaxed ones in dedicated development, test, and production environments after review (Secure your Copilot Studio projects^[5]). That direction surprises people who expect production to be the most locked-down environment. It is not a claim that production is less secure; it is a claim about where experimentation is constrained, because a personal development environment is where an untrained maker is most likely to wire something unreviewed to something sensitive. It is also a different axis from the restrictive project-environment policy this page opened with. That policy is restrictive relative to one project's approved runtime path; strict versus relaxed here describes how much unreviewed building an environment tier permits at all. A dedicated project environment can be relaxed on Microsoft's axis and still block every connector your project never asked for.

Lead with the rule, because it is the one this section exists for: anyone who can edit an agent can read any secret that agent can reference, no matter how well the secret is stored.

The storage mechanism is genuinely good. An environment variable of data type Secret with secret store Azure Key Vault keeps the value in the vault and stores only a reference in Dataverse; Microsoft notes that these secrets are not available for use in other customizations or generally via the API (Use environment variables for Azure Key Vault secrets^[9]). Setting one up for Copilot Studio takes three grants and one tag, and each of them is a place a review can go wrong:

• The Azure subscription holding the vault must have the Microsoft.PowerPlatform resource provider registered, and the vault must be in the same tenant as the Power Platform subscription.
• The person creating or using the secret environment variable needs the Key Vault Secrets User role on the vault, and so does the Dataverse service principal.
• Copilot Studio needs its own grant: assign Key Vault Secrets User to the Microsoft Copilot Studio Service identity.
• The secret itself carries a tag naming who may use it. An AllowedBots tag lists specific agents, with the value formatted as {envId}/{schemaName} and multiple agents separated by commas; an AllowedEnvironments tag instead allows every agent in a named environment.

Microsoft also recommends a separate vault per Power Platform environment to minimize the blast radius of a breach, which lines up neatly with the three-environment shape from the previous section. The figure below follows that chain from the stored secret to the agent that resolves it.

Where the boundary actually is

Now the part that decides who gets Editor permission on the agent. Microsoft's own walkthrough for using a secret environment variable in Copilot Studio ends by having you add a Send a message node, insert the environment variable through the Environment tab of the variable picker, and test the topic; the documented result is that the value of your secret is shown in the test panel (Use environment variables for Azure Key Vault secrets^[9]). That is a supported feature being used as designed, and it is also the whole argument. The vault protects the secret from people who cannot edit the agent. It does not protect it from people who can, because a maker with edit rights can add one node and read the resolved value out of a conversation.

This is a good place to be precise about what Key Vault buys you, because a design review will hear the opposite claim. It buys you: the value is never pasted into a topic or a solution file, so it does not travel in an export; it rotates in one place; access to it is auditable in Azure; and the same solution binds to a different secret in each environment through the variable. It does not buy you: protection against an authorized editor of the agent. Microsoft's security recommendations put both halves together, telling you to store secrets in a secure location such as Azure Key Vault and to restrict who can create, edit, and publish agents in each environment (Review the manage checklist^[10]).

The practical consequence for an agent that references secrets is a short list. Keep the Editor grant to the people who genuinely author it, remembering from the next section that Editor cannot be given to a security group at all. Prefer a scoped-down service identity in the vault over a broadly privileged one. And expect the audit log to be your evidence here: Copilot Studio logs EnvironmentVariableCreate, EnvironmentVariableUpdate, and EnvironmentVariableDelete events, so a change to which secret an agent points at is a recorded action rather than an invisible one (View audit logs for admins, makers, and users of Copilot Studio^[11]).

Every access grant on an agent answers one question: what should this person be able to do that they cannot do now. Copilot Studio has four distinct answers, and choosing the wrong one is the most common over-grant on this objective, because the strongest grant is also the easiest one to reach for.

Two kinds of object are in play and the word role covers both. A sharing role is a Copilot Studio grant on one agent, made from that agent's Share pane. A Dataverse security role is an environment-level grant made in the Power Platform admin center. Several vendor role and privilege names also still carry the older word bot, as in Bot Transcript Viewer and the ChatBotReaders privilege; those are the current names for agent permissions, so this page uses them verbatim.

Share for chat grants permission to converse with the agent and no authoring permission. It can target individual users, a security group, or everyone in the organization (Share agents with other users^[4]). Under the covers a person needs the ChatBotReaders privilege to chat with agents in an environment; the Environment Maker security role includes that privilege, which is why sharing an agent with someone who lacks sufficient permissions assigns them Environment Maker. Administrators can also create custom security roles carrying ChatBotReaders and assign them before sharing, which is the lighter-touch option when Environment Maker is more than the person needs.

Share for collaborative authoring gives permission to view, edit, configure, share, and publish the agent. Coauthors cannot delete it. Three constraints go with the grant: you can share for collaborative authoring only with individual users in your organization, never a group; each coauthor must have the Environment Maker Dataverse security role, and if they do not yet have it, the person sharing needs the System Administrator role so Copilot Studio can assign it on their behalf; and if the user was not already a member of the environment, the agent can take up to ten minutes to appear for them.

Analytics Viewer is a sharing role that grants access to the Analytics page for one specific agent. Its holders can view the page and its metrics and open the agent directly on it, and cannot edit or share the agent or reach topics, actions, settings, testing tools, or publishing. It can only be shared with individuals, not with groups of users. Agent viewer is the parallel role for evaluations: it grants access to the Evaluation page, letting the holder view and run evaluation test sets from other makers and rename, cancel, and delete evaluations, without permission to the agent itself. Both are assigned from the agent's Share pane, and you must be an agent owner to assign either.

Analytics and transcripts are two permissions, not one

This is the distinction most worth getting right, because the two halves live in different products. Much of the value of the Analytics page comes from drilling into the data behind a metric: selecting a response quality value in the Generated answer rate and quality chart, for example, lists the user questions behind it. Microsoft is explicit that all drill-downs to information from the conversation transcript require additional permissions, and that a user needs both the Analytics Viewer sharing role in Copilot Studio and the Bot Transcript Viewer security role for Microsoft Dataverse, where transcript data is stored (Share agents with other users^[4]).

The two grants differ in more than name. Analytics Viewer is a Copilot Studio sharing role scoped to one agent. Bot Transcript Viewer is a Dataverse security role assigned at the environment level in the Power Platform admin center, and a user who holds it can access conversation transcripts for every agent in the environment that they create or that is shared with them. By default only administrators have it, and, as the role table earlier on this page shows, makers with Environment Maker do not automatically get transcript access. Because the grant is environment-wide and its subject is conversation content, Microsoft advises granting transcript access only to users with appropriate privacy training. If you need tight control over who can read transcripts, the documented answer is to create a separate environment for your agents rather than to try to narrow the role.

Sharing rules put a ceiling on all of this

An administrator can cap what makers are allowed to grant. Sharing rules are a Managed Environments control in the Power Platform admin center, configurable for one environment or applied at scale through environment groups and rules (Control how agents are shared^[12]). The controls decide whether people may grant Editor permissions when sharing, whether they may grant Viewer permissions, whether sharing is restricted to individuals with no security groups, and, when it is, the maximum number of viewers per agent. Editors can edit, configure, share, and publish; viewers can only chat.

Four details keep this from behaving the way people assume. Editor permissions can only be given to individual users and never to a security group, which is a hard product constraint rather than a policy choice. Sharing limits apply only to agents that require authentication. Rules are enforced when someone tries to share, so they do not remove access from people who already had it; an agent that falls out of compliance can only have sharing removed until it complies again. And after rules are set it can take up to an hour before they start being enforced. One last item, carried over from the previous section: sharing is not solution-aware, so none of these grants travel with a promotion and all of them have to be re-established in the target environment.

A governance team reviews the agents in one environment and finds a familiar pattern: several makers configured their tools with their own credentials, so everyone using those agents reaches data through one person's access. Nothing is broken, nothing is unsupported, and the data policy permits every connector involved. The authorization boundary for hundreds of users is simply one maker's account, and nobody chose that deliberately.

Least privilege on an agent is not a single setting. It is a property of a chain, and the chain has four links that are configured in four different places: the user's identity to the agent, the credentials the tool presents outward, the permissions on the underlying source, and which connectors the environment allows at all. The figure below lays out those four links and what each one decides. Microsoft's checklist phrases the goal as enforcing least-privilege access for makers, admins, and service accounts, and its security recommendations add the mechanism: use delegation, impersonation, or filtering of data access in the context of an end user (Review the manage checklist^[10]).

The credential link is where the boundary usually moves

By default a connector tool asks the person using the agent for their own credentials for the associated service, which means the target system applies that caller's own permissions. Switching a tool to Maker-provided credentials replaces that with the maker's single identity for every caller, and it first requires the agent to use an authenticated channel (Use connectors in Copilot Studio agents^[13]). Copilot Studio treats the switch as a security-relevant change: the automatic security scan warns a maker when the credential mode is changed away from End user credentials (Automatic security scan in Copilot Studio^[14]).

Sometimes Maker-provided credentials is the right answer: Microsoft documents it for shared resources, or where users should not need individual access to the external service (Add tools to custom agents^[15]). That is a legitimate design, but it converts a per-user authorization model into a shared one, so it comes with obligations: scope the account to the minimum the scenario needs, state in the review that per-user permissions are no longer being enforced downstream, and make sure the agent itself restricts who can invoke the affected tool. The full comparison of the two credential modes belongs to Plan an agent identity strategy; what matters here is that the choice is a governance decision with a named owner, not a per-tool convenience.

Permission trimming, and testing it honestly

When the source enforces permissions itself, the agent inherits that enforcement and hands back only what the asking user was already allowed to see. That inheritance is what people mean by permission trimming, and it is the most reassuring link in the chain. With SharePoint as a knowledge source the agent surfaces only content the user has permission to access; if the user does not have permission, the agent responds with "no response", and the user needs at least Read permission on the SharePoint site or list (Add SharePoint as a knowledge source^[16]). This works because, once the agent is published, calls that use generative answers are made on behalf of the user chatting with the agent, using the agent authentication settings you configured.

Read that mechanism carefully and the testing rule falls out of it. If retrieval runs as the person chatting, then testing as yourself tests your own permissions. In the Test your agent pane the person chatting is the maker, so a maker with broad access to a SharePoint site will see exactly the content a restricted user must not see, and will see it working correctly. The pane is not lying; it is answering a different question. The same asymmetry appeared earlier with agent flows, where users without access to a flow can still run it from the Test panel.

So verify permission trimming with representative accounts. Sign in as a user who holds no permission on the restricted area and confirm the agent declines rather than answers; sign in as a user who holds partial permission and confirm the boundary falls where the source says it should. Microsoft's testing guidance names this as its own category, security and compliance testing, defined as validating role-based access control (RBAC), conditional access, and sensitivity label enforcement while ensuring no confidential data is leaked, and it also asks you to confirm that production knowledge sources and documents are the ones actually referenced by production agents, especially where development and test used different ones (Design a testing strategy for your agents^[17]).

Two failure modes deserve naming because they are quiet. A renamed SharePoint site or folder can break the existing source link and cause a permission gap, after which the agent may fail to reach the knowledge base until an administrator grants permissions on the renamed location and generates a new link. And a knowledge source that is grounded correctly but whose credential mode is wrong will look fine in every functional test and still be reaching the data as the wrong identity, which is why the credential mode and the trimming test are two checks rather than one.

Copilot Studio gives makers a single agent-level readout of whether published agents comply with security and governance standards, in the Protection status column on the Agents page. Its three values are Protected, Needs review, and Unknown. Protected means no immediate action is required based on detected signals and shows a green shield; Needs review means either the agent's policies are violated or authentication is inadequate (Agent runtime protection status^[18]).

Selecting the status opens a summary dialog that breaks the agent's protection profile into three categories, each carrying the same three possible statuses: Authentication, Policies, and Content moderation. The dialog also shows the number of messages blocked because of potential threats, policy violations, and content moderation settings, and all published agents automatically have threat detection enabled and display an Active label. The rollup rule is the part to remember: if either Authentication or Policies is in violation of the security standards defined by the agent's setup, that category shows Needs review and the label rolls up to the single agent-level status. Content moderation does not affect the protection status directly; it contributes statistics and trends only. The figure below shows that rollup.

Each category also tells you where to go. Authentication indicates whether the agent requires end-user authentication or is public, and links to Settings > Security > Authentication. Policies reflects violations of policies set by administrators in the Power Platform admin center and offers a Review errors link, which is the same violation evidence discussed earlier on this page. Content moderation links to Settings > Generative AI. Behind the summary, a Security analytics dialog charts blocked messages by reason and a session block rate trend over a selectable window of the last 7, 14, or 30 days.

The scan that fires before you publish

A second, narrower check runs at publish time. Agents are secure by default, but a maker can change a secure default for a valid scenario without knowing the risk, so Copilot Studio automatically runs a security scan and warns the maker before publishing. It warns on exactly three changes to secure defaults (Automatic security scan in Copilot Studio^[14]):

• Setting agent authentication to No authentication, which lets anyone with the link interact with the agent. The default is Authenticate with Microsoft.
• Selecting Maker-provided credentials under Credentials to use for connectors and flows. The default is End user credentials.
• Sharing the agent with everyone in the organization. A new agent is shared with no one.

That is a warning, not a gate, and the list is deliberately short. It catches three specific regressions from Microsoft's defaults, and it knows nothing about your organization's standards, your data classification, or what the agent is actually grounded in.

Why the release gate is still yours

Put the two together and the boundary of the product's help is clear. The publish gate proves no data policy is currently violated. The protection status proves authentication exists and no policy violation is outstanding. The security scan proves three named defaults were not silently reversed. None of them evaluates whether your authentication choice meets the organization's standard, whether the agent is shared more widely than the project agreed, whether tools run under a shared identity, whether a restricted user can pull back content they should not see, or whether the region the data is processed in satisfies a regulatory commitment.

Microsoft's readiness checklist is a reasonable shape for the gate you build instead, and its security and governance sections read as questions rather than settings. Among them: did you enforce least-privilege access for makers, admins, and service accounts; did you restrict who can create, edit, and publish agents in each environment; did you assign and document who can approve deployments; did you separate environments for development, testing, and production; did you apply data policies aligned to your risk profile; did you approve which connectors, tools, and MCP servers are allowed; did you define a review process before agents move to production; and did you assign owners responsible for long-term maintenance (Review the manage checklist^[10]). Geographic data residency belongs in the same pass, since it governs where data is stored, processed, and managed and is how a project meets regional requirements (Secure your Copilot Studio projects^[5]). A successful publish answers none of those questions, which is the whole reason the gate has a named owner and a written outcome.

Release is where governance stops being a configuration exercise and becomes an evidence exercise. The question a compliance conversation actually asks is not "is the agent secure" but "who changed its authentication, when, and who approved it", and answering that needs records that were being collected before anyone asked.

The good news is that the collection is not something you switch on. Administrative activities for Copilot Studio are enabled by default on all tenants and you cannot disable activity collection, although the audit logs themselves can be disabled in Microsoft Purview and retention policies can prevent retention of user message text and response text (View audit logs for admins, makers, and users of Copilot Studio^[11]). Microsoft's stated reason for auditing is the one to quote in a design review: changes to the content and settings of an agent can affect security and agent behaviour, and auditing those actions helps mitigate failures, adhere to compliance requirements, and address security threats.

Three record types, three different permissions

The most common governance mistake after release is treating one of these as if it were another.

Audit logs in Microsoft Purview record who did what to the agent. Copilot Studio logs authoring and administrative actions as discrete events, and the security-relevant ones are easy to name: BotCreate and BotDelete, BotUpdateOperation-BotAuthUpdate for a change to authentication settings, BotUpdateOperation-BotShare for a share, BotUpdateOperation-BotPublish for a publish, BotAppInsightsUpdate for a telemetry configuration change, and the environment variable create, update, and delete events. Because logging happens at the SDK layer, one action can produce several events. A second, important limit: the audit events do not include the full text or transcript of the interaction between a user and the agent, only the transcript thread ID. Developers can also reach these logs through the Office 365 Management API, and administrators can monitor and receive alerts on agent activities through Microsoft Sentinel by ingesting Purview audit logs (Monitor operations, compliance, and capacity^[19]).

Conversation transcripts in Dataverse record what was said. A transcript is written when an agent interacts with an end user or with a maker using the test chat, and it carries the conversation plus metadata such as start and end time and the triggered topic. That is not universal: transcripts are not written at all for Microsoft Dataverse for Teams environments, Dataverse developer environments, or Microsoft 365 Copilot agents (Control how transcripts are retained and accessed^[20]). Access is a Dataverse question, not a Copilot Studio sharing question, as the previous section established: Environment Maker does not include it, Bot Transcript Viewer does, and an administrator can additionally control at environment level whether owners and editors may see session transcripts at all and whether transcripts are saved to Dataverse in the first place. Turning saving off means no transcripts exist for conversations after that point, so this is a control a builder needs to know about before promising a retrospective. Transcripts have a default retention period in Dataverse that an administrator can extend, and organizations needing longer retention are pointed at exporting the raw data to a cheaper store such as Azure Data Lake Storage Gen2 through Azure Synapse Link for Dataverse.

Analytics in Copilot Studio records how the agent performed. It is aggregate by design: usage and key performance indicators, with drill-downs into the questions behind a metric that themselves require transcript permission. Analytics is the wrong artifact to produce as the audit record for an individual sensitive transaction, because the chart is a count and the per-action evidence is in the audit log while the conversation content is in the transcript. Reaching for the Analytics page because it is the one you can already open is exactly how that substitution happens.

Deciding who reads it

Evidence nobody reads is not a control. Microsoft's monitoring guidance pairs the tooling with process questions: whether audit logs capture sensitive operations, whether conversation transcripts are reviewed for quality and safety issues, whether alerts are configured for integration failures and workflow errors, whether a review process exists for hand-offs and escalations, and whether data retention and deletion are compliance-aligned (Review the manage checklist^[10]). Answering those is a naming exercise: which team reviews which record type, on what cadence, and where a finding goes when it turns out to be an incident. Where the security operations team owns detection rather than the makers, the documented route is Sentinel, with custom detection rules built over Copilot Studio events rather than a maker watching a dashboard.

Runtime telemetry is the fourth stream and it is the one you can wire yourself. An agent can send custom events to Application Insights, giving visibility into logged messages and events sent to and from the agent, the topics triggered during conversations, and custom telemetry events your topics send. That is a build task rather than a governance task, and it has its own page: Monitor agents with Application Insights. What belongs to this page is only the decision that production agents have telemetry at all, which the readiness checklist asks as its first monitoring question.