Notifications
Clear all
Topic starter
05/07/2026 6:48 pm
TL;DR: OpenClaw highlights how employees are delegating real work to AI assistants that can browse, execute tasks, install skills, and touch internal systems, turning ordinary workflows into part of the attack surface, according to Lakera. The security problem is not model output alone but authority delegation that outpaces visibility, guardrails, and least-privilege controls.
NHIMG editorial — based on content published by Lakera: OpenClaw Shows What Happens When AI Agents Act on Human Authority
Questions worth separating out
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.
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.
Q: What breaks when workplace AI tools can install skills or connectors freely?
A: What breaks is the trust boundary around third-party functionality.
Practitioner guidance
- Inventory every assistant with real system access Identify which employee-used AI tools can reach inboxes, shared drives, SaaS apps, browsers, and developer environments.
- Treat skills, plugins, and connectors as privileged integrations Require review and approval for new assistant extensions before they can touch production systems.
- 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.
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
👉 Read Lakera's analysis of OpenClaw and AI agent authority risk →
AI agents acting on human authority: what changes for IAM teams?
Explore further
05/07/2026 7:07 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OpenClaw shows how AI agent authority expands enterprise risk
