The Agentic AI Taxonomy, Part 5: Office Suite Agents

Quick summary: Microsoft 365 Copilot and Gemini for Google Workspace are SaaS-embedded agents, created by software vendors and shipped natively inside their own platforms. Because the data already lives with these vendors, these agents don’t introduce a new data-egress risk. Instead, they amplify an existing risk: oversharing and stale permissions that were already technically accessible but practically invisible until an agent could find them instantly. Mitigation requires access governance work (permission remediation, sensitivity labeling, group hygiene), which many enterprises have been deferring. This work now has real urgency behind it.

Welcome back to our series exploring the Numberline Agentic AI taxonomy, one category at a time. If you’re just joining us, you can catch up on the series where we introduced the new taxonomy, then analyzed chat assistants, sandboxed agents, and workspace-embedded agents.

In this installment we shift categories. We’re moving from provider-hosted, general-purpose agents into SaaS-embedded agents, which we define as agents created by software vendors and shipped natively inside those vendors’ own platforms.

This category is headlined by the agentic capabilities of the two major office suites, Copilot within Microsoft 365 and Gemini within Google Workspace. Beyond those, the proliferation of AI frameworks and toolkits has put agentic features into nearly every SaaS platform your enterprise licenses. We’re treating those as two separate topics. The office suite agents are substantive enough to warrant their own article, and we’ll cover the wider SaaS landscape in our next article.

A Working Definition, and a Brand Map

When we say Office Suite, we’re referring to the major platforms for business productivity: email, documents, presentations, spreadsheets, calendar, and file storage as the core set. The two largest examples are Microsoft 365 and Google Workspace, and those are today’s focus.

Both vendors of course operate very large technology platforms, and there are many (many!) ways an enterprise can build and consume agentic AI on them. We’re keeping the focus narrow. Today covers only the office-suite-native agents, meaning Microsoft 365 Copilot and Gemini for Google Workspace. We already covered the workspace-embedded agents from our previous article, and we’re excluding the no-code and engineering-built agent types, which get their own articles later in the series.

That narrowing deserves a moment of explanation, because the vendor branding is, frankly, confusing. Both vendors use a single brand name across products that sit in completely different parts of our taxonomy, with completely different security profiles. “Copilot” and “Gemini” each span five or more cells, as depicted in the image below. This is correct as of today, July 30, 2026. We’re hedging here because these vendors are in what feels like a near-continuous state of component creation, merging, and name-changing. We’ve depicted this in the diagram, below.

That map is worth looking at closely, because it carries a practical warning. In particular, your Microsoft 365 subscription alone can deliver agents into four different cells, each with different control points; Consumer Copilot chat, Microsoft 365 Copilot inside the suite, Browse with Copilot on the endpoint (which arrives with a Microsoft 365 Premium subscription and drives the user’s real browser), and Copilot Studio for citizen developers. One purchasing decision, four security postures. Most enterprises have never separated them, and when someone in a meeting says “we’ve approved Copilot,” it’s worth asking which one they mean.

What These Agents Can Do

Capabilities and licensing tiers change constantly, so rather than chase tier boundaries we analyze the full set of agentic capabilities these products offer:

• Access to some or all data within the office suite environment, subject to configuration and to access grants made by the user within administrator-defined constraints
• Analysis of, and recommendations about, tasks and workflows based on that data
• Performing specifically directed work tasks
• Automation, directed by the user, with some degree of agent autonomy

The Data Story Flips

With these agents, data access is the key element that makes this category different from everything we’ve covered so far: for every previous agent type, the headline data concern was egress. Corporate data leaving for a third party, uploaded into a vendor’s sandbox, processed on infrastructure you don’t control. That is not the case here, because your data already lives with this vendor. That decision was made years ago, when you adopted Microsoft 365 or Google Workspace. Copilot and Gemini process your content inside the same tenant and compliance boundary as the suite itself, under the same contractual commitments, and both vendors state that customer data is not used to train their models.

So data risk has inverted. It’s no longer about data getting out. It’s about data becoming findable on the inside.

