OpenClaw and the new agent attack surface for enterprise identity

At a glance

What this is: Zenity frames OpenClaw as evidence that agent assistants create a security gap between inherited human permissions and autonomous execution.

Why it matters: IAM, NHI, and PAM teams need to classify agents as identities, constrain delegated access, and add runtime visibility before adoption outruns governance.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 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.

👉 Read Zenity's checklist for securing OpenClaw and the agent attack surface

Context

OpenClaw sits in the category of AI agent assistants that can take actions using human permissions, consume untrusted content, and operate with runtime decisions that outpace conventional security visibility. For enterprise identity teams, that creates a basic governance problem: the access model assumes a user or service account is being governed, while the agent behaves like an execution identity with delegated authority.

The practical issue is not whether the agent is useful, but whether security controls can see, classify, and constrain it as an identity. Without central registration, scoped tools, and runtime monitoring, the organisation inherits an access path that can trigger actions without the review cycles, visibility, or ownership usually expected in IAM and NHI programmes. That is already a common starting position in early agent adoption, not an edge case.

Key questions

Q: What breaks when AI agents are treated like normal applications instead of identities?

A: When AI agents are treated like ordinary applications, their delegated permissions, runtime decisions, and tool use are not governed as identity behaviour. That creates blind spots in ownership, logging, review, and containment. The result is an execution path that can move from untrusted input to enterprise action without the controls normally applied to human or machine identities.

Q: Why do AI agents complicate least-privilege access models?

A: AI agents complicate least privilege because they can select tools and actions at runtime, while traditional privilege design assumes the access pattern is known in advance. If scopes are broad, one prompt or document can trigger excessive reach across systems. The right response is to scope access around task boundaries, not around the convenience of the workflow.

Q: How do organisations know if an AI agent is operating outside its intended boundary?

A: They know by correlating the input that triggered the action, the tool called, the parameter set used, and the systems touched. If those details are not captured together, the organisation cannot distinguish a normal action from scope drift. Runtime auditability is the clearest signal that agent governance is actually working.

Q: Who is accountable when an AI agent causes exposure through inherited permissions?

A: Accountability stays with the organisation that granted the delegated access and failed to govern the agent as an identity subject. Security, IAM, and business ownership must be defined together because an agent can act across systems while still using human permissions. Governance gaps do not move liability away from the enterprise.

Technical breakdown

Why AI agents become an identity problem, not just an application problem

AI agents blur three layers that traditional security often keeps separate: identity, intent, and execution. When an agent uses inherited human permissions, it can turn a normal login into an execution channel that moves across tools, data, and systems. That means the security boundary is no longer the app login alone. It is the agent runtime, the connected tools, and the content that can trigger action. Once untrusted input can influence tool use, the attack surface becomes identity-driven rather than purely software-driven.

Practical implication: classify the agent as an identity subject and map every delegated permission, connector, and trigger path before rollout.

Tool access, connectors, and token scope define the blast radius

An agent is only as safe as the tools it can reach. Connectors and API tokens turn a conversational interface into a multi-system executor, and broad scopes make one compromised prompt or malicious document a chain reaction across the environment. Least privilege still applies, but it must be applied to tools, not just to people. In practice, the dangerous part is not that the agent can call a tool. It is that a tool call can inherit enough authority to cross environment boundaries, modify state, or expose secrets.

Practical implication: enumerate every connector, default scopes to read-only where possible, and rotate tokens on a fixed cadence.

Runtime visibility is the control that separates approval from blind execution

Static policy checks are weak when the decision happens at runtime. Agent behaviour must be inspected where action is actually chosen, because the risk emerges in the sequence of inputs, tool selection, and parameters, not just in the presence of a permitted integration. This is why runtime visibility matters more than checkbox governance. If the security team cannot see which input triggered which action, the organisation cannot prove intent, explain impact, or stop dangerous sequences before they complete.

Practical implication: log input-to-action mappings, block destructive operations by default, and require approval for high-impact tool use.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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-style agent assistants expose an identity classification failure, not a new kind of app bug. The core issue is that the enterprise still treats the agent as a productivity layer while it behaves as a delegated execution identity. That mismatch breaks ownership, monitoring, and review models because the control plane is still built for human sessions and service accounts. The implication is that identity governance must start with classification, not after an incident forces the question.

