OpenClaw exposures expose the identity gap in agentic AI security

At a glance

What this is: SecurityScorecard’s STRIKE research shows exposed OpenClaw deployments create an agentic AI identity and access problem, not just a software vulnerability problem.

Why it matters: IAM, PAM, and security teams need to treat agentic tools as identities with scope, permissions, and blast radius, or exposed infrastructure will become attacker-owned access paths.

By the numbers:

• STRIKE found tens of thousands of exposed OpenClaw instances, many of which are vulnerable to Remote Code Execution, with 35.4% of observed deployments flagged as vulnerable at time of writing.

👉 Read SecurityScorecard’s analysis of exposed OpenClaw agentic AI deployments

Context

OpenClaw deployments are creating an identity and access gap because the service is not just a tool, it is an actor with permissions to move across connected systems. When those deployments are exposed, the risk is not abstract AI behaviour, but direct abuse of the access already granted to the agent.

That changes the governance problem for agentic AI. Security teams have to account for where the agent runs, what it can reach, and how much authority it inherits from the surrounding infrastructure. In other words, exposed agentic systems become part of the identity perimeter whether or not they were approved that way.

OpenClaw is a useful example because the issue is already visible at scale. The starting position is increasingly typical for fast-moving agentic AI adoption: teams deploy first, then discover that the access model was never designed for software that can act across systems.

Key questions

Q: What breaks when AI agents are given broad standing access?

A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check. That creates a control gap between intended scope and actual runtime behaviour. The result is weak accountability, limited containment, and audit trails that show activity without explaining why the activity was allowed.

Q: Why do exposed agentic AI deployments create more risk than ordinary web services?

A: They create more risk because the service is not just serving traffic, it is acting across systems on behalf of users or workflows. That means an attacker can pivot from one weakness into email, cloud, internal tools, and data access in a single compromise. The exposure surface is identity plus infrastructure, not code alone.

Q: How can security teams tell if an agentic deployment is overprivileged?

A: Look for broad permissions across cloud services, internal APIs, messaging tools, and file systems that are not required for the specific workflow. If the agent can make changes in multiple environments or touch sensitive data without task-specific limits, it is overprivileged. The signal is breadth of reach, not just the presence of credentials.

Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?

A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.

Technical breakdown

Why exposed agentic AI instances become identity choke points

An agentic AI deployment is more than an application endpoint. It often sits inside trusted networks, holds API credentials, and can interact with email, cloud services, internal data, and deployment systems. When that service is exposed, an attacker does not need to compromise each downstream system separately. The exposed agent becomes the highest-leverage entry point because it already carries delegated authority. In identity terms, this is a non-human identity with an overly wide trust envelope. The technical mistake is not only exposure, but assuming the runtime can be treated like a normal web workload when it actually behaves like a privileged operator.

Practical implication: inventory every agentic deployment as an identity-bearing system and map its inherited privileges before exposing it to any network segment.

How remote code execution turns into infrastructure misuse

Remote code execution on an exposed agentic system is especially dangerous because the attacker inherits whatever the agent can already do. If the agent can deploy services, modify files, call APIs, or access internal resources, the compromise rapidly shifts from code execution to operational control. That is why RCE in this context is not just an application flaw. It is a privilege amplification event. The attacker is not merely running a command. They are stepping into a runtime that may already have business authority, secrets, and connectivity. Once that trust boundary is crossed, normal activity can hide abuse because the actions look like the agent’s own work.

Practical implication: bind agent permissions to tightly scoped service accounts, isolate the runtime, and assume any exposed RCE path can become a delegated access takeover.

Why segmentation and least privilege matter more for agents than for ordinary apps

Agentic systems make traditional security controls more valuable, not less. Network segmentation limits lateral movement if the agent is abused. Least privilege reduces what the attacker inherits from the agent. MFA protects the human-linked identities around the platform, but it does not solve the core problem if the agent itself has excessive system authority. The key architectural point is that agentic AI expands the blast radius of a single exposed service because it can bridge multiple platforms in one workflow. That is why treating the agent as a disposable app instance misses the risk profile. It is an operational identity with reach.

Practical implication: enforce segmentation, remove standing access, and review every connected system an agent can touch as part of its attack surface.

Threat narrative

Attacker objective: The attacker wants to turn an exposed agentic AI runtime into a reusable access path for control, abuse, and persistence across the connected environment.

1. entry: The attacker finds an exposed OpenClaw deployment and uses the public surface as the initial foothold.
2. escalation: A remote code execution weakness lets the attacker run code in the agent runtime and inherit the permissions already assigned to that agent.
3. impact: The attacker uses the agent’s delegated access for infrastructure misuse, botnet activity, crypto mining, or access to internal systems and connected services.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

