The Agentic AI Taxonomy, Part 3: Sandboxed Agents

Welcome back to our series exploring the Numberline Agentic AI taxonomy, one category at a time. If you’re just joining us, you can read where we introduced the new taxonomy and analyzed the first agent type.

In this installment we’re looking at the next sub-type within the Provider-hosted, general-purpose category: Sandboxed agents.

These are general-purpose agents built and operated by the AI vendor, with the ability to execute inside a provider-hosted sandbox running in the vendor’s cloud. The sandbox is essentially a virtual machine dedicated to the agent instance, and it lets the agent carry out long-running, multi-step work without needing a continuous connection to the user’s device. These products are marketed on exactly that promise: they work on your behalf, interact with websites from their own browser, and keep going even when your laptop is closed or when your device is turned off.

Examples include ChatGPT agent, Google’s Gemini Spark, Manus, and Anthropic’s Claude Cowork. The vendors describe the architecture plainly. Anthropic says “Claude’s work runs in an isolated environment on Anthropic’s servers, separate from your computer and your network,” while Manus states that it “operates in a complete sandbox environment—a virtual computer with internet access, a persistent file system, and the ability to install software and create custom tools.” 

One wrinkle worth noting before we go further: some of these products blur the line between this category and our Local-access category. Manus offers a desktop mode that operates directly on the user’s machine, and Claude Cowork can reach local files and the user’s browser through the Claude Desktop app even while the session itself runs remotely. Our taxonomy handles this by classifying the mode of operation rather than the product name. When these tools run purely in the vendor’s cloud sandbox, they’re the sandboxed agents we analyze here. When a user enables the local bridge, that instance picks up Local-access characteristics too, and the controls from that future article will apply on top of these.

To make the core risk concrete before we get formal about it: imagine you ask one of these agents to build a slick presentation from company data. The agent, working alone in its sandbox, decides the best way to produce a polished chart is to upload your data to a third-party chart-rendering service. You get a nicely formatted chart back. The side effect is that an outside provider now has a copy of your data, and nobody asked you first. That decision happened autonomously, on the vendor’s machines, outside your network, and outside your view. Keep that scenario in mind as we walk the six attributes.

Data: Inputs

These agents have no local system access by default, so like chat assistants they process what the user hands them: prompts, uploaded files, pasted text, and content at public URLs. Also like chat assistants, they can read data inside corporate SaaS tenants such as M365, Google Workspace, Slack, and Atlassian once a user connects them.

What’s different is the autonomy. These agents run decoupled from the user’s device and operate on long-running tasks without user involvement. They access data on behalf of the user, either through configured connectors or by pausing and asking the user to authenticate a session for them. And this on-behalf-of mode is where we expect most users will live, because that’s where the value is. Using these agents against corporate data is genuinely useful, which is precisely why the risks deserve attention.

Those risks go beyond uploading sensitive data to the AI vendor. As the chart example shows, these agents can and will use external tools and services to process your data, independently and without asking. And unlike the previous category, where the user’s device at least originates the conversation, essentially all of a sandboxed agent’s activity happens on the vendor’s machines and networks. Anthropic is candid about this: “Cowork has unique risks due to its agentic nature and internet access,” and Claude in a remote session “can still browse the web, read email and documents through your connected apps, work in folders you’ve connected, and take actions through those same channels.”

Controls

• Detect or block sensitive content leaving corporate-managed devices
• Detect or block sensitive content leaving the enterprise network for the AI provider’s platform
• Define which users or groups can perform which actions within each SaaS platform
• Centralized infosec control over the permissions that user accounts, and the AI systems connected through them, hold within SaaS environments

Recommendations

• On corporate networks, use TLS decryption and DLP to inspect outbound traffic and catch sensitive data in prompts or uploads (typically part of your CASB or SWG platform)
• Apply DLP policies to stop sensitive files from being uploaded to these agents
• 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.
• Examine the sandboxed-agent capabilities and controls your sanctioned AI platform exposes, and enforce them where appropriate