These agents grant no new access. Both vendors are explicit that their agents act on behalf of the user, retrieving only what the requesting user can already reach. Google’s documentation states plainly that if a user doesn’t have access to a document or email, Gemini won’t retrieve that content. Microsoft says the same about Copilot. 

But the problem is that users typically have far too much access. Every over-permissioned SharePoint site, every “anyone with the link” Drive file, every stale group membership, every folder that was protected mainly by the fact that nobody ever looked in it: all of that was already accessible. What changes is that it becomes instantly navigable in plain English, readily available to a curious agent.

That’s why the enterprise conversation around these products has centered on oversharing remediation rather than data leakage. The agent is an amplifier of whatever permission hygiene you already have. If your access controls are tidy, the agent is a productivity win. If a decade of collaboration debt has accumulated in your file stores, the agent will surface it, quickly, to anyone who asks the right question.

Now, let’s go through our six attributes.

Data

Inputs

These agents ingest the user’s prompt plus whatever suite content that user can reach: mail, documents, spreadsheets, presentations, chat history, calendar, and file storage. On the Microsoft side that means content indexed through Microsoft Graph across SharePoint, OneDrive, Exchange, and Teams. On the Google side it means Drive, Gmail, Docs, and the rest of Workspace. Where enabled, both can also access public web results.

One distinctive attack surface here is indirect prompt injection, and email is the front door. Anyone in the world can send content into your tenant. A crafted message or a shared document sitting in a mailbox becomes untrusted content that the agent may read and act on, using the permissions of a user who asked an innocent question. Security researchers have demonstrated zero-click exfiltration against these products, vendors have patched the specific vectors, and the attack class remains live. This is a meaningful shift from earlier categories, where the untrusted content came from the open web. Here it is delivered into the trusted boundary, and waits.

Outputs

Both agents produce text, summaries, documents, spreadsheets, slides, and drafted messages. Those outputs often carry no inherited classification. A summary drawn from a labeled confidential document lands as an unlabeled draft unless your labeling policies handle it. Both platforms apply their existing DLP inspection to agent-generated content once it lands in a covered service, an email or a document, which helps to some degree. Neither solves provenance, and neither inspects output that never leaves the assistant panel

Controls

• Permission remediation across the file estate, which is the foundational control everything else depends on
• Sensitivity labeling and auto-labeling, applied to both sites and individual items
• Microsoft: Purview DLP for Microsoft 365 Copilot, which can exclude labeled content from Copilot retrieval
• Microsoft: Restricted Content Discovery in SharePoint Advanced Management, which removes a site from Copilot discovery and organization-wide search without changing who can open it
• Microsoft: Restricted Access Control, which scopes site access to a named Entra or Microsoft 365 group
• Google: DLP policies applying information rights management to sensitive files, which stops Gemini retrieving them
• Google: client-side encryption, which puts content beyond the reach of any generative assistant, including Google’s own
• Google: admin-level restriction of which Workspace apps Gemini may read from
• Admin controls of whether these agents can retrieve public Web content

Recommendations

• Run an oversharing assessment before broad rollout, not after. Microsoft’s data access governance reports and Content Management Assessment, and Purview’s data security posture assessments, exist specifically for this. On the Google side, audit Drive sharing links and shared drive membership.
• Hunt for specific anti-patterns. On Microsoft, that means “Everyone Except External Users” grants, broken permission inheritance, ownerless sites, and organization-wide sharing links. On Google, it means “anyone with the link” files, domain-wide shares, and stale shared drive membership.
• Treat discovery suppression as temporary. Microsoft’s Restricted Content Discovery is a useful pause button while you remediate a high-risk site. Microsoft is explicit that it is not a permanent fix, and it does not change who can open the content.
• Label your crown jewels before rollout, because label-driven exclusion only works on content that has been labeled.
• Phase the rollout. Enable IT and Security first, since they are best equipped to notice unexpected surfacing, then pilot with a small group in a sensitive function such as HR, Finance, or Legal with monitoring on, and only then go broad.
• Verify what exclusion actually means on your platform. Microsoft’s DLP for Copilot can suppress labeled content from responses while the item may still appear as a citation. Know the difference between “not used” and “not visible.”

