Planning for AI Agents Before Your Organization Has Hundreds of Them

What Ignite 2025 revealed about agents across SharePoint, Teams, and Security Copilot – and why governance can no longer be an afterthought

At Microsoft Ignite 2025, the headline capability wasn’t a single feature. It was a pattern. Agents in SharePoint. Agents in Teams. Twelve new Security Copilot agents built into Defender, Entra, Intune, and Purview. More than thirty partner agents extending protection across the stack. And a new product – Agent 365 – whose entire purpose is to help organizations see all of it in one place.

If you read our article on SharePoint as the AI control plane, you already know our position: Copilot’s quality depends on the structure it reasons over, not on the license tier you buy. This article extends that argument to a bigger and more urgent question. What happens when the thing you need to govern isn’t just content anymore – it’s autonomous software that acts on your behalf, across every application you own?

That is the real story behind the Ignite 2025 Book of News. Not a wave of features. A shift in what IT and security teams are now responsible for.

The Pattern Nobody Can Miss Anymore

Look across the Ignite 2025 announcements and a single theme repeats in almost every product line:

• In SharePoint, agents can now be built no-code directly in document libraries and sites, opened instantly in Copilot Chat, and downloaded from the Agent Store in both Microsoft 365 Copilot and the Teams app store
• In Teams, channels can host agents with real business context – agents that pull data from connected tools like Jira and GitHub through Model Context Protocol integrations, surface blockers, and coordinate workloads without a human prompting them
• In Security, twelve new Microsoft-built Security Copilot agents joined an already-live portfolio of 37, alongside more than thirty new partner-built agents extending protection across the stack

This is not a single feature wave you can evaluate, approve, and move on from. It’s a new category of thing your organization now has to manage – alongside users, devices, and applications. Each of these agents has an identity. Each one has access to something. Each one takes actions on someone’s behalf, at machine speed, often without a human reviewing each step.

Most organizations are not yet set up to answer a basic question: how many agents are currently running in our tenant, and what can each of them see?

This Is Tool Sprawl’s Next Chapter

We’ve written before about tool sprawl – the accumulation of SaaS applications that nobody tracks, nobody owns, and nobody retires. Agent sprawl is the same failure pattern, but faster and higher-stakes.

A forgotten SaaS subscription sits idle and costs money. A forgotten agent doesn’t sit idle. It keeps running. It keeps reading whatever it was given access to. It keeps acting – creating SharePoint pages, summarizing meetings, nudging colleagues, pulling data from connected systems – whether or not anyone remembers it exists.

The difference that matters most: a SaaS tool is something a human has to actively log into and misuse. An agent is something that acts continuously, on its own initiative, using whatever permissions its creator happened to have at the moment they built it. If your content is unlabeled, an agent will treat it as low risk and act accordingly. If your permissions are a mess, an agent will happily inherit whatever inappropriate access already exists.

This is why “who created this agent, and what can it touch?” is no longer a nice-to-have governance question. It is now as urgent as “who has admin rights to this system?” – and most organizations don’t yet have a good answer. Since Security Copilot’s custom agent capability launched in September, customers have already built more than 370 unique custom agents. That is a strong signal of how fast informal agent creation is outpacing formal governance – and Security Copilot is only one of the surfaces where this is happening.

Where Agents Are Showing Up – and What Each One Actually Does

SharePoint agents

Agents built directly in SharePoint document libraries and sites can now open instantly in Copilot Chat – no separate provisioning step required. They’re also available for download from the Agent Store in Microsoft 365 Copilot and the Teams app store. Microsoft’s own legal team is the reference case here: they built SharePoint agents to help 3,000 marketers find legal and compliance answers, and measured a 2.97x improvement in response time over manual search. That’s a genuine, measurable productivity gain – achieved with no-code tooling any site owner can access.

Teams agents

Teams channels can now host agents with actual business context, using Model Context Protocol integrations to pull data from tools like Jira and GitHub. These agents can create meetings automatically, highlight blockers, summarize updates, and coordinate workloads – surfacing issues in your workflow without anyone needing to check a dashboard. The obvious risk: an agent built to “nudge people about overdue tasks” is one bad configuration away from spamming an entire department. The upside is real, but it depends entirely on the same discipline you’d apply to any automated process with organization-wide reach.

Security Copilot agents

