Notifications
Clear all
Topic starter
02/08/2026 9:44 am
TL;DR: OpenClaw’s security guidance argues that LLM agents should be treated as personal assistants with dangerous defaults, because prompt injection, skill abuse, and exposed credentials can turn tool access into an enterprise attack surface, according to Semgrep. The practical problem is not the model alone but the surrounding identity, sandboxing, and secret-handling assumptions that fail once agentic systems can act inside business workflows.
NHIMG editorial — based on content published by Semgrep: The Pragmatist's Guide to Lobster Handling
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and 47% have only partial visibility.
Questions worth separating out
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: Why do AI agents create more risk than traditional automation?
A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously.
Q: What breaks when AI agent skills are not reviewed before installation?
A: The main failure is that malicious instructions can hide inside a skill that appears legitimate, then execute under the agent’s delegated access.
Practitioner guidance
- Limit agent reach to session-scoped permissions Assign only the minimum tool, network, and file access needed for the task, then remove persistent privilege once the session ends.
- Treat skills as executable third-party code Create a review gate for every new skill or plugin, including provenance checks, script inspection, and dependency review.
- Isolate agents from crown-jewel systems Run agents in a dedicated VM or container with blocked production network paths, restricted filesystem scope, and explicit allowlists for approved destinations.
What's in the full article
Semgrep's full article covers the operational detail this post intentionally leaves for the source:
- Hands-on detection checklist for finding OpenClaw-style installs, processes, and config directories across a Unix-flavoured fleet
- Specific hardening settings for openclaw.json, including sandbox scope, pairing, logging redaction, and discovery controls
- Skill vetting workflow with red-flag indicators such as curl | bash, auto-update behaviour, and hidden script content
- Incident response guidance for documenting indicators, checking lateral movement, and assuming exposed secrets are compromised
👉 Read Semgrep's analysis of OpenClaw security, agent threats, and safe experimentation →
OpenClaw-style agents and the identity gap teams are missing?
Explore further
02/08/2026 12:37 pm
Agentic systems create a non-human identity governance problem, not just an AI safety problem. Once an assistant can authenticate to email, storage, or shell tools, it behaves like a privileged workload with human-like reach and machine speed. That makes IAM scope, secrets handling, and access review part of the same control plane. The practitioner conclusion is simple: if the agent can act, it must be governed like an identity.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an AI agent exposes credentials or changes identity state?
A: Accountability should sit with the business owner of the agent, the identity team that granted scope, and the control owner responsible for the affected workflow. If the agent touched privileged systems, incident handling should follow the same seriousness as any privileged access failure, because the issue is not just misuse but governance collapse across the identity layer.
👉 Read our full editorial: OpenClaw-style agents expand the attack surface for enterprise IAM
