The Agentic AI Taxonomy, Part 2: General-Purpose Chat Assistants

Welcome back to our series walking through the Numberline Agentic AI taxonomy, one category at a time. If you missed our earlier article where we introduced the new taxonomy, start here.

Today we’re digging into the first category: Provider-hosted, general-purpose agents. Recall that these are vendor-built and vendor-operated, with access to public sources and sites but no access to local or enterprise resources by default.  As we’ll explain below, they can reach private cloud-based resources, once a user connects them.

This category has three sub-types, and we’re starting with the simplest one: chat assistants. These are the high-visibility AI tools everyone already knows, Claude, ChatGPT, Copilot, Gemini, and others. Millions of people, including plenty of your employees, use them every day.

Before we get into our six-attribute analysis, we have two points to highlight. 

First, we deliberately call these chat assistants rather than agents. We chose these terms to illustrate a real behavioral difference between these and the rest of the taxonomy: chat assistants are reactive and limited in scope, while true agents take more independent, multi-step action. We’ll return to that contrast as the series progresses.

Second, a correction to how people often describe these tools. It’s tempting to say chat assistants are accessed solely through a browser, but that’s not accurate. Claude, ChatGPT, and the rest all ship desktop and mobile apps too. What actually matters for security purposes isn’t the access channel, it’s whether the assistant has expanded local reach. In their default configuration, none of these access methods grant the assistant standing access to your local filesystem or device. A browser tab and a desktop window are functionally the same thing from a controls standpoint. That’s why chat assistants stay in this category regardless of which client you use. Future articles will address other scenarios where tools are built to reach beyond the conversation into your local environment on an ongoing basis.

With that set, let’s dive into our analysis. If you recall, from Part 1, we’ll be examining these chat assistants across our six attributes: Data, identity, authority, autonomy, management, and lifecycle. For each of these, we’ll first discuss them, and then list the relevant controls and recommendations.

Data: Inputs

These agents process any data a user hands them directly, prompts, uploaded files, pasted text, and content at public URLs.

They can also read data inside corporate SaaS tenants, such as M365, Google Workspace, Slack, and Atlassian, once a user connects them. That’s the point where enterprise data can end up outside the enterprise’s visibility and control if nobody’s watching.

How much control the enterprise actually has depends on the specifics of the integration. In general, enterprise accounts on SaaS platforms give tenant administrators control over whether and how a chat assistant can read and act on their SaaS data. As one example, Claude’s M365 connector is available even on the free Claude tier, but using it against a corporate tenant requires the right enterprise license and admin configuration on the M365 side.

From a Zero Trust perspective, these assistants amplify the need for data classification and data processing controls. Users are still the actors initiating actions and accessing data, so there is a need for more user education on proper AI usage and handling of enterprise data, to prevent uploading of sensitive corporate data.

These enterprise controls are useful and worth deploying. They’re also not bulletproof, and as we’ll see in future articles covering other agent types, they hold up best when paired with other layers of control.

Controls

• Detect or block sensitive content leaving corporate-managed devices
• Detect or block sensitive content leaving the enterprise network
• Configure and limit access to SaaS data within corporate tenants
• Define which users or groups can perform which actions within the SaaS platform

Recommendations

• On corporate networks, use TLS decryption and DLP to inspect outbound traffic and catch sensitive data in prompts or uploads. (This is typically part of your CASB or SWG platform)
• Detect and block risky outbound traffic from managed devices via endpoint DLP or XDR.
• Apply DLP policies to stop sensitive files from being uploaded to chat assistants
• Publish and require acceptance of Acceptable Use Policies for enterprise data
• Work with SaaS application owners to define allowed and disallowed actions for each platform, by user group

Data: Outputs

Chat assistants produce text, code, images, and files like Office documents. Within a connected SaaS platform, they can also create or edit content, and sometimes send messages directly, through Slack, Teams, or email, for example. Note that data or artifacts created by these assistants lose their provenance and classification, so there’s a definite risk associated with the returned data. User education can help reduce this risk, with processes to support either manual or automated classification of returned artifacts. Ideally, sensitive data should not be sent to these chat assistants to begin with. 

Controls

• Block clipboard access and file downloads on corporate-managed devices
• Apply mobile device management for app installation and data usage controls
• Restrict SaaS platform data and activity access to limit what the agent can reach

Recommendations

• Use Secure Web Gateways or browser controls to block downloads from specific destinations
• Block clipboard access through endpoint or secure browser controls
• Enforce application allow-listing to prevent unsanctioned app usage
• Use endpoint, network, or platform DLP to enforce access restrictions on sensitive data returned from these assistants
• Work with SaaS application owners to define allowed and disallowed actions per platform

Identity

Agent identity: within its own self-contained environment, and when reading public web content, a chat assistant has no principal at all. There’s no user to authenticate against and nothing to authorize, it’s simply processing what’s in front of it. Once a connector is involved and the assistant reaches into a SaaS resource, that changes: it acts on behalf of the user, using that user’s own credentials and access.

User identity: people reach these assistants either anonymously or by authenticating to the vendor platform with personal or enterprise credentials, including SSO where configured.

Controls

• Enterprise tiers can enforce SSO, MFA, and device posture checks through your IdP
• Agent platforms can perform domain capture on unmanaged account creation
• Enterprise-controlled SaaS resources can disallow on-behalf-of agent access, or restrict it to specific user groups and actions

Recommendations

• Configure the agent platform for SSO and domain capture
• Configure your IdP with appropriate device posture checks and MFA
• Use email scanning and domain or content blocking to catch use of non-enterprise accounts on sanctioned platforms
• For every significant SaaS platform, inventory current access, decide on controls, and start enforcing limits on agentic access through user authentication. You’ll need to work with SaaS application owners to define what’s allowed.

