It usually starts with a good idea. Someone in HR builds a Copilot agent to answer leave questions. Sales asks for one that drafts proposals from the CRM. A developer tries Microsoft Foundry for a customer-support agent. Six months later the business has twenty Copilot agents, and the question from the leadership team is simple: are we secure?
Most teams can show a list of agents. Fewer can say, with confidence, that the control plane behind them is secure: the identities, sign-ins, permissions and connections that decide what every agent can actually do.
This post walks through that journey: the kinds of Copilot agents your teams are building, what the control plane behind them is, where it breaks, and the checks that let you answer “are we secure?” with evidence instead of hope.
What counts as a Copilot agent?
“Copilot agents” covers more than most people think. In a Microsoft 365 tenant today, agents arrive five ways:
| Kind of Copilot agent | Who builds it | What it usually reaches |
|---|---|---|
| Agent Builder agents in Copilot Chat | Any licensed user, in minutes | SharePoint, Teams and Outlook content they add as knowledge |
| SharePoint agents | Anyone with access to a site | The site and its files |
| Copilot Studio agents | Makers, often outside IT | SharePoint, mailboxes, Dataverse and business systems through connectors |
| Agent Store agents | Microsoft and partners; deployed by admins | Whatever the agent’s permissions allow |
| Microsoft Foundry agents | Developers | APIs, databases and production systems |
Microsoft’s own documentation calls declarative agents built in Copilot Studio “Copilot agents”. Agent Builder and SharePoint agents are declarative agents too. They answer from the knowledge they are given, and they inherit whatever that knowledge exposes.
Admins can see and control much of this. In the Microsoft 365 admin center, Microsoft says admins can enable, assign, block or remove agents, and its agent registry lists shared agents with their creator and creation date. Use it. But the registry shows that an agent exists. It doesn’t show what the agent’s knowledge sources expose, which grants it holds, or what it connects to.
Step 1: Be honest about what’s being built
Ask three questions in your next team meeting, or your next client review:
- Are people building Copilot agents? In Copilot Chat with Agent Builder, in SharePoint, or in Copilot Studio, which lets makers build agents with little or no code connected to SharePoint, mailboxes, Dataverse and business systems.
- Is anyone building in Microsoft Foundry? Foundry is where developers build custom agents and AI apps that call APIs, run multi-step workflows and work with production data.
- Who approved each one? Not “was it allowed”, but who, by name, decided it should exist with the access it has.
The answers are usually: more than you thought, yes (often as a pilot), and nobody in particular.
Step 2: Understand the four layers of the agent control plane
Every agent, whatever built it, depends on four layers. Get these right and most agent risk goes away. Get them wrong and no prompt filter will save you.
Layer 1: Identity
Who is the agent? Microsoft now gives agents their own identities through Microsoft Entra Agent ID. Microsoft’s Copilot Studio documentation says that since May 2026, every new Copilot Studio agent automatically gets an Entra Agent ID, and the person who created it is recorded as its sponsor. Microsoft says Foundry agents get an Entra Agent ID as part of onboarding too.
That’s a big improvement. But an identity is only as good as its ownership. A sponsor who left in June is not an owner.
Layer 2: Authentication
How does the agent prove who it is? Through tokens, keys, secrets and sessions. Foundry agents in particular often use keys and service accounts set up by a developer for a pilot, and those keys tend to outlive the pilot.
Layer 3: Grants
What has the agent been allowed to reach? This is where most real incidents come from. A Copilot agent given “the HR SharePoint” as knowledge can read whatever that site exposes, including folders shared far wider than anyone intended. A Foundry agent with a connection to the finance database can read, and maybe write, whatever that connection allows.
Layer 4: Connections
Who does the agent talk to? Agents call connectors, APIs, other apps and other agents. Each hop extends what the agent can reach, and each is a place where data can leave.
Step 3: Find where the control plane breaks
These are the most common ways it breaks in Microsoft 365 tenants:
- Agents shared with everyone. An Agent Builder agent built for one team is shared with the whole company, along with the knowledge it was given.
- Maker-owned agents. The agent’s sponsor is the person who built it. When they move roles or leave, the agent keeps running with nobody accountable.
- Agents running on a person’s connection. A Copilot Studio agent uses the maker’s own credentials for a connector, so it can reach everything the maker can.
- Pilot keys that never die. A Foundry pilot ends; the key and service account remain, with access to production data.
- Inherited oversharing. An agent is given a SharePoint site as its knowledge source. The site contains a folder shared with “everyone”, so the agent can surface payroll to anyone who asks.
- Quiet new connections. An agent is updated to call a new connector or app, and nobody reviews the change.
None of these is a bug in Copilot Studio or Foundry. They’re the normal result of building fast without watching the control plane.
Step 4: Use Microsoft’s controls, and know where they stop
Microsoft gives you real tools. Microsoft Agent 365, generally available since 1 May 2026, adds a registry, agent identities through Entra Agent ID, access controls and usage reports. Microsoft says foundational features such as agent identity and inventory come at no extra cost to Microsoft Cloud customers, with premium features at $15 per user per month.
Use them. Then be clear about what’s still on you:
- Grants and sharing still need reading one by one.
- Keys and service accounts from pilots still need retiring.
- Agents outside Microsoft, and third-party AI apps connected through consent, still need to be on the same list.
- Someone still has to act when an agent goes off script at 2 am.
- For MSPs, every client is a separate tenant to check. See Copilot agents for MSPs.
A worked example: the proposal agent and the pricing sheet
This is an illustrative example, not a real client. A 90-person engineering consultancy has 17 Copilot Studio agents and two Foundry pilots.
The proposal agent. Sales built it to draft proposals. Its knowledge source is the sales SharePoint site. Six months ago, someone shared the “Rates and margins” folder on that site with the whole company for a planning meeting. The agent can now quote internal margins to anyone who asks, including a contractor with a guest account.
The support pilot. A developer built a Foundry agent to answer customer tickets. The pilot ended in July. Its key still works, and it still has read access to the customer database.
The ask. The managing partner asks the MSP: “Are our agents secure?”
Without control-plane checks, the MSP can show the list of 19 agents and their Entra Agent IDs. That’s all.
With them, the MSP can say: 17 agents have active sponsors and two don’t; the proposal agent can surface a folder shared with everyone, and here is the one sharing change that fixes it; the Foundry pilot’s key is still live, so it has been reset and its access removed; and three agents gained a new connection this month, each now reviewed by its sponsor.
That’s the difference between a list and confidence.
Checklist: is your agent control plane secure?
Identity
- You have one list of every Copilot agent: Agent Builder, SharePoint, Copilot Studio, Agent Store and Foundry.
- Every Copilot Studio and Foundry agent has its own identity.
- Every agent’s sponsor still works here and knows they’re the sponsor.
Authentication
- No agent runs on a person’s own credentials.
- Keys and service accounts from finished pilots are retired.
Grants
- Every agent’s knowledge sources and connectors match its job.
- Sites and folders shared with “everyone” are reviewed before an agent uses them.
- Write access is the exception, not the default.
Connections
- New connectors and app connections are reviewed when they’re added.
- You’d know if one agent or app started reaching into another.
Response
- Any agent can be stopped in one step, at any hour.
- Every agent is reviewed at least every 90 days.
How Centeye helps
Centeye Synthwatch watches the agent control plane across Microsoft 365 and Google Workspace. Today it lists the agents and AI apps holding access through app grants and service accounts, gives each one an owner and a 90-day re-approval, reads what each grant allows with a risk score, finds oversharing an agent could surface, and traces app-to-app chains. It can revoke a grant, lock a service principal or reset an API token, at the setting you choose.
Synthagent, the guard agent inside Synthwatch, watches all four layers, identity, authentication, grants and connections, continuously. It links an agent going off script to its sponsor’s account and mailbox in one case, and fixes it in place.
What’s coming: reading agents straight from the Copilot Studio registry and Microsoft Entra Agent ID. Foundry agents are covered today when they reach Microsoft 365 through an app grant; reading Foundry directly isn’t built yet. Synthwatch and Synthagent are in early access.
Frequently asked questions
What are Microsoft 365 Copilot agents?
Agents that work inside Microsoft 365 Copilot: built by users with Agent Builder in Copilot Chat, created from SharePoint sites, built by makers in Copilot Studio, or deployed from the Agent Store. Each answers from, or acts on, the data it’s been given.
How do I see every Copilot agent in my tenant?
Start with the agents page in the Microsoft 365 admin center, which lists shared agents with their creator. Then look wider: Copilot Studio environments, Foundry projects, and third-party AI apps connected through app consent don’t all show up in one place.
What is an agent control plane?
The set of controls that decide what an agent can do: its identity, how it signs in, what it’s been granted access to, and what it connects to. Securing agents mostly means securing those four layers.
Do Copilot Studio agents get their own identity?
Yes. Microsoft’s documentation says that since May 2026, new Copilot Studio agents automatically get a Microsoft Entra Agent ID, with the creator recorded as sponsor.
Are Foundry agents riskier than Copilot Studio agents?
Not by nature, but they’re often more powerful. Foundry agents tend to call APIs and work with production data, and pilots often leave live keys behind. Treat each one as a production identity.
Can a Copilot agent see files the user can’t?
It works within the access it’s been given. The common problem is that the access it’s given, such as a SharePoint site, contains content shared far wider than intended.
Where should an MSP start?
Pick one client that’s building agents. List every agent and its sponsor, read the grants of the three with the widest access, and retire any pilot keys. That first review usually makes the case for the rest.
New to the terms? See AI agent, non-human identity and OAuth grant in our glossary. Want to see the agents in your tenant? Ask for early access.
Copilot agent types and admin center agent management as described on Microsoft Learn. Copilot Studio and Foundry agent identities as described on Microsoft Learn and the Microsoft Entra blog. Agent 365 availability and pricing as described in Microsoft’s GA announcement and licensing FAQ, October 2026. The worked example is illustrative. Synthwatch and Synthagent are in early access. Microsoft, Copilot Studio, Foundry, Entra and Agent 365 are trademarks of the Microsoft group of companies.