If one autonomous agent is useful, it is natural to ask whether many agents working together could be dramatically more effective. Over the last few weeks, the AI community has been testing this idea in practice by running large numbers of agents in coordinated swarms. The early results are clear: swarms can be far more capable than individual agents, but only under the right conditions. 

Two distinct patterns have emerged. There are controlled swarms, such as Cursor’s web browser demo, that operate within clearly defined boundaries. There are also uncontrolled swarms, such as OpenClaw, that run with broad, implicit access to user machines and assets.

The productivity gains from swarming are real. In controlled environments, swarms demonstrate that large numbers of agents can coordinate work, iterate in parallel, and solve problems faster than any single agent or human team. At the same time, uncontrolled swarms show how easily these same techniques can bypass basic security and access expectations when they are given ambient authority.

This tension defines the current moment. Builders can see which swarms unlock, and  that running many agents together is qualitatively different from running one. What they cannot yet do is ship these systems safely into enterprise or cloud-native environments using existing operational and security models.

Can agent swarms operate safely?

Cursor’s web browser demo is a strong example of what a well-scoped swarm can achieve. Thousands of agents coordinated to produce a complex piece of software in a short time. The result was not just faster output, but a demonstration that fully autonomous software development is approaching practical reality when the environment is tightly controlled.

In contrast, MoltBot and OpenClaw highlight the risks of applying the same ideas without sufficient constraints. These systems emphasize accessibility and broad capability, but they rely on sweeping access to local machines, filesystems, networks, and credentials. That access is rarely transparent to users and is difficult to reason about or audit. The resulting behavior is impressive, but it comes with significant security and operational risk.

Despite these differences, both approaches point to the same underlying shift: swarms allow agents to operate more efficiently and accurately than previously thought possible, but how do we run them at scale? And in the case of OpenClaw specifically, how do we operate them safely?

Why agent swarms do not translate to production

Today’s swarms run into two fundamental problems.

The first is that successful swarms lack operational rails. Most demonstrations rely on local machines or tightly constrained sandboxes. There is no durable hosting model, no monitoring for swarm health over time, and no mechanism to allow swarms to continue operating without being blocked by slow or manual human decisions. As a result, these systems remain confined to experiments and greenfield use cases.

The second problem is risk. Uncontrolled swarms raise difficult questions for organizations. How do you prevent company-owned assets from being pulled into a swarm unintentionally? How do you stop new swarms from forming across provisioned infrastructure without oversight? How do you ensure that actions taken by agents are attributable, auditable, and reversible?

These are not theoretical concerns. In cloud-native environments, agents run continuously, operate across shared infrastructure, touch production data, and act on behalf of many users. Ambient authority does not exist in these systems, and without explicit identity and access boundaries, swarms can become unsafe and unworkable.

What production-grade agent swarms require

For swarms to move into production environments, several capabilities are required.

There must be a persistent runtime where large numbers of agents can live indefinitely. Like Kubernetes, that runtime must support isolation, coordination, and state without relying on implicit machine-level authority.

Agents must have explicit identity from creation through execution. Every action must be attributable and auditable, with access that is scoped, time-bound, and revocable.

Finally, swarms must be able to act autonomously without being frequently blocked by human decision making, while still supporting human oversight for high-impact actions. This requires clear separation between what agents can do on their own and what requires approval or escalation.

We are excited that platforms and reference architectures are emerging that finally meet these requirements.

Agent swarm architecture in practice

To make this concrete, 1Password built a real-world scenario in which a large number of agents interact with real infrastructure using production credentials. We partnered with Autonomy because it provides a platform that treats agent identity and isolation boundaries as first-class concerns.

Most runtimes are designed for short-lived workloads, stateless services, or systems that inherit identity and access from the underlying environment. In contrast, Autonomy is designed for long-horizon agents where each agent is a concurrent actor with its own cryptographic identity and isolated workspace (filesystem, shell, etc).

The Autonomy runtime schedules an actor only when it has a message for that actor to process, so thousands of agents can run in parallel on a single machine. Agents can spawn sub-agents, discover each other, and collaborate over encrypted channels.

Here is how we created a swarm:

Crucially, identity and authorization are explicit rather than inherited. Each agent has a distinct authenticated identity throughout its lifecycle, and every action is attributable by design. This makes integration with 1Password straightforward. Agents authenticate as themselves, request access dynamically, and receive credentials that are scoped to intent, time-bound, and revocable.

This is in sharp contrast to OpenClaw where there is neither attributable identity nor isolated resources. In our demo, agents do not inherit access from the machine or the network. Instead, they authenticate through Autonomy as themselves to receive auditable and limited access through 1Password.

An autonomous site reliability demonstration

With this foundation in place, we built an autonomous SRE system that operates with minimal interruption. The system monitors reliability signals and, when degradation occurs, spins up swarms of agents to investigate. Some agents inspect logs, others correlate metrics, and others evaluate remediation options. The swarm scales dynamically based on the severity of the issue and scales back down once conditions stabilize.

When remediation falls within delegated authority, agents can act directly using credentials provided securely by 1Password. When a situation requires elevated access or carries higher risk, the system pauses and brings a human into the loop to approve or extend access. No access is implicit, no credentials are permanent, and every action is attributable to a specific agent and decision.

This integration with 1Password reflects how real systems could safely delegate authority to autonomous agents in cloud environments. Check it out below:

How to use 1Password to secure agent swarms

Recent attention around agent swarms has highlighted two very different paths forward. On one end are carefully scoped systems, such as Cursor’s internal swarm experiments, that demonstrate what coordinated agents can achieve when they operate within controlled environments. On the other end are systems like OpenClaw that rely on broad, implicit access to user machines, and spontaneously form their own coordination layer through unsafe public channels. The capabilities may look similar on the surface, but the underlying execution models are not.

The risk with agent swarms is an execution model that unlocks swarm-level capability by discarding access boundaries and relying on ambient authority. That approach can produce impressive results, but it does not hold up for serious use cases where control, auditability, and trust are required.

1Password can solve this problem. As systems become more autonomous, access decisions shift from individual actions to intent. Humans do not want to approve every agent request. They want to express intent once, such as allowing a swarm to access a specific set of resources for defined purposes, and rely on the system to enforce that intent safely across many agents.

Existing access models do not support this shift. They either require constant human intervention or push teams toward unsafe shortcuts that break security controls. Neither approach scales. What is missing is a way to translate a single, high-level access decision into scoped, time-bound authority that can be applied across a swarm while remaining auditable and revocable. 

Agent swarms require execution environments with explicit identity and durable boundaries. When those foundations exist, as they do in platforms like Autonomy, 1Password becomes the access plane: enforcing intent across swarms with scoped, time-bound authority, without sacrificing speed or scale. 

If agent swarms are going to become part of production infrastructure, security cannot be something they bypass to be effective. It has to be something that scales with them.