M365 Copilot & Agents

Copilot reads what you're allowed to read. Not always a good plan.

What Copilot and Agents find in your tenant isn't in the Microsoft documentation. It's in your permissions. We make sure both are right.

Get advice now

Book via Azure Marketplace

Deploying M365 Copilot and Agents securely: configuration, oversharing and the right architecture

Before Copilot, oversharing had no noticeable consequences, because no human had the time to search through all the documents of an average company. Copilot has that time. It takes seconds, and it doesn't look for problems — it simply finds them, because it accesses whatever the respective user is allowed to read via Microsoft Graph, and in most tenants the average employee has access to around 130,000 files that were never intended for them. The most common first effect after a Copilot rollout is therefore not increased productivity, but unwanted transparency.

That's not an argument against Copilot. It's an argument for sequence. Permissions, Sensitivity Labels, DLP policies, the configuration of the Copilot Control System and the question of which admin centers matter before the first rollout: these tasks existed before Copilot just as they do after it, but the reason to tackle them systematically was never as tangible as it is now. Copilot in this sense is not a problem — it's an opportunity to set up the tenant the way it should always have been.

16 %

of all corporate data is statistically over-permissioned (Microsoft)

130,000

files the average employee has access to that were never intended for them

70 %

of employees have shared business-critical data with unauthorized AI (Microsoft)

23 %

don't know whether their company offers AI tools at all (Microsoft)

What Copilot is, what an Agent is, and why the difference matters

The distinction Microsoft draws between Copilot and Agents is technically precise but often blurry in communication, which leads companies to either expect too much or start at the wrong end. The simplest line runs along the question of autonomy.

M365 Copilot and Copilot Chat are interactive assistants that answer questions, summarize content and draft texts, always based on what the user is allowed to read via Microsoft Graph. They don't act, they assist. Declarative Agents — SharePoint Agents or agents from the Agent Builder — extend this approach with a limited, predefined knowledge scope, but make no independent decisions and execute no system actions.

Agents only become truly autonomous as Custom Engine Agents, built in Copilot Studio, Power Platform or Azure AI Foundry: these can be triggered event-driven, communicate with external services and execute actions without a human confirming every step. Those who don't understand this distinction either build agents for tasks a simple Copilot prompt would handle just as well, or expect a Declarative Agent to have an autonomy that's architecturally not designed for it.

Copilot and Agents require a platform built for them

Copilot accesses data via Microsoft Graph that the user is allowed to read, and Agents operate within the system boundaries defined by the respective platform. If those boundaries were never explicitly set — because the tenant has grown organically and was never designed for AI access — Copilot and Agents will technically run, but in an environment optimized for neither performance nor governance.

Our Cloud Workplace Foundation lays the M365 base that Copilot needs: permission structure, Sensitivity Labels, DLP, governance policies — not bolted on afterwards, but integrated from the start. For Agents operating in Azure, the same applies: the Azure Foundation and the Azure Container Foundation ensure the ground is solid before building begins. Deploying Agents in an environment without this foundation is deploying on sand.