OpenClaw exposure is an NHI governance problem first and an AI problem second. The research shows that the immediate risk is not autonomy, but exposed services with authority to act across systems. That means agentic AI deployments should be governed as non-human identities with lifecycle, access scope, and blast-radius controls, not as ordinary applications. Practitioners should align these deployments to OWASP-NHI and Zero Trust assumptions rather than waiting for an AI-specific exception.

Standing trust assumptions break down when an agent can act across multiple systems. Least privilege is often defined as if the subject’s task and scope are known at provisioning time. Exposed OpenClaw deployments show that assumption is fragile when the service can touch email, APIs, cloud resources, and internal data in one runtime. The implication is not just tighter permissions, but a re-evaluation of how privilege is granted when software behaves like an operator.

Blast radius, not just exposure count, is the right unit of risk for agentic AI. Tens of thousands of exposed instances matter because each one can inherit connectivity, credentials, and operational authority. A single RCE weakness becomes materially worse when the runtime sits inside trusted infrastructure and has broad permissions. Security teams should judge agentic deployments by the systems they can affect, not only by whether the service is internet-facing.

Identity perimeter drift: exposed agentic tools are expanding the set of systems that effectively sit inside the trust boundary. The vendor’s research suggests adoption is outpacing hardening, which is exactly how identity perimeter drift happens. Once teams allow agents to modify files, deploy services, and call APIs, the question becomes who is accountable for the agent’s permissions and where that authority ends. Practitioners need to treat that drift as a governance defect, not a deployment detail.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• 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.
• OWASP Agentic Applications Top 10 is the next step for teams mapping tool misuse, identity abuse, and agent governance gaps.

What this signals

Identity perimeter drift: as agentic tools spread, the practical boundary of IAM moves from user and service account governance to every runtime that can act across systems. Teams should expect more deployments that inherit access faster than they are reviewed, which makes discovery and scope mapping a first-order control rather than a reporting exercise.

With 52% of companies able to track and audit the data their AI agents access, per AI Agents: The New Attack Surface report, the governance gap is already visible. The immediate programme risk is not just exposure, but the inability to prove what an agent touched after the fact.

Security leaders should start building review models for agentic systems that combine access scope, isolation, and offboarding discipline. If the deployment can modify infrastructure or call production APIs, it belongs in identity governance with the same seriousness as privileged human access.

For practitioners

• Inventory every agentic deployment as an identity-bearing service Record where each OpenClaw-like deployment runs, what credentials it holds, which APIs it can reach, and which downstream systems it can modify. Include third-party and experimental deployments that bypass formal review.
• Constrain the runtime with segmented network paths Place agentic systems in isolated environments so a single exposed service cannot pivot freely into internal systems. Use segmentation to reduce lateral movement and limit how far a compromised agent can propagate.
• Reduce inherited authority before exposure Strip standing access from the agent wherever possible, bind it to narrowly scoped service accounts, and remove any credentials not required for the immediate workflow. Review cloud, email, and internal tool access separately.
• Monitor for misuse patterns that look like legitimate agent activity Watch for infrastructure changes, unusual API calls, botnet-like compute behaviour, and repeated execution from a single agent runtime. Abuse is easier to miss when the commands resemble normal task completion.

Key takeaways

• Exposed agentic AI deployments create a non-human identity risk because the attacker inherits the agent’s existing authority, not just its code execution path.
• STRIKE’s finding that 35.4% of observed deployments were vulnerable shows the problem is already measurable, not theoretical.
• Segmentation, least privilege, and runtime isolation are the controls that shrink the blast radius when agentic access is exposed.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Identity Perimeter Drift: Identity perimeter drift is the gradual expansion of the systems, apps, and delegated permissions that fall inside the organisation's trust boundary. It matters because collaboration tools and SaaS integrations can turn a narrow access model into a broad entitlement surface without a formal design change.
• Blast Radius: Blast radius is the amount of damage a compromised identity or system can cause before it is contained. For agentic AI, the metric is not just technical reach, but the number of connected services, permissions, and operational actions the runtime can affect.
• LLM Remote Code Execution: A condition where a large language model integration causes arbitrary code to run on the host or backend system. The model is usually not the direct vulnerability. The failure appears when attacker-shaped model output is parsed, trusted, and handed to a dangerous execution path.

What's in the full report

SecurityScorecard's full research covers the operational detail this post intentionally leaves for the source:

• Updated exposure trend data from the declawed dashboard, including the 15-minute refresh model
• Vulnerability category breakdowns across exposed OpenClaw instances and how the STRIKE team classified them
• Practical reduction steps for segmentation, access scope, and runtime isolation in agentic environments
• Video discussion and source research material for teams that need implementation context beyond the summary

👉 SecurityScorecard’s full post covers exposure trends, RCE risk, and reduction steps in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.