Copilot agents and data access in Microsoft 365

Microsoft says Copilot agents only surface organisational data that the person using them can already view, with one exception its documentation flags clearly: a Copilot Studio tool set up with the builder’s own (maker’s) credentials. That makes data access a common question once people in an organisation start building their own agents. An agent is a version of Copilot set up for a particular job, such as answering HR policy questions from a SharePoint site or looking up orders in a business system. This page explains what Microsoft 365 Copilot agents and Copilot Studio agents can reach, how knowledge sources, connectors and credentials affect that, and the admin controls Microsoft documents.

Why it matters

Agents are easy to create. Microsoft’s agent management page lists many platforms for building them, including Microsoft Copilot Studio, SharePoint, Agent Builder, AI Foundry and the Agents Toolkit, as well as non-Microsoft agent platforms. Each one can be connected to documents, websites and other systems, then shared with colleagues.

That makes two questions important for anyone running a tenant:

• Whose access does the agent use? The person chatting with it, or the person who built it?
• Who can see, share and switch off agents? And does anyone know how many exist?

The answers depend on how the agent was built and configured, which is why Microsoft’s documentation covers both data access and admin governance.

What agents can access, as Microsoft describes it

Microsoft’s data, privacy and security page for Microsoft Copilot states that Copilot “only surfaces organizational data to which individual users have at least view permissions.” When an agent is needed, Microsoft says Copilot sends it a search query on the user’s behalf, based on the user’s prompt, Copilot activity history and “data the user has access to in Microsoft 365.”

Microsoft’s planning page for Copilot extensibility puts it another way: “A plugin doesn’t grant a user access to data that the user or component isn’t otherwise authorized to access.” It adds that Microsoft Graph and Microsoft 365 services “enforce the applicable identity-based access boundaries for data stored in those services,” while externally hosted services “remain responsible for enforcing their own identity, permission, privacy, and compliance requirements.”

Two consequences follow:

• Existing oversharing carries over. If a SharePoint site is open to everyone in the organisation, an agent grounded in that site can surface its content to anyone who uses the agent, because each of those users already has access. The guide to SharePoint oversharing and Copilot explains the governance steps Microsoft describes for this.
• Labels and policies still apply. Microsoft says that when data is encrypted by Microsoft Purview Information Protection, for example by sensitivity labels, Copilot “honors the usage rights granted to the user.” Microsoft’s extensibility planning page lists existing permissions, sensitivity labels, data loss prevention, retention, eDiscovery, audit and compliance controls among the things to review when planning an agent.

Microsoft also states that “Admins have full control to select which agents are allowed in their organization,” and that a user can only access agents the admin allows and that the user installed or was assigned.

Knowledge sources and connectors

A knowledge source is what an agent draws its answers from. Microsoft’s Copilot Studio data policy page names knowledge sources such as uploaded documents, SharePoint and OneDrive, and public websites, and Copilot Studio agents can also use Copilot connectors.

Copilot connectors bring data from non-Microsoft systems into Microsoft Graph so agents can use it. Microsoft’s Copilot Studio page says these connectors “fully respect source-level permissions, ensuring that users only access content they’re authorized to view,” and that a tenant admin has to configure a connector before agent makers can add it. Microsoft’s Copilot privacy page says data from Graph connectors can be returned in Copilot responses “if the user has permission to access that information.”

For agents that call external services, Microsoft’s privacy page says to “check the privacy statement and terms of use of the agent to determine how it will handle your organization’s data,” and that in the Integrated apps section of the Microsoft 365 admin center, admins can view the permissions and data access an agent requires, along with its terms of use and privacy statement.

Maker credentials vs user credentials

This is the point Microsoft’s documentation flags most clearly. When a Copilot Studio agent uses a tool (for example, a connector that reads a database), the tool has to sign in to that service somehow. Microsoft describes two options:

• User authentication. The person chatting with the agent signs in, and the tool runs with their access. Microsoft describes this for cases where the agent “is meant to retrieve data that only the user has access to, or to perform work on their behalf.”
• Agent author authentication (often called maker credentials). The tool runs with the builder’s own connection. Microsoft describes this for when access to the service is implicit, or for “low-risk use cases”, such as finding the support team’s phone number for a postal code or getting a weather forecast.

Microsoft’s page on maker-provided credentials explains the risk: “the agent uses the maker’s credentials, not the end user’s credentials… Using maker credentials could lead to oversharing of data or capabilities - for example, an end user might retrieve information or perform actions that only the maker’s account is permitted to do.”

