Topic starter
02/06/2026 6:53 pm
TL;DR: Filesystem escapes, privilege escalation and allowlist bypasses can turn an AI agent into an execution layer, according to Cyera’s analysis of four OpenClaw CVEs, with 65K+ exposed instances on Shodan and 180K+ on Zoomeye as of May 2026. The security problem is not agent capability alone, but whether identity, isolation and runtime controls can survive agent automation.
Editorial analysis by NHI Mgmt Group, based on content published by Cyera: “Four New OpenClaw Vulnerabilities: When AI Agents Become the Attacker's Execution Layer”.
By the numbers:
- Shodan shows over 65K publicly accessible OpenClaw instances as of May 2026.
- Zoomeye shows over 180K publicly accessible OpenClaw instances as of May 2026.
Key questions
Q: What breaks when AI agents are not governed at runtime?
A: Without runtime governance, an agent can shift behaviour after provisioning and still execute actions that were never reviewed in context.
A: Because the agent can execute attacker-influenced actions inside a privileged workflow, which collapses the distance between input, decision and impact.
Q: How do teams tell whether their agent controls are actually working?
A: They should test the controls against runtime behaviour, not policy intent.
Practitioner guidance
- Audit agent runtime authority Map every filesystem, shell and SaaS permission the agent can reach, then classify which of those entitlements are truly required for the workflow.
- Remove client-controlled privilege signals Replace any ownership or role decisions derived from headers, environment variables or other mutable client input with server-issued authorisation state.
- Test sandbox boundary assumptions Challenge whether the sandbox actually prevents path swaps, symbolic links and other TOCTOU conditions from redirecting reads or writes outside the intended root.
Bottom line: OpenClaw shows how an AI agent can become the attack layer when runtime isolation, authorisation and command validation do not line up with agent behaviour.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/06/2026 7:05 pm
OpenClaw exposes an identity problem before it exposes a code problem. The platform turned an AI agent into a high-privilege operational actor, which means conventional application assumptions no longer hold. When an agent can read, write, execute and schedule work across systems, the security question becomes who or what is acting, under what authority, and with what runtime scope. Practitioners should stop treating agent access as a feature flag and start treating it as governed identity.
A few things that frame the scale:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What should security teams do when AI agents need access to tools and data?
A: Security teams should treat AI agents as runtime access actors and separate them from static machine identities. Limit tool scope, define approval gates, and require explicit revocation triggers for sessions and delegated access. The goal is to prevent broad runtime behaviour from inheriting static privileges.
👉 Read our full editorial: OpenClaw vulnerabilities show how agents become the attack layer