I downloaded OpenClaw when it first came out mostly out of curiosity. The tool shows you an install prompt and asks if you want to proceed. I said no.
A day later, our security team told me I was the subject of a security policy violation. The install script had npm-globally installed the tool on my machine anyway, regardless of what I clicked.
I think the story matters for security teams and business leaders alike because it illustrates a problem every company is facing right now. Once OpenClaw, or any locally installed agent, is running on your machine, it has access to your filesystem, your SSH directory, your AWS credential directory, and your graphics card. Most people downloading it do not fully understand the breadth of access they are granting and what that access enables. In practice, they’ve installed a user-authorized backdoor.
OpenClaw is not an outlier. It is a visible example of a problem agentic AI systems will have to confront as they move into broader use.
Execution models define the risk
Recent demonstrations of agent swarms have shown very different execution models. In one model, agents operate inside tightly controlled environments, with explicit access boundaries and defined scope. Those demonstrations show what coordinated swarms can accomplish when the runtime is constrained. But the risk profile changes significantly when those controls are removed.
OpenClaw represents a different execution model. It is built for broad accessibility and capability, and it relies on ambient access to local machines, networks, and whatever credentials happen to be present. Coordination emerges through shared channels rather than through tightly controlled runtime boundaries. From the outside, the capabilities may look similar.
The execution model is what ultimately changes the risk profile, because in a controlled environment access is explicitly granted and tightly scoped. On a local machine, an agent inherits whatever the machine already has. That becomes hard to reconcile with identity systems built around static, point-in-time delegation.
The delegation problem
Almost every agentic workflow today follows the same basic pattern: a human delegates access to an agent at a specific point in time, based on an assumption that the outcome will be deterministic. The agent will do what you intended when you authorized it, and that authorization will continue to reflect your original intent. In traditional systems, where execution paths are predictable and bounded, that assumption often holds.
With LLM-driven agents, that predictability weakens. The behavior isn’t fixed but evolves as the system encounters new inputs and context. Context can evolve mid-execution through prompt injection or other inputs, and the effective intent of the system can shift over time while the original authorization remains static. The authorization granted at a single moment can end up governing behavior that no longer reflects the original intent.
The problem gets worse once you factor in speed, because identity and authorization protocols were designed assuming a human would always be in the loop. Someone approves access, an action occurs, and approval is revisited if something changes. Agents don’t operate at human speed. They act continuously, at machine speed, often across many tasks simultaneously.
If you require re-authorization at every decision point, you introduce friction that quickly erodes productivity gains that made swarms attractive in the first place. At swarm scale, especially in environments where agents operate across shared infrastructure and production systems, the impact of a single compromised agent does not remain contained. When authority is ambient rather than explicitly scoped, the failure propagates through the coordination layer itself.
What the production version actually requires
For agent swarms to operate safely in production environments, several conditions need to hold at the same time. The runtime must support isolation, coordination, and state management without relying on implicit machine-level access. Each agent needs an explicit identity from creation through execution, rather than inheriting authority from the environment in which it runs.
Every action must be attributable to a specific agent and the authorization that granted it, with the ability to revoke access when circumstances change. The human oversight problem is harder to resolve. Teams do not want to approve every agent action because that undercuts the productivity benefit. Removing humans from the loop entirely introduces a different risk profile.
What’s needed is a clear boundary between what the swarm is allowed to do on its own and what requires escalation. That boundary has to be enforced by the system at machine speed, not by someone watching a dashboard.
What it looks like when it works
Consider a reliability incident in a cloud-native environment. A swarm might be tasked with investigating the degradation: one set of agents reviewing logs, another correlating metrics across services, another evaluating possible remediation steps. As severity increases, additional agents are assigned; as conditions stabilize, activity winds down. At each stage, actions remain bounded by explicitly delegated authority and subject to escalation if risk thresholds are crossed.
The system must adapt to changing conditions without abandoning those boundaries. Agents may collaborate and divide work, but identity and authority remain explicitly defined throughout execution. Scaling behavior does not alter the underlying identity or access constraints.
When an action falls within delegated authority, agents proceed using credentials that are scoped to the specific task and bounded in time. They don’t rely on whatever long-lived access happens to be present on the host, so if risk conditions change or elevated access is required, the system pauses and escalates rather than continuing on inherited privileges. Instead of relying on ambient trust, policy enforcement is continuous, and access remains revocable throughout the swarm’s lifecycle.
The difference from uncontrolled swarm models isn’t cosmetic. It’s structural because it affects how identity, access, and failure behave as the system scales. In systems built on ambient authority, agents inherit whatever access the host environment provides, which can create compounding risk as scale increases. In systems built on explicit identity and bounded delegation, scaling does not require surrendering control.
The intent problem
Authentication does not address what happens once an agent begins acting under delegated authority. As execution continues, context can shift and new inputs can change the effective intent of the system, while the original authorization remains static. Most identity and access models built around point-in-time grants are not well suited to reassessing that intent at machine speed. This results in a widening gap between what was approved and what the system is actually doing.
Enforce human reauthorization strictly and you constrain the productivity gains that made swarms worth building. Relax it and access persists without any ongoing assessment of whether the agent’s behavior still reflects the original intent. The system ends up oscillating between friction and blind trust — and neither position is workable at production scale.
What is required is a way to translate a high-level access decision — granting a swarm access to defined resources for a specific purpose — into scoped, time-bound authority that remains revocable throughout execution. Current identity and access models are not designed to express or enforce that kind of delegation.
Mitigating near-term risk
For those experimenting with OpenClaw or similar tools, isolation matters. Use dedicated sandbox hardware rather than a primary work machine, and create fresh accounts that are not connected to corporate systems. Resources should be separated and access tightly scoped. Anything the tool can reach should be treated as potentially exposed, because filesystem-level access provides broad visibility into local credentials and data.
For security teams considering agent governance, the central issue remains ambient authority. Agents should operate with explicit identity rather than inheriting access from the host environment, and credentials should be scoped to defined tasks and bounded in time. Logging must preserve attribution at the agent level so actions can be traced to a specific identity and authorization decision.
Donella Meadows wrote in Thinking in Systems that changing outcomes requires changing the system that produces them. The developers building tools like OpenClaw and the users experimenting with them are responding to incentives that prioritize productivity gains. Security infrastructure has not evolved at the same pace, and the gap is becoming harder to ignore.
If agent swarms are to deliver their productivity gains in production environments, authentication and authorization systems will need to evolve alongside them. Agents must be able to authenticate as distinct identities, operate with tightly scoped authority, and remain subject to continuous policy enforcement without constant human intervention. The goal is not to limit automation. It’s to make automation governable at scale.