Identity

This is the purest on-behalf-of case in our entire taxonomy. These agents have no distinct identity, no service accounts, and no compartments of their own. They execute as the requesting user, inheriting that user’s permissions natively through the platform’s own access model rather than through a connector or an OAuth grant.

For a security team, that is genuinely good news. There is no new principal to provision, govern, or decommission, and agent actions carry the user’s identity into the platform’s existing audit trail. It also means your existing identity controls apply without modification. Conditional access, MFA, device posture, and group membership all govern the agent exactly as they govern the human.

Controls

• Existing identity and conditional access controls, which apply unchanged
• Group membership, which is often the real determinant of what the agent can reach
• Per-user licensing, which functions as a hard access gate
• Google: separate toggles for Gemini availability and Gemini access to Workspace data

Recommendations

• Recognize that access reviews are now effectively AI security work. Group membership and file permissions have always determined exposure. They now determine it at conversational speed.
• Use the Google control separation deliberately if you’re on Workspace. A user can have Gemini for drafting assistance without AI-mediated retrieval from Drive, which is a useful intermediate posture while remediation is underway.
• Treat licensing as a control surface. Deciding who gets a license is deciding who gets an amplifier.

Authority

The formal answer is simple. These agents have exactly the same authority as the requesting user, no more and no less. They cannot reach a file the user cannot open, and they cannot take an action the user is not permitted to take.

The operational answer is more interesting, and it is the point most worth making to your leadership.

Same authority does not mean same reach. A human searching for something is narrow, specific, and quick to give up. They search for what they expect to exist, in the places they expect it, and they stop when they find something good enough. An agent is expansive, complete, and (to overly anthropomorphize) very curious. It examines everything within scope, correlates across sources a person would never think to connect, and returns a synthesized answer. The user could always technically have opened those thousand files. They would simply never have found them, and they certainly would not have read all of them.

That gap between technical authority and practical reach is where the risk lives. Your permission model has been quietly protected for years by limited human attention spans. These agents remove that protection.

Controls

• The underlying permission model in SharePoint, OneDrive, and Drive, which is the actual authorization boundary
• Label-based and rights-based restrictions that constrain the agent more tightly than the user, which is the one place agent authority can be deliberately narrowed below human authority
• Restricted Content Discovery and equivalent discovery limits
• Agent-specific admin scoping of which applications and data sources are in play

Recommendations

• Re-evaluate access with the assumption that everything a user can reach will actually be read. That assumption was never true before and it is a reasonable one now.
• Use controls that constrain the agent more tightly than the human where the content warrants it. Information rights management on the Google side and DLP-for-Copilot exclusion on the Microsoft side both let you say “the user may open this, the agent may not.”
• Prioritize remediation by blast radius rather than by site count. A single overshared site holding board materials matters more than a hundred messy project sites.

Autonomy

Today these agents sit at the low end of our autonomy scale. They are largely reactive, responding to a prompt, drafting into a document, summarizing a thread. They do not independently decide to act.

We’d encourage you to treat that as a snapshot statement, with a potentially short shelf life. Both vendors are actively pushing agentic capability into the suites: scheduled and triggered actions, multi-step task completion, and agents that operate across suite applications without a prompt for each step. The assessment in this section is the one most likely to be out of date by the time you’re planning your next review cycle.

Controls

• Feature-level admin toggles for agentic capabilities as they ship
• Approval requirements for actions with side effects, where exposed
• Per-application enablement, restricting which suite apps the agent operates in

Recommendations

• Set a recurring review of newly shipped agentic features in your suite, rather than assessing once at rollout.
• Decide your position on autonomous action before the feature arrives enabled by default, which is the pattern both vendors have followed.

Management

This is the richest management surface we’ve encountered so far in the series, and the reason is straightforward. These agents live inside a tenant you already administer, using an admin console your team already knows, governed by a policy engine you have already deployed. And both vendors have heavily invested in Agentic control centers for the enterprise.

