AI agents in Microsoft 365: the new attack surface to audit

Two years ago the question was "should we enable Copilot". In 2026 the question has changed shape: your users are building and installing AI agents - in Copilot Studio, in Teams, from SaaS vendors, and increasingly on their own machines. Microsoft's answer to the resulting chaos even has a product name now (Agent 365, a registry and control plane for agents), which tells you how real the problem has become. The industry word for it is agent sprawl.

An agent is not a chat window. It is software that acts: reads mailboxes, writes files, calls APIs, triggers workflows. Every agent is therefore an identity with permissions - a non-human user in your tenant - and most organisations have no inventory of them.

Why agents are a permissions problem, not an AI problem

Everything we already knew about Copilot applies, amplified. Copilot surfaces what a user can already access; an agent acts on what it can access, around the clock, without the human pause that sometimes catches mistakes. Three patterns do most of the damage:

• Over-consented OAuth apps. An AI meeting-notes tool that asked for Mail.Read and full file access, approved in one click by a user in 2025, is still there, still reading. Agent platforms multiply these grants.
• Shadow agents. Users connect personal AI tools to work accounts because it makes them faster. Each connection is an unaudited data path out of your tenant, invisible in your license list.
• Orphaned agents. The employee who built the workflow agent leaves; the agent keeps running under credentials nobody remembers granting. It is the service-account problem again, at ten times the creation rate.

The audit checklist

You cannot govern agents you cannot see, so the work starts with inventory, not policy.

1. List every OAuth application with consented permissions in the tenant. Sort by scope breadth (mail, files, directory) and by who consented. Flag anything AI-related that a user self-approved.
2. Find the high-privilege grants. Mail.ReadWrite, Files.ReadWrite.All, Directory.Read.All held by third-party apps deserve a named owner and a written justification each.
3. Inventory Copilot Studio and Teams agents. Who built each one, what does it connect to, who can invoke it, and is the builder still an employee?
4. Check what agents can reach. An agent grounded on "all of SharePoint" inherits every oversharing mistake you have. The Copilot readiness work (broad-access sites, anonymous links, stale guests) is also agent readiness.
5. Look for stale and orphaned credentials. Agents authenticate with app secrets and certificates that expire, get copied, and outlive their owners.
6. Decide an approval path. One page: who may create agents, what scopes need review, and how often the inventory is re-checked. Without a path, users route around you.

An AI agent is a new employee who works at machine speed, never sleeps, and was hired by whoever

clicked "consent". The audit question is the oldest one in security: who can access what, and who

decided?

Getting the inventory without a scripting project

Microsoft Graph exposes OAuth grants, service principals and app permissions, and you can enumerate them with PowerShell if you are willing to maintain the scripts and re-run them monthly - sprawl grows back the moment you stop looking. The faster route is a read-only scan: Olyteck Cyber walks the tenant through Graph and reports OAuth applications and their permission scopes alongside the sharing and identity findings, without exporting file contents. It counts findings, never files.

Either way, treat July's inventory as a baseline, not a fix. The organisations that stay in control of agents in 2026 are not the ones that banned them - bans just create better-hidden shadow agents. They are the ones that can answer, at any moment, the simple question: what is running in our tenant, and on whose authority?