OpenClaw-style agents expand the attack surface for enterprise IAM

At a glance

What this is: This is an independent security analysis of OpenClaw-style agentic systems and the risks they create when users, skills, tools, and secrets are connected without strong containment.

Why it matters: It matters because agentic systems behave like non-human identities with tool access, which means IAM, PAM, and secrets governance must extend to AI-driven execution paths, not just human accounts.

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.

👉 Read Semgrep's analysis of OpenClaw security, agent threats, and safe experimentation

Context

OpenClaw-style systems collapse the line between user input, instructions, and execution, which makes traditional trust and review models unreliable. In plain terms, the agent can read content, decide what to do, and then act through tools, so the security question becomes how to constrain that execution path before it reaches sensitive systems. That is the same governance problem identity teams face whenever a non-human identity can inherit human trust.

The article’s core warning is that agentic AI is not just another automation layer. Once an assistant can use email, browser access, shell commands, plugins, or skills, it needs the same lifecycle thinking applied to privileged service accounts, secrets, and delegated access. For teams already managing IAM or NHI programmes, the unusual part is not the technology stack. It is the speed at which trust, capability, and compromise can converge.

Key questions

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. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

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. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

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. Without manual review of the repository and skill content, users rely on marketplace reputation signals that can be manipulated. That turns installation into a trust shortcut and makes code execution a supply chain problem.

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.

Technical breakdown

Why prompt injection becomes execution in agentic systems

Agentic systems blur the distinction between content and command. A prompt, email, webpage, or document can be treated as input by the model and later converted into a tool call, which means an attacker does not need direct shell access to influence execution. The security failure is structural: once the agent can pass information into tools, every external source becomes a potential instruction channel. Classic input filtering is insufficient because the system cannot reliably separate harmless text from malicious control signals.

Practical implication: constrain tool permissions and validate every high-risk action at the execution boundary.

Why sandboxing must sit below the reasoning layer

The article’s key architectural point is that you cannot rely on the model to behave predictably. LLM output is probabilistic, so the same prompt may produce different actions, and adversarial content can steer those actions in unintended directions. That makes the reasoning layer a poor place to enforce safety. The safer design pattern is to treat the agent like an untrusted component and place controls around the execution environment, including network access, filesystem scope, and credential exposure.

Practical implication: enforce network, filesystem, and tool isolation before allowing any agent to touch production data.

How skills and dependencies expand the supply chain risk

OpenClaw skills behave like executable, opinionated task bundles, not passive configuration files. That makes them similar to unvetted open-source dependencies, especially when they can include scripts, external fetches, or update logic. The risk is twofold: malicious skills can be intentionally harmful, while vulnerable skills can be exploited after installation. In both cases, the governance problem is provenance and review, not just malware scanning. If the ecosystem is immature, trust must be earned per skill, not assumed by popularity or community adoption.

Practical implication: treat every skill as code, require review gates, and block auto-update behavior until provenance is verified.

Threat narrative

Attacker objective: The attacker aims to turn the agent’s legitimate tool access into a credential and data exfiltration path that bypasses normal user scrutiny.

1. Entry begins when a user installs or connects an OpenClaw-style agent to email, browser, or other enterprise tools with broad permissions.
2. Escalation occurs when prompt injection or a malicious skill convinces the agent to use its own trusted context to request, read, or exfiltrate secrets.
3. Impact follows when those stolen credentials are used to reach internal systems, move through connected services, or expose sensitive data at scale.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

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.

Separation of concerns fails when the same system both interprets and executes instructions. That is the deeper reason prompt injection is so dangerous in agentic environments. Traditional controls assume a clear boundary between data and code, but tool-using agents collapse that boundary. The named concept here is instruction-to-execution collapse, which is the control failure that makes untrusted text operationally dangerous. The practitioner conclusion is to move enforcement out of the model and into execution controls.

Skill ecosystems turn governance into supply chain management. When skills can bundle scripts, dependencies, and hidden instructions, the security question becomes provenance, review, and lifecycle control. This is where OWASP NHI and OWASP Agentic AI guidance intersect: a skill can function like a delegated identity artifact with embedded authority. The practitioner conclusion is to treat every skill as a managed asset with approval, revocation, and offboarding.

Blast radius is the right metric for agent security maturity. The article’s core lesson is not whether an agent is useful, but how far it can reach if compromised. Sandboxing, network scoping, and credential minimisation do more to reduce loss than model-level assurances ever will. That aligns with NIST AI RMF GOVERN and MANAGE thinking: accountability and containment matter more than optimism. The practitioner conclusion is to measure what an agent can access, not how confidently it speaks.

Popularity is not a trust signal in immature agent ecosystems. The article notes a large installed base and mixed skill quality, which is exactly the pattern that creates governance drift. Teams tend to accept tool sprawl before they understand the access paths it creates. That is why identity programmes should review agents, plugins, and skills with the same discipline used for third-party access. The practitioner conclusion is to build approval, logging, and offboarding into the rollout from day one.

From our research:

• 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.
• For a broader control lens, read OWASP NHI Top 10 for the most common agentic application risk patterns.

What this signals

Instruction-to-execution collapse is the operational signal identity teams need to watch for as agent adoption accelerates. The danger is not merely that agents make mistakes, but that they can convert untrusted content into trusted action unless execution controls are broken away from reasoning. For teams aligning to external guidance, the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework are useful references for containment and accountability.

Agent rollout should now be measured by what the system can reach, not by how much productivity it appears to deliver. If an agent can reach credentials, sensitive data, or high-value internal services, the programme already has an identity governance issue. The most useful next step is to map agent permissions to the same review logic used for privileged service accounts and delegated third-party access.

The practical shift for security leaders is toward agent boundary management: isolated execution, narrow tool scope, and explicit offboarding. That is a stronger control pattern than hoping policy text or user training will prevent abuse. Where identity, NHI, and AI governance intersect, the programme needs one view of access, one review cycle, and one revocation path.

For practitioners

• 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. Use separate credentials for experimentation so a compromised agent cannot inherit broader access from a human operator.
• 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. Reject auto-update mechanisms and unverified external download steps such as curl piped into shell.
• 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. Keep customer, finance, and identity administration systems out of the default experimentation path.
• Audit for secret exposure before enabling tool access Inventory where API keys, tokens, certificates, and session material are stored, then remove them from any environment an agent can read. If the agent can access secrets, assume prompt injection or malicious skill content can eventually extract them.

Key takeaways

• Agentic systems create identity risk because they can act, not just analyse, which makes access scope a first-class security control.
• The main evidence is a structural one: once instructions, tools, and secrets sit in the same execution flow, prompt injection and skill abuse become practical compromise paths.
• Teams should respond by constraining agent reach, reviewing every skill as executable code, and removing standing access to sensitive systems and secrets.

Key terms

• Agentic Soc: An agentic SOC is a security operations model where AI systems assist with triage, investigation, and response using tool access and execution authority. The control challenge is not just accuracy, but governance of what the machine can see, decide, and do.
• Instruction-to-Execution Collapse: The loss of a clear boundary between untrusted input and trusted action in an agentic workflow. When text, context, and tool use merge into one path, malicious content can influence real operations without a conventional code injection step.
• Skill Supply Chain: The ecosystem of external task bundles, plugins, scripts, and dependencies that extend an agent’s capability. Because these artifacts can carry hidden instructions or vulnerable code, they must be reviewed as executable supply chain inputs rather than harmless configuration.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

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

👉 Semgrep's full article covers detection steps, sandbox settings, and skill vetting guidance for OpenClaw

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical operational terms. It is designed for practitioners who need to connect identity controls to real-world access risk across modern systems.