Security Copilot already had 37 built-in agents before Ignite. The event added more than 40 new ones – 12 Microsoft-built agents across Defender, Entra, Intune, and Purview, plus more than 30 partner-built agents extending protection end to end. Security Copilot itself is rolling out to Microsoft 365 E5 customers – first to existing Security Copilot customers, then more broadly, with 30 days’ advance notice before activation for everyone else.

Eligible E5 customers receive 400 Security Compute Units per month for every 1,000 user licenses, capped at 10,000 SCUs monthly. A 400-seat organization gets 160 SCUs; a 4,000-seat organization gets 1,600. Scaling beyond that allocation costs $6 per SCU on a pay-as-you-go basis. This capacity is designed to support typical usage – but usage-based cost is now a governance question too, not just a security one.

The results Microsoft is reporting are worth noting: SOC analysts have detected malicious emails up to 550% faster using the Phishing Triage Agent, and identity admins have achieved up to 204% greater accuracy identifying missing Zero Trust policies with the Conditional Access Optimization Agent. Results like these are what make the case for Security Copilot compelling – but they also raise the stakes on governance, since a force multiplier works both ways. An ungoverned agent doesn’t just underperform quietly. It amplifies whatever access and structure it inherits.

The common thread across all three surfaces – SharePoint, Teams, and Security – remains the same: every one of these agents needs an identity, a defined scope, and a named owner. None of that happens automatically just because the agent is easy to create.

Agent 365: The Control Plane, Explained

Agent 365 reached general availability on May 1, 2026. It’s licensed at $15 per user per month as a standalone add-on, or included as part of Microsoft 365 E7. Understanding what it actually is matters, because it’s easy to misread it as just another agent, or as a feature rather than infrastructure.

Agent 365 is not an agent. It doesn’t build agents, and it doesn’t run them. It’s a control plane – a single place where IT and security teams can observe, govern, and secure every agent operating in the environment, whether that agent was built with Microsoft AI platforms, sourced from an ecosystem partner, or registered independently.

It’s organized around five capabilities:

• Registry – a single source of truth for every agent in the organization, the foundation that prevents sprawl in the first place
• Access Control – governing what each agent can see and do, extending the same identity and permission model your organization already applies to human users
• Visualization – a complete view of how agents connect to each other and to the broader ecosystem, so issues can be spotted and resolved quickly
• Interoperability – agents access the same data and applications people use every day, from Word and Excel to SharePoint and Dynamics 365, giving them the same organizational context as a human colleague
• Security – detailed logging, reporting, and eDiscovery, plus policies to detect, retain, and investigate improper agent behavior, keeping the organization audit-ready

Since general availability, Agent 365 has continued to expand. A Shadow AI page, powered by Microsoft Defender and Intune, now surfaces local AI agents installed on Windows devices – agents that can read files and execute code entirely outside IT’s visibility, without ever touching a managed cloud service. Multi-tenant management has extended the control plane for organizations running more than one tenant. And risk signals from ecosystem partners are increasingly unified into a single security view, rather than requiring teams to check multiple portals to understand one agent’s overall risk profile.

Critically, Agent 365 does not stand alone. It draws its authority from infrastructure you already operate: identity and access controls from Microsoft Entra, data protection and compliance from Microsoft Purview, and threat protection from Microsoft Defender. This is deliberate. Microsoft’s position is that agents should be treated as first-class citizens of your existing security operations – not as a separate category requiring an entirely new toolset.

Purview: Why It’s the Backbone, Not a Side Character

Agent 365 gives you visibility. Purview is what determines whether the agents it’s watching are actually safe to run.

Every governance capability that already existed in Purview – labeling, encryption, data loss prevention, information barriers, content lifecycle policies, access reviews – now directly determines what agents can read, reason over, and act on. This is not a new relationship. It’s the same relationship Purview has always had with your content and your people, extended to a new category of actor.

The uncomfortable part is what happens when that relationship is neglected. If your content is unlabeled, Copilot and every agent that reasons over it treats it as low risk by default – whether or not it actually is. If your access controls are inconsistent, an agent will happily operate with whatever inappropriate access its creator already had. If your lifecycle policies haven’t been touched since your last migration, agents will surface and act on content that should have been retired years ago.