A fictional example: Priya at harbourlogistics.example builds an agent that answers questions from the finance system, using her own finance access. She shares it with the whole sales team. Anyone in sales can now ask questions that return data only Priya was meant to see. Nothing was hacked; the agent simply used her access on everyone’s behalf.

Microsoft documents a Power Platform setting called Control maker credential options that lets admins allow End-user credentials, Maker-provided credentials, or both. Microsoft notes that by default both are enabled, and that turning off maker-provided credentials means agents triggered by scheduled or autonomous events, or running in the background, fail, because “All agent triggers must involve an active user.”

How to find the maker credential setting

Based on Microsoft’s instructions (checked October 2026). Menus can change; Microsoft’s maker credentials page has the latest steps.

1. Sign in to the Power Platform admin center with an admin account.
2. In the side navigation, select Manage, then Environments (or Environment groups) and the environment.
3. Select Settings, expand Product and select Features.
4. In the Copilot Studio agents section, under Control maker credential options, choose the options and select Save.

Microsoft notes that if the environment belongs to an environment group, the setting is configured on the group instead.

Admin controls Microsoft documents

The Agents area of the Microsoft 365 admin center

Microsoft describes the Agents area of the Microsoft 365 admin center (Agents > Overview) as a place to “discover and review the agents that exist in your organization’s tenant,” “understand who published and owns each agent,” and “control availability and access to each agent.” It includes a Registry of agents, plus a Requests view (All agents > Requests) listing pending agent requests submitted by users.

Microsoft’s agent actions page lists what admins can do from Agents > All agents, including:

• Install or uninstall an agent for everyone or for selected users and groups
• Block or unblock an agent across the organisation
• Delete an agent, which Microsoft describes as a soft delete that keeps its properties for 30 days so it can be restored
• Assign a new owner to agents that are ownerless or active (Microsoft says ownership can only be reassigned for shared Agent Builder and Copilot Studio agents), after which “The previous owner loses all access, including read rights”
• Publish to store or Reject submission for an agent a user has requested.

Microsoft notes that blocking an agent built with Agent Builder or Copilot Studio affects Copilot and host apps such as Outlook and Teams, but blocking a SharePoint or Foundry agent “only impacts its availability in Microsoft Copilot Chat.”

Microsoft states that governance actions such as approving agent requests or assigning ownership “can only be performed by users in the AI Administrator or Global Administrator roles,” and that other roles can monitor governance gaps but can’t take administrative action. The guide to admin roles and least privilege explains why Microsoft describes limiting who holds roles like these.

Agent settings: types, sharing and user access

Microsoft’s agent settings page (Agents > Settings) describes three groups of settings:

1. Allowed agent types. Allow apps and agents built by Microsoft, Allow apps and agents built by your organization and Allow apps and agents built by external publishers. Microsoft says that if an option is disabled, agents of that type “don’t appear for users in the Agent store.”
2. Sharing. Allow all users to share with anyone in the organization, No users can share with anyone in the organization, or Allow specific groups of users to share with anyone in the organization. Microsoft notes that “Only agents built with Copilot Studio Lite are governed by sharing control.”
3. User access. All users (the default), No users, or Specific users/groups.

Copilot Studio data policies

For Copilot Studio, Microsoft describes Power Platform data policies (also called DLP policies) as the way to control which connectors agents can use. Based on Microsoft’s instructions (checked October 2026), data policies are in the Power Platform admin center under Security > Data and privacy > Data policy; Microsoft’s data policy examples have the full steps. Microsoft states that “Since early 2025, data policy enforcement is in effect for all tenants,” that makers and users see error messages for any data policy violation, and that when a violation occurs “the Publish button becomes unavailable.”

Microsoft’s page lists connectors admins can block, including:

• knowledge from uploaded documents, from SharePoint and OneDrive, and from public websites
• chat without Microsoft Entra ID authentication, which stops “no authentication” agents
• HTTP requests, with endpoint filtering available
• publishing channels such as Microsoft Teams and Microsoft 365, SharePoint, Direct Line, Facebook, WhatsApp and Omnichannel.

Microsoft points out a detail that’s easy to miss: blocking the uploaded-documents knowledge connector “only prevents local file uploads. It doesn’t prevent makers from adding files from SharePoint or OneDrive.” That needs the SharePoint and OneDrive connector blocked as well.

Data protection and prompt injection