Data: Outputs

Like chat assistants, these agents create artifacts to satisfy user instructions. Those outputs lose any provenance or classification that was attached to the input data. And AI systems do return erroneous results, so humans and upstream systems need to validate what comes back. That risk grows with autonomous multi-step processing, since an error early in a processing chain can compound quietly.

User education has to be part of the solution here, supported by processes for manual or automated classification of returned artifacts. Ideally, sensitive data shouldn’t be sent to these agents in the first place.

Controls

• Filter or 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
• Audit or restrict the SaaS application authorizations granted to the agent platform

Recommendations

• Educate end users on how these systems work and the risks of processing sensitive corporate data through them. For this category, education is a primary control, not a consolation prize
• Consider blocking this agent type entirely if your AI platform’s enterprise controls support it.
• Use endpoint, network, or platform DLP to detect or enforce restrictions on sensitive data returned from these agents.
• Work with SaaS application owners to define allowed and disallowed actions per platform

Identity

These agents do have an identity, but it’s irrelevant from the enterprise perspective. It’s effectively a workload ID that exists only for the AI provider that provisions and hosts the sandbox. From our view, these agents operate on behalf of the user for any external action they take.

However, there are two paths by which they acquire that on-behalf-of access. The first is the configured connector, the same OAuth-style grant we covered for chat assistants. The second is session handoff: the agent hits a login wall, pauses, and asks the user to authenticate inside the agent’s own browser. The user logs in, the agent proceeds, and the authenticated session persists in the vendor’s cloud, often across tasks, until someone signs out. This is a common way these agents get authenticated access to sites that have no connector.

It’s also worth exploring a “devious user” scenario: a user could independently create accounts on prohibited or unknown SaaS systems and hand the agent those credentials. The agent would then be able to access those systems and potentially share corporate data with zero enterprise visibility or control.

Controls

• Agent platforms can perform domain capture on unmanaged account creation, ensuring enterprise visibility
• Enterprise-controlled SaaS resources can disallow on-behalf-of agent access, or restrict it to specific user groups and actions

Recommendations

• Examine your sanctioned AI platform’s sandboxed-agent capabilities and controls, and enforce as appropriate
• For every significant SaaS platform, inventory current access, decide on controls, and start enforcing limits on on-behalf-of agentic access. You’ll need to work with SaaS application owners to define what’s allowed
• Tune your identity monitoring for the traffic pattern these agents create: actions arriving at your SaaS platforms from the AI vendor’s IP ranges under a legitimate user’s identity. Device-based and network-based anomaly detection won’t catch this on its own. IdP conditional-access rules and identity-anomaly monitoring are the tools that will

Authority

Sandboxed agents carry the same level of authority as the chat assistants we discussed previously. Whatever the user can do, the agent can do on their behalf, nothing more. The distinction is that much of the activity now occurs outside the enterprise’s view.

Of course, our familiar caveat applies here as well. The user may be over-privileged, and an autonomous agent can exercise those privileges at a scale and speed no human would, touching more data and taking more actions in an afternoon than the user might in a quarter.

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 data, prompts, and requests sent to these agents. Keep in mind that for these agents, the prompts can be lengthy and indirect

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. Use that process to constrain over-privileged accounts before an agent inherits them
• Determine whether external AI usage warrants deep inspection of prompts, such as AI analysis of the prompts and uploaded data

Autonomy

These agents absolutely act with autonomy. By design, they take actions and complete long-running tasks without human intervention; it’s the core of their value proposition.

The good news is that the platforms are starting to expose meaningful human-in-the-loop controls. Claude Cowork is a useful concrete example: it offers three permission modes, ranging from manual approval of every action, to automatic approval with a per-action safety review that blocks anything it judges unsafe, to skipping approvals entirely. Certain sensitive actions, like granting access to additional folders, deleting files, or creating scheduled tasks, stay human-gated regardless of mode. Expect competing platforms to converge on similar controls.

