The Agent Party Is Moving from the Endpoint to the Cloud

The first wave of mass agent adoption started on the device. The next wave will be shared, persistent, and cloud-hosted.

For the past six months, the most visible progress in AI agent adoption has happened at the endpoint.

As coding agents such as Claude Code and Cursor surged in popularity, agents began appearing in terminals, IDEs, browsers, desktop applications, and local workspaces. They could see the files in front of us, operate the applications we already use, and take action with the permissions of the person sitting at the keyboard. This made them useful quickly. It also made them easy to try.

Suddenly, the endpoint became interesting. Agents began to sprawl across developer machines and workflows. Secrets, excessive permissions, and misconfigurations soon followed, and a wave of solutions emerged to secure these endpoint agents, from agent visibility to runtime controls and sandboxing.

But the endpoint was never going to be the final home of the agents.

The next phase is already taking shape: the center of gravity of agent adoption is moving to the cloud. Not because local agents are going away, but because the value of an agent changes when it stops being a personal tool and becomes shared organizational infrastructure.

This trend is already showing in the data - OpenRouter’s weekly token data published in mid September offers a concrete signal: agentic traffic made up 82% of all tokens on the platform, making agents the dominant source of token consumption on a cloud model platform. The endpoint remains where people delegate and review, while execution increasingly runs across shared infrastructure.

The endpoint was the right place to start

The endpoint gave agents something the cloud did not: immediate access to the context of a real person doing real work.  

A desktop agent could read a folder, open a browser, operate an application, inspect a codebase, or work across the tools already configured on a laptop. A developer could point an agent at a repository. A knowledge worker could give it a folder of contracts, a half-finished presentation, or a set of email threads. The distance between intention and action became very small.

That made the endpoint the natural place for experimentation. It removed the need to build integrations before seeing value. It let agents learn from the messy, local context where work actually happens. 

The problem is that local context is not the same thing as organizational context.

An agent running on one employee’s machine is often tied to one person, one device, one installation, and one set of permissions. It may be powerful, but it is difficult to share, schedule, monitor, reproduce, or improve across a team. When the employee changes roles, the context may disappear with them. When the agent is copied into another workflow, its permissions and instructions may change without anyone noticing.

The endpoint is an excellent place to discover what an agent can do. It is a much less effective place to run the agentic workforce of a large organization.

The cloud is becoming the place where work persists

That shift is visible in the products being launched by the major AI platforms. The point is not simply that the center of gravity of agent adoption is moving into the cloud, but that the work agents perform is becoming durable across devices, surfaces, and people. As context, instructions, artifacts, and permissions persist beyond a single machine, the agent starts to look less like a personal tool and more like organizational infrastructure.

Anthropic made this transition explicit in July, when it moved Claude Cowork beyond the desktop to web and mobile. In September, it went further by merging Cowork and Claude Chat into one Claude experience. A task can now begin at a desk, be checked from a phone, and continue after the laptop closes, while projects, artifacts, connectors, and skills carry across chat and Cowork. The user no longer has to decide whether a request belongs in a conversational interface or an agentic workspace.

The same pattern is emerging at the enterprise layer. In April, OpenAI launched Workspace Agents and Google introduced Gemini Enterprise, both framing agents as shared infrastructure rather than individual assistants. Teams can build, share, and run agents, connect them to files and tools, invoke them from collaboration surfaces, and manage identity, permissions, monitoring, and governance centrally. This changes the unit of adoption: the agent becomes a reusable team object that can support a process, not just a personal workflow.

Taken together, these product shifts show why the endpoint is becoming one surface in a larger agent system. It remains where people delegate, review, and intervene, but execution, memory, and control are increasingly moving into the cloud. Agents are being built from multiple interfaces, shared across teams, connected to enterprise systems, and handed off to background runtimes, creating a need for centralized control across the full chain.

Why this shift is inevitable

There are two forces pushing agents beyond the endpoint: business efficiency and security.

Enterprise value requires shared infrastructure

A local agent can save one person an afternoon. A shared agent can become a repeatable business process. Large-scale AI projects rarely fail because the first user cannot get value from the tool. They fail because the value remains trapped in a local workflow. One employee finds a clever way to reconcile data, prepare a report, qualify a lead, or investigate an issue, but the process is difficult to share, monitor, and to make reliable for everyone else.

To become an organizational capability or valuable asset, the agent needs to be available when the user is not. It needs shared context, reusable skills, stable integrations, and a permission model that works across departments. It needs to run on a schedule, handle handoffs, preserve institutional memory, and expose its outputs to the people and systems that depend on them.

This is why large AI projects tend to move from a local experiment toward a shared, governed environment. The cloud is one important way to provide that environment, but the deeper transition is from personal execution to organizational execution.

An agent built in a SaaS studio can be shared with a team. An endpoint agent can be connected to a cloud service. A cloud agent can be invoked from Slack or surfaced in an existing business application. The boundaries between these surfaces are becoming more fluid, not less.

