AI agents are arriving in Microsoft 365 and Google Workspace from every direction: Copilot Studio, Microsoft Foundry, Gemini Enterprise, the SaaS apps you already pay for, and the tools staff connect themselves. Gartner predicts that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025.
Each of those agents is a new kind of worker. It signs in, reads data and takes actions, often with nobody watching. This guide sets out six steps to secure them, in the order that matters. They work whichever platform built the agent, and they work for a single business or an MSP looking after dozens.
If you’re not sure how many agents are coming, start with AI agent sprawl: the wave of agents coming to Copilot, Microsoft Foundry and Gemini.
Step 1: Find every agent
You can’t secure what you can’t see. Make one list of every AI agent and AI app with access to your data.
Look in four places:
- App consents (OAuth grants) in Microsoft Entra ID and Google Workspace. Most third-party agents and AI tools connect this way.
- Service accounts and app identities (service principals) that nobody recognises. Developer-built agents, including many in Microsoft Foundry, often run on these.
- Copilot Studio and Gemini Enterprise admin views, for agents staff have built.
- Your people. Ask teams what they’ve connected. The answers are often surprising.
Record what each agent is, what platform it runs on, and what it can reach.
Step 2: Give every agent an owner
Every agent needs a named sponsor: a person who answers for what it does. Not “IT”, not “the vendor”, and not the contractor who built it six months ago.
The owner approves the agent’s access, is the first person asked when it behaves oddly, and decides whether it’s still needed. When an owner leaves, their agents move to someone else before the account closes, the same way you’d hand over their files.
An agent with no owner should be paused until someone claims it.
Step 3: Give each agent its own identity
Agents should never run on a person’s account or a shared admin login. When they do, you can’t tell the agent’s actions from the person’s, and you can’t stop one without stopping the other.
Give each agent its own identity, so its sign-ins and actions are its own. Microsoft and Google are both adding dedicated agent identities, such as Microsoft Entra Agent ID. Where those aren’t available yet, a dedicated service account or app registration per agent is the next best thing. Never let two agents share one.
Step 4: Limit what each agent can reach
Most agent incidents aren’t clever attacks. They’re agents doing exactly what they were allowed to do, with far more access than their job needed.
- Match access to the job. An agent that answers HR policy questions needs the policy site, not the whole HR drive.
- Prefer read over write. Give write access only where the job needs it, and only to the systems it needs.
- Fix oversharing first. Copilot and Copilot Studio agents work within the permissions they’re given, so any site shared with “everyone” becomes something an agent can surface. Review the widest sharing before agents arrive. This is the most common way agents end up seeing payroll, contracts and HR files; see what Copilot can see for how to check.
- Retire old keys. Keys and service accounts from finished projects should be removed, not left “just in case”.
Step 5: Watch how each agent behaves
An agent’s normal day is usually very regular: the same systems, similar volumes, similar hours. That makes unusual behaviour easier to spot than with people.
Watch for:
- Volume jumps. An agent that reads 40 files a day suddenly reads 4,000.
- New reach. An agent touching a system or folder it has never touched before.
- Odd hours or places. Activity at 3 am, or use of its key from somewhere new.
- New connections. An agent granting access to, or calling, another app.
Join agent activity to the rest of the picture. An agent going off script at the same time as its owner’s account shows a suspicious sign-in is a very different event from either one alone.
Step 6: Be able to stop any agent in one step
When an agent misbehaves, you need to stop it in minutes, not after a meeting. Decide in advance:
- What “stop” means: revoke its access, lock its service account, or reset its key.
- Who can do it, including out of hours.
- What happens on its own and what waits for a person. Protective steps, like revoking one agent’s access, can often run automatically. Disruptive ones should wait for a human.
- Who to tell: the agent’s owner, and the client if you’re an MSP.
Then put every agent on a review cycle. Every 90 days, the owner confirms the agent is still needed and its access is still right.
A worked example: the invoice agent goes off script
Here’s an illustrative example.
Friday, 11:20 pm. A finance agent normally reads a few dozen files a day from the finance share to match invoices. Tonight it starts pulling more than a thousand. Its key had been pasted into a public code repository by mistake.
Without these steps: nobody owns the agent, so nobody is alerted. It runs on a shared service account that other tools also use, so stopping it would break them. On Monday, someone notices the storage bill.
With them: the agent is on the list with its own identity and a named owner. Its jump in volume is far outside its normal pattern, so it’s flagged within minutes. Its access is revoked and its key reset without touching anything else, every file it opened is listed, and its owner wakes up to a one-page summary.
Checklist: is every agent secured?
- Every agent and AI app with access to your data is on one list.
- Every agent has a named owner who still works for the business.
- Every agent has its own identity, not a person’s account or a shared login.
- Each agent’s access matches its job; write access is the exception.
- Sites and files shared with “everyone” have been reviewed.
- Old keys and service accounts are retired.
- Unusual agent behaviour raises an alert to its owner.
- Agent alerts are joined to sign-in and email alerts for the same person.
- Any agent can be stopped in one step, at any hour.
- Every agent comes back for review every 90 days.
How Centeye secures agents
Centeye Synthwatch covers these steps across Microsoft 365 and Google Workspace. Today it:
- Finds the AI agents and AI apps holding access through app grants, and service accounts nobody recognises (step 1).
- Assigns each one a named owner with a 90-day re-approval (steps 2 and 6).
- Shows reach: what each grant allows, a risk score, oversharing agents could surface, and when Copilot opens sensitive files (step 4).
- Stops an agent by revoking a grant, locking a service principal or resetting an API token, at the setting you choose (step 6).
On the way: reading agents directly from Copilot Studio and Gemini Enterprise, Microsoft Entra Agent ID and Google’s agent identities (step 3), and agents and MCP servers on laptops. Agents built in Microsoft Foundry are covered when they reach Microsoft 365 through an app grant.
The Praxis guard agent supervises agents for you (step 5): it learns each agent’s normal, links an agent going off script to its owner’s account and mailbox in one case, can ask the owner why, and stops the agent within your rules. Synthwatch and the guard agent are in early access, and work across every client tenant for MSPs.
Frequently asked questions
Do Microsoft and Google secure agents for me?
They provide important controls, such as Microsoft Agent 365 and Entra Agent ID, and Google’s admin views for Gemini Enterprise. Use them. But each covers its own platform, some depend on extra licences, and none gives an MSP every client in one place. Check each vendor’s current requirements.
What’s the most common agent risk?
Too much access. Most problems come from agents that can reach far more than their job needs, often because files were overshared long before the agent existed.
What if an agent’s owner leaves?
Move the agent to a new owner before the person’s account closes, or pause it. An agent with no owner should never keep running.
How is securing agents different from securing apps?
Apps wait for people. Agents act on their own, at machine speed, and can call other apps. That’s why each agent needs its own identity, an owner, behaviour monitoring and a fast off switch.
Where should an MSP start?
Pick one client already using Copilot or Gemini, make the list of agents and AI apps, and assign owners. That first list usually makes the case for the rest.
New to the terms? See AI agent, non-human identity and OAuth grant in our glossary. Read what guardian agents are for the supervision side. Want to see the agents in your tenant? Ask for early access.
Forecast cited from a Gartner press release, 26 August 2025. Microsoft Agent 365 and Entra Agent ID as described by Microsoft. The worked example is illustrative. Synthwatch and agent protection in Praxis are in early access; this post describes what ships today and what is coming.