OpenClaw shows how AI agent authority expands enterprise risk

At a glance

What this is: This is Lakera’s analysis of OpenClaw as a signal that AI assistants are moving from advisory tools to actors operating inside real workplace workflows.

Why it matters: It matters because IAM teams now have to govern delegated AI action paths, not just authenticate users or classify model output.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.

Context

OpenClaw sits in the space where employee productivity tooling becomes an identity and access problem. Once an AI assistant can browse, execute tasks, install skills, or operate inside email, files, browsers, and internal applications, the question is no longer only what the model outputs but what authority it can exercise.

The governance gap is that many organisations still treat these systems as software helpers rather than delegated actors. That assumption breaks when open-ended automation is connected to real systems, because the action itself becomes the security event.

This makes the article relevant to both NHI governance and agentic AI identity, but the primary issue is delegated authority inside ordinary business workflows rather than model safety in isolation.

Key questions

Q: What breaks when AI assistants are allowed to act on behalf of users without policy checks?

A: The assistant can make legitimate-looking requests that exceed the user's intended scope, especially when it can retrieve data, call APIs, or generate responses across sensitive systems. Without action-level policy checks, authentication becomes a weak proxy for authorisation. Teams lose the ability to prove that each AI-driven action stayed inside the approved boundary.

Q: Why do AI assistants expand enterprise risk even when the model output looks harmless?

A: Because the security impact comes from execution, not language quality. A polite assistant can still browse, install skills, access inboxes, and operate across internal systems, so the harmful event is the action chain the assistant can trigger. That is why access scope, connector trust, and runtime guardrails matter more than content moderation alone.

Q: What are the signs that AI governance is failing in the enterprise?

A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

Q: Should organisations treat AI assistants and autonomous agents the same way?

A: No. AI assistants that act inside a human session can often be governed through delegated access and user accountability, while autonomous agents need their own identity, lifecycle records, and monitoring. Mixing the two creates false comfort and leaves the wrong party accountable for access decisions.

Technical breakdown

Authority delegation turns AI assistants into access-bearing actors

An AI assistant becomes security-relevant the moment it can act on behalf of a person across systems, not just generate text. In this model, the risk is not only the prompt or output, but the permissions inherited from the human context, the connectors attached to the assistant, and the actions it can trigger inside email, SaaS, developer tools, or shared drives. That makes the assistant behave like an identity boundary problem. The security issue is whether the system can distinguish user intent from agent execution and stop sensitive operations from becoming ordinary workflow noise.

Practical implication: Treat any assistant that can execute actions or access enterprise data as an identity-bearing workload, not as a harmless UI layer.

Skills, plugins, and connectors expand the agent attack surface

The article points to one-click execution paths and malicious third-party skills, which is the classic problem of untrusted extensions becoming privileged execution paths. A skill or connector is not just extra functionality. It is a code path that can inherit the assistant’s access and reach the same systems the user already touches. In practice, this creates a supply chain problem inside the workflow: if the extension layer is weakly governed, the assistant becomes a delivery mechanism for abuse, data movement, or unauthorised action.

Practical implication: Review third-party skills and connectors with the same scrutiny you apply to privileged integrations and browser extensions.

Indirect manipulation matters because untrusted inputs can steer actions

Workplace assistants do not only consume commands from users. They also ingest documents, links, tickets, spreadsheets, and other content that can steer behaviour without appearing malicious in the normal sense. That is why the article’s emphasis on indirect prompt injection and data poisoning is important: the input layer becomes an action-control layer when the assistant is allowed to reason and act across tools. The result is a security model where content that looks like business data can become operational instruction.

Practical implication: Classify external content consumed by agents as untrusted input and control which documents, links, and datasets they are allowed to process.

Threat narrative

Attacker objective: The objective is to abuse delegated AI authority so that normal business workflows can be turned into channels for unauthorised access, data movement, or harmful actions.

