OpenClaw shows how AI agent authority expands enterprise risk

At a glance

What this is: OpenClaw is a Lakera analysis of how employee-used AI assistants can act on human authority and expand enterprise attack surface.

Why it matters: It matters because identity teams now have to govern delegated AI actions across NHI, autonomous, and human workflows, not just traditional logins and SaaS permissions.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Lakera's analysis of OpenClaw and AI agent authority risk

Context

OpenClaw is a workforce AI security story, but the underlying issue is identity and authority. Once an assistant can browse, run tasks, install skills, and operate across apps, it stops being a convenience layer and becomes an actor that can exercise delegated access inside normal business workflows.

The governance gap is that many programmes still treat AI usage as content safety or software rollout, rather than as an access problem. If an assistant can act inside email, files, browsers, and developer tools, then identity, permissions, connector trust, and auditability all become part of the control boundary.

This is not a fringe scenario. The article describes the current pattern as employees bringing open-ended automation into production work before security teams have built the visibility and control model to match it.

Key questions

Q: How should security teams govern AI assistants that act on behalf of employees?

A: Security teams should treat employee-facing AI assistants as delegated execution paths, not just chat interfaces. That means mapping which systems they can reach, limiting their permissions, requiring approval for sensitive actions, and logging the actions they perform. The identity question is who has authority, how far that authority extends, and whether the assistant can exceed the user's intended scope.

Q: Why do AI assistants increase blast radius in normal business workflows?

A: AI assistants increase blast radius because they can inherit a person's access across email, files, browsers, and business applications, then act faster and more broadly than a human usually would. Once connectors and skills are added, the assistant becomes a new execution layer inside existing identity trust. That widens the impact of one compromised session or one overly broad permission grant.

Q: What breaks when workplace AI tools can install skills or connectors freely?

A: What breaks is the trust boundary around third-party functionality. Unreviewed skills and connectors can create new pathways into sensitive systems, move data between environments, and introduce hidden action surfaces that were never approved in the original access model. In practice, this means the organisation loses control over where the assistant can go and what it can do.

Q: Who is accountable when an AI assistant takes an unsafe action under a user's authority?

A: Accountability sits with the organisation that granted the assistant its access model, the team that approved the connectors, and the business owner of the workflow. Human authority does not erase governance responsibility. Practically, teams need clear ownership for delegated AI access, review of high-risk actions, and audit trails that show exactly which identity performed each step.

Technical breakdown

Delegated AI authority turns user access into machine-executed action

The core technical change is that an assistant can execute actions on behalf of a person, not just produce recommendations. That creates a delegated execution path across SaaS applications, browsers, developer environments, and file systems. In practice, the risk is not only what the model returns, but what it is allowed to trigger once a user has granted it access. Identity and authorization controls therefore need to account for both the human principal and the software actor acting under that principal's session.

Practical implication: map which AI tools inherit user authority and treat those sessions as privileged execution paths.

Extensions, connectors, and skills are part of the trust boundary

Workplace agents are only as safe as the integrations they can reach. Skills, plugins, connectors, and one-click execution paths create code pathways into enterprise systems, which means third-party functionality can become an indirect access channel. This is a familiar identity pattern in a new wrapper: excess scope, weak review, and opaque provenance. The control failure is usually not the model itself, but the expansion of what the assistant can touch without a matching governance process.

Practical implication: review assistant extensions, connectors, and installs with the same rigor used for privileged SaaS integrations.

Indirect prompt steering turns ordinary content into an execution input

OpenClaw illustrates the modern version of prompt injection and content steering. Documents, links, spreadsheets, tickets, and web pages are no longer passive inputs when an assistant can interpret them and then act. Untrusted content can quietly influence the sequence of operations an assistant performs, which makes data handling and instruction handling inseparable. That is why AI security for workplace tools has to cover both input trust and action control, not one or the other.

Practical implication: classify external documents and web content as untrusted inputs that can change agent behaviour, not just inform it.

Threat narrative

Attacker objective: The attacker aims to convert delegated AI authority into unauthorized action, data exposure, or workflow abuse that blends into normal business activity.

1. Entry occurs when employees adopt open-ended AI assistants and connect them to inboxes, shared drives, browsers, and internal systems under their own authority.
2. Escalation occurs when skills, plugins, or indirect inputs steer the assistant into installing connectors, moving data, or running commands that exceed normal user intent.
3. Impact occurs when the assistant performs actions that are operationally indistinguishable from the employee's own work, expanding blast radius across applications and datasets.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Delegated AI authority is now an identity problem, not a productivity feature. The article shows employees using assistants that can browse, run tasks, and operate across apps under human authority. That means the control question is no longer whether AI can answer correctly, but whether the delegated principal can act safely inside real systems. The practitioner conclusion is that identity governance must extend to software acting inside a human session.