Security Copilot is the clearest proof point of this dependency. It plugs directly into the same data foundation that Purview governs – every label, every DLP rule, every permission setting shapes what Security Copilot can see and act on. A sloppy Purview setup does not produce a moderately useful Security Copilot. It produces an equally sloppy one. A strong foundation, conversely, is what turns 550% faster phishing detection from a marketing claim into something your organization can actually realize.

Microsoft has also added automated insights directly into the admin center – surfacing abandoned sites, overshared files, and suspicious permission patterns without requiring a manual audit. It’s a useful capability. It’s also, in effect, Microsoft telling every organization the same thing we’ve been saying in this series: fix the foundation before you scale what sits on top of it.

What Impactory Recommends Before Agent Adoption Scales

Reactions to announcements like these usually split into two camps: excitement to deploy everything immediately, or a freeze driven by how large the problem suddenly looks. Neither is the right response. Here’s the sequence we recommend to clients preparing for the next wave of Copilot and agent adoption:

• Audit your SharePoint environment first. Identify ownerless sites, overshared files, and confirm someone can actually describe your metadata structure. This is the same foundation we’ve written about in our SharePoint article – it doesn’t change just because agents are now part of the picture
• Define your taxonomy properly. Business domains, departments, projects. It doesn’t need to be perfect. It needs to be consistent, because agents will inherit whatever structure – or lack of it – already exists
• Review your Purview setup end to end. Labels, label policies, DLP rules, and lifecycle settings need to be aligned before you expand agent access to more of your content
• Run one Teams agent pilot, not ten. Pick a single business process, build one channel agent that surfaces blockers or automates one task, and demonstrate value concretely – not in a ninety-slide deck
• Create a content and agent creation storyboard. Document what Copilot and agents are allowed to create, for whom, and under what rules – then enforce it through Purview and SharePoint governance, not through a policy document nobody reads
• Register everything in Agent 365 from day one. Don’t wait for sprawl to happen and then try to inventory it retroactively. Every agent – Microsoft-built, partner-built, or internally built – should enter the registry as it’s created

None of this is about slowing down AI adoption. It’s about making sure the adoption that happens is something your organization can actually see, explain, and stand behind.

Questions CIOs and Heads of IT Should Ask Now

Visibility & Inventory

• Do we know how many agents are currently active across SharePoint, Teams, and our security tools?
• Can we identify who created each one, and whether they still work here?
• Have we registered our agents in Agent 365, or are we still tracking this manually – if at all?

Access & Risk

• Do agents inherit their creator’s permissions, or do they operate under a defined, scoped identity?
• Have we checked for local, unmanaged AI agents running on employee devices outside our visibility?
• Is our Purview labeling and DLP posture strong enough that an agent reasoning over our content would produce reliable, appropriately scoped answers?

Governance & Ownership

• Does every agent in our environment have a named owner accountable for its scope and behavior?
• Do we have a defined process for retiring an agent when its creator leaves or its purpose ends?
• Have we budgeted for the operational cost of governing agents at scale – including usage-based costs like Security Copilot’s SCU overage pricing – not just the license cost of creating them?

If most of these are hard to answer today, that’s not a reason to pause AI adoption. It’s the reason to build the governance layer now, while the number of agents in your environment is still small enough to get under control.

Structure Made Copilot Reliable. Governance Makes Agents Safe.

Ignite 2025 didn’t just deliver a wave of new capabilities. It delivered a clear signal about what enterprise AI adoption requires next: not more features, but the governance infrastructure to run those features responsibly at scale.

SharePoint structure, Teams workflows, Purview governance, and Copilot intelligence don’t work in isolation. Agent 365 is Microsoft’s acknowledgment that agents will multiply whether or not organizations are ready – and that visibility and control need to exist before that multiplication becomes unmanageable, not after.

The organizations that get ahead of this won’t be the ones that deploy the most agents fastest. They’ll be the ones who can answer, at any point, exactly how many agents are running in their environment, what each one can access, and who’s accountable for it. That capability doesn’t come from a license. It comes from the same discipline we’ve argued for throughout this series – applied now to a new category of thing that needs governing.

Not sure whether your organization is ready for what’s coming next?

→ Book a Consultation with Impactory

Our team can walk through your current SharePoint, Purview, and Copilot foundations, help you understand what Agent 365 would actually reveal in your environment, and build a practical governance plan before agent adoption outpaces your ability to see it.