1. Entry occurs when employees adopt open or community-built AI assistants and connect them to inboxes, shared drives, browsers, or developer environments without full governance.
2. Credential and permission exposure follows when the assistant inherits the user’s access, installed skills, and connector permissions, giving the attacker or malicious content a privileged execution path.
3. Escalation happens when third-party skills, one-click execution, or indirect manipulation cause the assistant to perform actions that look like routine work but actually move data or trigger sensitive operations.
4. Impact is the broadening of the attack surface across ordinary workflows, where the agent can touch systems and data at the speed of delegated authority.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• ClawHub malicious skills 2026: Hundreds of malicious ClawHub skills for the OpenClaw agent pushed credential stealers in early 2026; Koi found 341 of 2,857 in the ClawHavoc campaign.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Delegated AI authority is now an identity problem, not just an application problem. The article shows that the decisive risk is not what the assistant says but what it is allowed to do under a human's authority. Once an assistant can browse, execute tasks, or touch internal systems, the organisation has created a delegated access path that must be governed as identity behaviour. Practitioners should treat this as an access model redesign, not a content-safety tweak.

Open-ended agent tooling creates a new form of identity blast radius. When a worker connects AI assistants to email, files, browsers, and dev tools, the assistant can inherit a wide action surface that traditional least-privilege reviews do not describe well. The issue is not merely over-permissioning in the abstract. It is that one person’s workflow can now fan out into multiple systems through an agent that acts fast enough to collapse the review window. Practitioners need to understand how much of the enterprise now sits inside delegated execution paths.

Skills and connectors are governance objects, not convenience features. In agentic environments, third-party extensions are the practical route from everyday productivity to enterprise compromise. That means the approval model for adding a skill or connector belongs in IAM and PAM governance, not in a casual app-adoption workflow. The organisation is no longer evaluating a tool add-on. It is authorising a new path into business systems.

AI agent authority expands faster than existing visibility models. Access review, audit, and recertification processes assume stable permissions that can be observed over time. That assumption weakens when an assistant can be connected, extended, and used informally before security teams even know it exists. The implication is that discovery and control must move closer to runtime usage, or the organisation will keep reviewing yesterday's permissions while today's delegated actions go unseen.

From our research library:

• 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
• Read next: AI Agent Authorisation Guide

What this signals

Identity blast radius is the right lens for workplace agents. Once an AI assistant can inherit human authority across email, documents, browsers, and business apps, the question becomes how far one delegated action can travel before it is contained. That is an access governance problem first, not an AI output problem.

OpenClaw-style adoption will outpace formal AI programmes unless security teams move at the workflow layer. The organisations most exposed are the ones that wait for a formal platform rollout before governing agent access. Runtime visibility, connector control, and action logging need to arrive earlier than policy exceptions do.

For practitioners

• Map delegated AI actions to identity ownership Inventory which assistants can browse, execute tasks, install skills, or operate across enterprise systems, and assign an accountable owner for each action path.
• Constrain connectors and skills to least privilege Review every connector, plugin, and skill as a high-risk integration, then remove any permissions not required for the assistant's actual work.
• Classify untrusted content for agent consumption Treat documents, links, spreadsheets, and tickets as inputs that can steer behaviour, and block assistants from processing high-risk external content by default.
• Require audit trails for agent actions Make sure logs capture what the assistant did, which data it touched, which connector it used, and which human authority it acted under.

Key takeaways

• AI assistants become a security concern when they can act under human authority across enterprise systems, not when they merely produce content.
• The article shows that connectors, skills, and indirect inputs can turn everyday workflows into an attack surface with broad blast radius.
• The control gap is governance at the action layer, where identity, access scope, and audit trails have to follow what the assistant can do.

Key terms

• Delegated AI Authority: Delegated AI authority is the permission a person gives an assistant to act inside business systems on their behalf. It turns a conversational tool into an execution layer, which means security teams must govern scope, auditability, and revocation with the same seriousness they apply to privileged access.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Indirect manipulation: Indirect manipulation is the use of ordinary-looking content such as documents, links, spreadsheets, or tickets to steer an AI system's behaviour. The content may appear harmless to a person while still influencing agent decisions, making input trust a governance problem.
• Agent action path: An agent action path is the sequence of systems, permissions, and triggers an AI assistant can use to complete work. It matters because governance must cover the path from instruction to execution, not only the prompt or the final output.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.