Microsoft’s Copilot privacy page states that “Prompts, responses, and data accessed through Microsoft Graph aren’t used to train foundation LLMs, including those used by Microsoft Copilot.” It also says admins can use Content search or Microsoft Purview to view and manage stored Copilot interaction data, and Purview retention policies for chat interactions with Copilot. The guide to Microsoft 365 audit logs and alerts explains the audit log.

Microsoft’s extensibility planning page also warns about prompt injection: if a custom action can provide data from untrusted sources such as emails or support tickets, “an attacker might be able to craft a message payload that causes your agent to behave in a way that the attacker controls, such as incorrectly answering questions or even invoking custom actions.” Microsoft says organisations “should only enable declarative agents that use trusted knowledge sources and connect to trusted REST APIs via custom actions,” and, where untrusted data sources are necessary, to design the agent “with the possibility of breach in mind” and not give it “the ability to perform sensitive operations without careful human intervention.” The guide to prompt injection, explained covers the idea in plain terms, and AI agent permissions looks at agent access more broadly.

Things to watch for

• Agents built on maker credentials and then shared widely, as in the fictional example above.
• Ownerless agents left behind when the builder changes roles or leaves. Microsoft describes reassigning ownership for these.
• Broad knowledge sources, such as an agent grounded in a site that’s already overshared.
• Agents reading untrusted input (inboxes, tickets, web pages) that can also take actions.
• Assuming one setting covers everything. Microsoft’s own pages show that sharing controls apply only to some agent types, and that blocking has different effects depending on how the agent was built.

Things that change

Microsoft is changing agent features quickly. Its agent management pages describe Microsoft Agent 365 and Microsoft 365 E7, and some features are part of Microsoft’s Frontier programme, which Microsoft says gives early access to AI capabilities “before those features reach general availability (GA).” Microsoft rewrote its Copilot extensibility privacy page in September 2026, which is why this page now quotes Microsoft’s main Copilot privacy page as well. This page reflects Microsoft’s documentation as checked on 21 October 2026.

Common questions

What data can Copilot agents access?

Microsoft says Copilot only surfaces organisational data that the user has at least view permission to, and sends agents queries based on data the user has access to in Microsoft 365. Microsoft Graph and Microsoft 365 services enforce those access boundaries, while externally hosted services remain responsible for their own. Sensitivity labels and other Purview controls still apply. What agents can access, as Microsoft describes it has Microsoft’s wording.

Can a Copilot agent show people data they can’t normally see?

It can when a Copilot Studio tool uses the maker’s credentials. Microsoft warns that in that case “an end user might retrieve information or perform actions that only the maker’s account is permitted to do.” Microsoft documents a Power Platform setting, Control maker credential options, and says both end-user and maker-provided credentials are allowed by default. Maker credentials vs user credentials includes a fictional example and the steps.

Do Copilot Studio agents respect SharePoint permissions?

Microsoft says Copilot works within users’ existing Microsoft 365 permissions and that Copilot connectors “fully respect source-level permissions”. That cuts both ways: if a SharePoint site is already open to everyone in the organisation, an agent grounded in that site can surface its content to anyone who uses the agent. The guide to SharePoint oversharing and Copilot covers the governance steps Microsoft describes.

How do I block or switch off an agent in Microsoft 365?

Microsoft’s agent actions page describes blocking an agent across the organisation, uninstalling it for everyone or selected users, or deleting it, which Microsoft calls a soft delete kept for 30 days. These are under Agents > All agents in the Microsoft 365 admin center. Microsoft notes that blocking affects different apps depending on how the agent was built. The Agents area of the Microsoft 365 admin center has the list.

Who can approve or govern agents in Microsoft 365?

Microsoft states that governance actions such as approving agent requests or assigning ownership “can only be performed by users in the AI Administrator or Global Administrator roles.” Other roles can monitor governance gaps but can’t take administrative action. Microsoft also notes that when ownership is reassigned, the previous owner loses all access. The guide to admin roles and least privilege explains why Microsoft describes limiting who holds these roles.

Is my company data used to train Copilot?

Microsoft’s Copilot privacy page states that “Prompts, responses, and data accessed through Microsoft Graph aren’t used to train foundation LLMs, including those used by Microsoft Copilot.” For agents that call external services, Microsoft’s page points to checking each agent’s privacy statement and terms of use, which admins can view in Integrated apps. Data protection and prompt injection covers how Microsoft describes stored interaction data.

Where to get official help

Microsoft Learn’s pages on data, privacy and security for Microsoft Copilot, agent management in the admin center and Copilot Studio data policies have Microsoft’s current steps. For licensing questions, Microsoft or a Microsoft licensing partner is the place to confirm what a tenant includes.