That creates leverage for the business. It also creates a much larger attack surface.

Endpoints are dangerous places to run agents

Endpoints are especially dangerous for agents because they collapse three boundaries that normally limit software: the boundary between a trusted user and automation, between untrusted content and executable instructions, and between one application and the rest of the user’s authenticated environment. 

An agent can read a webpage, email, document, or codebase, interpret content inside it as an instruction, and then act through the user’s existing sessions and tools. A single malicious input or mistaken plan can therefore become an authenticated action on the machine or across connected services, combining the speed and reach of automation with the privileges of a human user.

It may have access to local files, browser sessions, messaging applications, development environments, cloud credentials, corporate VPNs, and the user’s identity. It can interact with systems in ways that are difficult to distinguish from the user themselves. If an agent is manipulated by untrusted content, a malicious webpage, a poisoned document, or a prompt injection, the resulting action can happen inside a highly privileged environment.

The risk is not only that an agent produces a wrong answer, but rather that it takes a wrong action with the authority of the person who launched it.

Local execution also creates visibility problems. Security teams may struggle to maintain a complete inventory of agents, understand which tools they can access, reconstruct what they did, or detect patterns across many devices. The organization sees the outcome, but not necessarily the full chain of prompts, tool calls, data movement, and approvals that produced it.

Cloud execution does not remove these risks. It makes them more governable. A managed runtime can assign an explicit identity to each agent, isolate execution, apply policy before a tool call, log activity centrally, enforce approval checkpoints, and suspend an agent when behavior looks wrong. These controls are much harder to implement consistently across a fleet of personal endpoints.

That is why the major platforms are not simply putting agents in the cloud. They are building runtime policies, identity, gateways, registries, observability, and memory around them.

What this means for CISOs

For CISOs, the most important implication is that agent security is becoming a cross-surface problem. The relevant question is no longer, “How do we secure the AI agents installed on employee endpoints?” It is, “How do we secure every place an agent can be created, connected, executed, and used?”

The scope now spans four surfaces.

Endpoint agents. These include desktop, terminal, IDE, and browser agents, as well as local copilots that can access files, applications, and user credentials.

SaaS-managed agent studios. These are embedded in platforms such as ChatGPT, Claude, Gemini, Microsoft 365, and other business applications, where employees can create, connect, and share agents.

Self-hosted and cloud agents. These include long-running, scheduled, and production agents operating in managed runtimes or enterprise cloud infrastructure, often with access to systems of record.

Third-party agents. These are operated by suppliers as part of the services they provide, such as agentic capabilities embedded in legal, finance, customer-support, or data-processing products. They may interact with customer information, connected applications, delegated accounts, or supplier-managed systems even when the customer cannot directly inspect their configuration, permissions, or runtime behavior.

These surfaces are connected. An endpoint agent may invoke a cloud service, a SaaS-built agent may call third-party tools, and a vendor-operated agent may act inside a customer’s connected environment. A security product that sees only one part of this chain will miss the actual risk.

Team8’s CISO survey shows that CISOs already understand this challenge, and that it is becoming more urgent than ever.  AI and agent security is the top CISO pain point in 2026, selected by 78% of respondents, compared to 39% in 2025.  However, solution implementation is still catching up, as are budgets. 

CISOs should look for solutions that provide continuous visibility and control across all four surfaces. They need to know which agents exist, who created and uses them, what identity and permissions each agent carries, and which data, tools, connectors, skills, and systems it can reach. They also need to understand where an agent was built, where it executes, how it moves between surfaces, and what prompts, tool calls, data transfers, and approvals shaped its actions. That visibility must support the detection of prompt injection, tool abuse, data leakage, and anomalous or rouge behavior, as well as the ability to pause, constrain, or remove an agent when it is no longer trusted.

The winning security architecture will not force organizations to choose between endpoint and cloud. It will connect endpoint, SaaS-managed, self-hosted, and third-party agents, understanding the user, the agent, the build surface, the runtime, the tools, the data, and the action as one continuous chain.

The road ahead - the agent security perimeter is expanding

The endpoint was where agents first became useful. It will remain an important place to secure them. But it is no longer the whole story.

Agents are now being built inside SaaS products, shared across teams, invoked from collaboration tools, connected to enterprise data, and delegated to cloud runtimes. The agent security perimeter is expanding from the device to the full agent lifecycle.

For founders, this creates an opportunity to build security products that understand agents across surfaces, rather than treating them as another category of endpoint software or another API integration to monitor.

For CISOs, the mandate is clear: do not secure only the agent on the laptop. Secure the entire agentic system, from creation to configuration to execution to action, across the endpoint, the SaaS studio, and the cloud runtime.

The agent party is moving from the endpoint to the cloud. Security needs to be at every stop along the way.