Human-paced access review is a weak fit for machine-executed work. Review cycles are built for entitlements that are visible, stable, and slow enough to certify. When an assistant can install a skill, access data, and complete an action path in one flow, the review window often opens after the risk has already been exercised. The implication is that access governance must account for runtime delegation, not just entitlements on paper.

Identity blast radius is the right concept for workplace AI. The article repeatedly points to broad permissions, broad access, and actions that look like ordinary work. That is exactly what makes delegated AI dangerous: a single consented assistant can inherit the reach of the employee across email, files, browsers, and development tools. Practitioners should treat every new connector as a blast-radius expansion event.

Workforce AI security and NHI governance are converging. Although the article is framed around employee use, the operational problem is identical to machine identity governance: who can act, through which connector, over which data, and with what audit trail. Once assistants execute actions, the boundary between human identity, NHI, and autonomous behaviour becomes a governance chain rather than a single control point. The practitioner conclusion is to govern the chain end to end.

Open-ended assistant ecosystems create trust debt faster than security teams can retire it. The article's emphasis on skills, plugins, and third-party extensions shows how quickly new access paths appear around a core assistant. This is not a product feature issue alone; it is a lifecycle issue involving approval, scoping, monitoring, and removal. The implication is that teams must manage assistant onboarding and offboarding as continuously as they manage privileged access.

From our research:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• For a broader view of lifecycle control, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that help reduce delegated-access drift.

What this signals

Identity teams should expect AI assistant governance to land in the same operating model as privileged access management. The practical issue is not whether employees will use assistants, but whether those assistants can be discovered, scoped, and removed with the same discipline used for high-risk access. That requires joining identity inventory, SaaS audit trails, and connector governance into one control plane.

Open-ended assistant adoption will expose a new class of unmanaged access unless organisations formalise onboarding and offboarding for workplace AI. The NHI Lifecycle Management Guide is the right analogue here because the problem is lifecycle, not novelty. If assistants can be added to workflows without a matching removal path, trust debt accumulates across the identity stack.

Employees will keep extending AI into production work, so the control strategy has to shift from policy statements to measurable boundaries. The key signals are connector count, privileged action volume, and how quickly a risky assistant can be disabled once discovered. The article's logic points to a simple reality: if you cannot inventory it, you cannot govern it.

For practitioners

• Inventory every assistant with real system access Identify which employee-used AI tools can reach inboxes, shared drives, SaaS apps, browsers, and developer environments. Record the identity that is actually exercising access, the connectors granted, and the data classes exposed.
• Treat skills, plugins, and connectors as privileged integrations Require review and approval for new assistant extensions before they can touch production systems. Limit who can add connectors, and place install controls on managed endpoints and SaaS admin paths.
• Restrict assistant access with least privilege and scoped OAuth Constrain delegated access to the minimum SaaS permissions needed for the task and remove broad token grants where they are not essential. Revalidate scopes whenever an assistant is connected to a new workflow.
• Log what the agent did, not only what it said Use SaaS audit trails, repository activity, and sensitive file access logs to reconstruct assistant actions. Build detection around unexpected movement of data, installation of new skills, and action sequences that do not match normal employee behaviour.

Key takeaways

• AI assistants that act on behalf of employees expand enterprise risk because they inherit real authority across email, files, browsers, and SaaS systems.
• The most dangerous failure mode is not model output, but delegated action through skills, connectors, and untrusted content that can steer execution.
• Security teams need lifecycle controls for workplace AI, including discovery, scoped access, action logging, and removal when the assistant is no longer trusted.

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.
• Assistant Connector: An assistant connector is an integration that lets an AI tool reach external applications, data stores, or workflows. It is not just a convenience feature. Once enabled, it becomes part of the trust boundary and can create a new path to sensitive systems if not reviewed and scoped carefully.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause when it is misused, over-scoped, or compromised. For AI assistants, it includes the combined reach of the user's permissions, the assistant's connectors, and any automation the system can trigger without additional approval.
• Indirect Prompt Steering: Indirect prompt steering is the use of external content such as documents, links, spreadsheets, or tickets to influence how an AI system behaves. In practice, the content does not need to contain obvious malware. It only needs to shape the assistant's decisions or actions in an unsafe way.

What's in the full article

Lakera's full analysis covers the operational detail this post intentionally leaves for the source:

• Examples of high-risk actions to classify and control when an assistant can operate across email, documents, browsers, and developer tools
• Practical guidance on reviewing installs, connectors, and permissions for workplace AI on managed endpoints
• Detailed discussion of indirect prompt manipulation through documents, links, spreadsheets, and datasets
• Lakera's recommended readiness posture for teams that need to govern employee-delegated AI in real workflows

👉 Lakera's full post covers the blast radius, guardrails, and workflow controls in more detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.