Identity does not select or combine tools dynamically mid-session was designed for pre-authorised workflows. That assumption fails when the actor is autonomous because the agent can interpret untrusted content, choose tools, and time execution without a human approval gate. The implication is that access review cadences do not fully describe the risk anymore, because the behaviour exists in-session and may vanish before governance processes observe it.

Tool access without runtime containment creates identity blast radius. The checklist’s strongest signal is that a single agent can move from input to action across multiple systems if connectors and tokens are over-scoped. That is not just over-privilege in the classic sense. It is delegated authority with chained execution, which broadens the impact surface far beyond the originating login. Practitioners should treat the blast radius as a design variable, not a post-incident metric.

Indirect prompt injection is now an identity abuse vector, not only a content security problem. When fetched content can drive execution, the attack path jumps over normal perimeter controls and turns untrusted input into privileged action. That means the governance problem sits at the intersection of NHI, data ingress, and runtime decisioning. Teams that miss that junction will keep detecting symptoms after the agent has already acted.

OpenClaw validates a broader market shift toward agent governance as a discipline distinct from traditional IAM. The category is moving from static access assignment to live control of how an identity interprets, selects, and executes work. That shift accelerates the need for frameworks that treat agents as governed executors, not just API consumers. Practitioners should expect their existing IAM and NHI operating models to be tested at the boundary between intent and action.

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.
• That governance gap is why teams should start with OWASP NHI Top 10 for agentic-risk framing and then extend controls into runtime containment.

What this signals

With 80% of organisations already reporting agent scope violations, the issue is not theoretical adoption risk but operational governance debt. The programme question is whether identity teams can see the agent, bound the agent, and explain the agent before the first incident creates those requirements for them.

Identity blast radius: the practical measure of how far an agent can move once it inherits human authority. That blast radius expands quickly when connectors, tokens, and content triggers are not governed together, so teams should align NHI lifecycle controls with agent runtime monitoring.

Enterprises should also align this work with the NIST Zero Trust Architecture model and the OWASP Agentic AI Top 10, because both push the programme toward continuous verification rather than assumed trust.

For practitioners

• Classify every agent as an identity subject Assign an owner, register the agent centrally, and map its human inheritance, connected systems, and permitted actions before broad deployment.
• Reduce connector and token scope to the smallest workable set Inventory every tool, connector, and access token, then default non-essential access to read-only and remove broad delegated authority that widens the blast radius.
• Build runtime controls around input-to-action links Log which message, document, or URL triggered each action, then block destructive actions by default and force approval for high-impact operations.
• Treat indirect prompt injection as an execution trigger Flag untrusted content sources as potential security events and isolate channels that can influence agent behaviour before they reach tool execution.

Key takeaways

• AI agents become an identity governance problem the moment they inherit human permissions and can act on untrusted input.
• The control failure is visible in scope drift, over-broad connectors, and weak runtime auditability, not just in the presence of a bad prompt.
• Security teams should classify agents, constrain delegated access, and instrument action-level visibility before adoption outruns control design.

Key terms

• Agent Identity: An agent identity is the governance view of an AI agent as a distinct execution subject, not just a tool. It includes ownership, permissions, connectors, and logging. For autonomous behaviour, the identity must be controlled at runtime as well as at provisioning time.
• Indirect Prompt Injection: Indirect prompt injection is malicious content that reaches an agent through documents, web pages, email, or other inputs and alters its behaviour. In agentic systems, the risk is not limited to bad text. It becomes execution influence when the content can trigger tools or actions.
• Delegated Authority: Delegated authority is access granted to one identity so it can act on behalf of another. In AI agent programmes, that means the agent inherits human or service-account permissions and can exercise them across tools. The governance challenge is proving that the delegated scope still matches the real task.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if it is misused or compromised. For AI agents, the blast radius can expand rapidly when connectors, tokens, and runtime permissions are broad, because one action can cascade across multiple systems before review occurs.

Deepen your knowledge

AI agent identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are classifying agents, scoping connectors, or building runtime oversight, the course maps directly to that work.

This post draws on content published by Zenity: OpenClaw Security Checklist for CISOs: Securing the New Agent Attack Surface. Read the original.