On the Microsoft side that means SharePoint Advanced Management for permission governance and discovery restriction, Purview for labeling, DLP, and posture management, and Purview’s AI-focused posture tooling for visibility into what Copilot is actually surfacing. On the Google side it means the Admin console’s generative AI section, DLP with information rights management, client-side encryption, Chrome Enterprise Premium for endpoint DLP extending to the Gemini app, and Workspace’s logging and export for Gemini activity.

The one caution is licensing. Several of the most important controls sit behind premium tiers. SharePoint Advanced Management requires SharePoint Premium. Some Purview capabilities require specific Microsoft 365 licensing. On the Google side, DLP and information rights management require the higher Workspace editions. It is entirely possible to license the agent and not license the controls for the agent, and that is a procurement conversation worth having before deployment rather than after.

Controls

• Per-user and per-organizational-unit enablement
• Per-application restriction of where the agent operates
• Tenant-level data governance tooling, which now doubles as AI governance tooling
• Activity logging and export for agent interactions
• Licensing itself, both as an access gate and as a control prerequisite

Recommendations

• Confirm you have licensed the governance tooling, not just the agent.
• Bring your data governance team into AI deployment planning, since they own the controls that matter most here.
• Monitor what the agent is actually surfacing, not just whether it’s enabled. Both platforms offer activity visibility, and the early weeks of a rollout are when unexpected retrieval patterns show up.

Lifecycle

Traditional identity lifecycle does not apply, since there is no agent identity to provision or decommission. What matters instead is capability creep.

These agents arrive through your existing subscription, and new agentic features land inside an already-approved product based on the vendor’s release schedule. No procurement, no change advisory board, no security review. The product you assessed last quarter may have meaningfully different capabilities this quarter, and nobody will have sent you a ticket about it.

The parallel to our earlier articles is the “arrives uninvited” problem. It is perhaps even sneakier because the vendor is one you have already vetted, inside a boundary you already accept. It’s still real, because your risk assessment silently ages.

Controls

• Vendor release notes and roadmap communications
• Admin console feature toggles as new capabilities ship
• Activity logging, which reveals capability changes in practice rather than in documentation

Recommendations

• Assign someone ownership of suite AI release monitoring. This is a real, recurring job now, and needs to be proactively managed.
• Re-run your assessment on a schedule rather than at deployment only.
• Watch the default. When a new agentic feature ships enabled by default, the time period between feature release and your review is a window of unmanaged capability in production.

Summary

Office suite agents invert the risk model we’ve been building through this series. The data was already with the vendor, the agent grants no new access, and the control surface is one your team already operates. In several respects this is the most comfortable category we’ve covered.

The discomfort is that these agents are effectively a “stress test” for your permission model. Years of collaboration debt, sitting quietly in file stores nobody browses, becomes searchable in plain English by anyone with a license. 

Which means the work here is not primarily AI security work. It’s the access governance work most enterprises have been deferring for a decade, with a new and very concrete deadline attached. Permission remediation, sensitivity labeling, group hygiene, and access reviews are the controls that matter, and the agent-specific features from both vendors are best understood as tools to buy time while you do that work rather than substitutes for it.

The good news is that this is familiar territory. We know how to do access governance. The agent just changed its priority.

If you’d like some guidance, join us for a free 30-minute Agentic AI Security Workshop. We’ll review the taxonomy with you and help you apply these recommendations to your enterprise.

Next up: application-specific SaaS agents. Having covered the office suites, we turn to the agentic features arriving inside every other SaaS platform you license, where the headline problem is not oversharing but discovery, because many of these agents show up without anyone deciding to deploy them.

References and additional resources

• Microsoft’s guidance on preparing SharePoint for Microsoft 365 CopilotMicrosoft’s secure and governed foundation for Microsoft 365 Copilot
• Microsoft’s documentation on Restricted Content Discovery
• Google’s enterprise security controls for Gemini in Workspace
• Google’s generative AI in Workspace privacy hub