Of course, the very essence of this category is that agents operate independently of users, which cuts directly against keeping a human in the loop. Every enterprise will have to find its own balance point.

Controls

• Human-in-the-loop enforcement for defined action types, where the platform exposes it
• Restrictions on agent activities, at either the individual user or centralized enterprise level

Recommendations

• Evaluate the human-in-the-loop controls your AI platform exposes for enterprise use, and set defaults deliberately rather than accepting the vendor’s

Management

These agents are subject to varying degrees of enterprise control. As with chat assistants, enforce user registration under the centrally controlled enterprise account, and expect control over which SaaS applications are enabled for agentic access.

Platform-side visibility is uneven but improving, and worth checking specifically rather than assuming. Cowork again makes a useful example of both sides: its activity is not captured in Anthropic’s Compliance API at this time, but Team and Enterprise admins can monitor Cowork activity across the organization via OpenTelemetry, and org owners can disable web search or browser use for it entirely. Know exactly which of these capabilities your sanctioned platform offers, because the gaps define your blind spots.

Controls

• Access and authorization controls for sandboxed-agent reach into enterprise-controlled SaaS applications
• Platform controls over whether users can use sandboxed agents at all
• Organization-level toggles for high-risk capabilities such as web browsing
• Centralized management, monitoring, and telemetry for 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 local bridges, the desktop-app connections that let a sandboxed agent reach local files or the user’s browser, and communicate it clearly

Lifecycle

The agent instances themselves are ephemeral, spun up for a task and dissolved when it completes. But it would be a mistake to conclude there’s no lifecycle to manage here, because three things persist well beyond any individual task.

First, workspaces: These platforms maintain long-lived work areas holding context, files, and project data for extended periods. Second, authenticated sessions: Credentials established through session handoff can persist in the vendor’s cloud across tasks until explicitly signed out. Third, and most easily forgotten, scheduled tasks: These platforms let users create recurring tasks that run remotely with no device online. A scheduled task is a standing piece of automation that outlives the user’s attention, and it needs decommissioning like any other asset. What happens to a departing employee’s recurring agent tasks is an important lifecycle question, which demands ongoing tracking and management.

Controls

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

Recommendations

• Set up systems and processes to track employee usage of these platforms and their connected SaaS systems
• Report on usage, and allocate time to validate how these agents are actually being used
• Add agent workspaces, persistent sessions, and scheduled tasks to your identity lifecycle and offboarding checklists
• Treat these platforms like any other asset, categorized and managed at a criticality level that matches how your business actually uses them

Summary

Ultimately, these agents raise risk in two distinct ways.

First, their multi-step autonomous activity occurs outside the view and control of both the end user and the enterprise. The chart-rendering scenario we posed in the introduction is a good example of how these agents can process or transmit data in ways nobody explicitly requested.

Second, their network communications no longer originate from the user’s device or corporate network at all. Everything initiates from the sandbox in the vendor’s cloud. The enterprise loses network-level visibility and control, and a prompt injection attack or hijacked agent could exfiltrate data without the enterprise ever seeing the traffic. Compounding this, the actions that do reach your SaaS platforms arrive from the vendor’s IP space under a legitimate user’s identity, which can defeat device-based anomaly detection. Identity-layer monitoring has to pick up that slack.

This technology area is moving fast. Expect AI platforms to keep changing how their systems operate, and to remain ahead of what we’d prefer from enterprise visibility, control, and reporting perspectives. Platform reporting will improve, but for the foreseeable future it will lag the rate of innovation. Which means that to a not-insignificant degree, we’re going to have to rely on our users to follow the guidelines we’ve communicated. That’s exactly why user education sits unusually high on the controls list for this category.

Next up in this top-level category: workspace-embedded agents, where the agent stops borrowing the user’s identity and starts carrying its own. This is a big shift, which we’ll be tackling in our next article.