Authority

We touched on this above: chat assistants act on behalf of the user, subject to whatever constraints the enterprise has configured in the SaaS tenant. They carry no identity of their own, so there’s no separate grant of power to worry about beyond what the user already has.

That gives a clear answer to the question we ask of every agent type here: does it have more, less, or different authority than the person driving it? For chat assistants, the answer is straightforward: Exactly the same authority. Whatever the user can do, the assistant can do on their behalf, nothing more. That’s a useful baseline to keep in mind, because it won’t hold for every category in this series. And this simpler type of agent is a good way for us to start thinking about the potentially over-privileged access that user or agent identities may have. 

Controls

• For enterprise-controlled SaaS resources, define which users or groups can authenticate, and what actions they or an on-behalf-of agent can take
• Use client-side DLP or HTTP traffic inspection to evaluate prompts and requests

Recommendations

• Inventory every significant SaaS platform, decide on controls, and start enforcing limits on user access and authorization. 
• Re-evaluate existing user access with the assumption that an AI agent may now be exercising it, potentially touching more data or taking more action than the human ever did on their own. Use this process to constrain user accounts, and avoid over-privileged agent access.

Autonomy

Chat assistants aren’t autonomous in any meaningful sense. They act only in response to a user’s query. They may take a few minutes to complete something complex, but they aren’t orchestrating multi-step work on their own initiative.

Controls

• User authorization, performed by the assistant on behalf of the user

Recommendations

• Recognize that these tools amplify and accelerate what a user asks for, but don’t expand the underlying scope of control. They’re bound by that user’s access and don’t make independent decisions.
• Make sure user authorizations within SaaS applications are well understood. A complex or high-impact action can be triggered by a chat assistant just as easily as by the user typing it manually.

Management

Chat assistants aren’t managed by the enterprise directly, since the vendor operates the platform itself. What the enterprise does control is whether and how its users can access these tools, and what they’re permitted to do on the user’s behalf within enterprise-controlled SaaS platforms.

For enterprise-managed accounts, which we strongly recommend, the enterprise gains real visibility and control over how its people use the platform. That typically includes SSO integration, domain capture (so anyone signing up with a corporate email lands under enterprise management automatically), role management tied to SCIM provisioning, centralized billing, controlled integration into your SaaS tenants, audit logs, a no-training-on-your-data commitment, and support for regulatory requirements like GDPR or CCPA.

We think that list makes the case for itself. These controls cost money and effort to maintain, but standing up and enforcing a centrally managed enterprise account is table stakes for enterprise security at this point, not a nice-to-have.

This is also where the local file system access beast rears its head. Several desktop chat clients let a user grant the app local filesystem access in a couple of clicks. Once that’s on, you’re no longer dealing with a contained chat assistant, you’ve effectively created a Local-access agent, with everything that implies for the controls we’ll cover in a future article. It’s worth knowing this setting exists and explicitly deciding whether to allow it, rather than letting individual users flip it on without realizing what it changes.

Controls

• Access and authorization controls for chat assistant reach into enterprise-controlled SaaS applications
• Centralized management and monitoring of enterprise-tier accounts

Recommendations

• Formally procure and enforce use of enterprise accounts on sanctioned AI platforms
• Block unsanctioned platforms and free-tier accounts on sanctioned ones
• Apply your standard identity governance processes to agentic AI platforms and to on-behalf-of access into SaaS platforms
• Decide on a policy for desktop-client local filesystem access, and communicate it clearly

Lifecycle

The typical enterprise system lifecycle model doesn’t really apply here, since the vendor runs the platform and updates it on their own schedule. What matters instead is watching how the tool’s capabilities, reach, and connector scope change over time.

As we’ve all seen, these assistants keep getting more and more capable. As they take on deeper and more sophisticated actions, users will lean on them for increasingly business-critical work. That’s worth tracking from an availability standpoint: if access gets unexpectedly disrupted, the business impact might be bigger than you’d expect. Even a deliberate, temporary outage while (for example) your team tests new controls can land harder than planned, so it pays to coordinate with the business users who depend on these tools day to day.

The same goes for scope. A chat assistant might gain new abilities within a SaaS platform you already approved, without that change ever crossing your desk. Tracking which systems your users’ assistants can reach, and staying current on vendor releases, is the practical version of lifecycle management for this category.

Controls

• Usage and activity logs
• Visibility into new releases and platform updates

Recommendations

• Set up systems and processes to track employee usage of chat assistant platforms and their connected SaaS systems
• Treat these platforms like any other asset, categorized and managed at a level of criticality that matches how your business actually uses them

Companion Scope

This one’s easy for chat assistants: there are no agent infrastructure components, gateways, MCP servers, or anything similar, under enterprise control here. Some connectors may be built on protocols like MCP under the hood, but since the enterprise doesn’t stand up or operate that infrastructure itself, it’s out of scope for this category. We’ll pick that thread back up when it actually matters, starting with Local-access agents.

Summary

That’s our first pass through the new taxonomy, applied to the simplest case in the set. Chat assistants are the category most of your users already touch daily, and hopefully this gives you a concrete way to reason about where the real risk sits, and where it doesn’t.

If you’d like a more visual way to consume the information in this blog, take a look at our experimental interactive Chat Assistant security navigator below, and let us know what you think in the comments.

Okay, that analysis was for just the first of 11 types of agents. We can already tell that this is going to be a legitimately interesting and substantive series of articles. We do think it’ll get a bit more streamlined over time, but all we can say is “get ready!” We can’t promise that future articles will be significantly shorter, but we can promise that they will continue to provide you with in-depth analysis, and bring our Zero Trust perspective to the set of recommendations.

---

Interactive Chat Assistant Security Navigator

Hover over each of the visual components, including connecting lines, for guidance.