OpenClaw exposes the identity gap in agent governance

At a glance

What this is: This is SailPoint’s analysis of the OpenClaw incident, which it uses to show that AI agent exposure becomes an identity governance failure once agents are allowed to act with broad permissions and weak ownership.

Why it matters: IAM, IGA, PAM, and NHI teams need to treat agents as governed identities because compromise paths now run through credentials, lifecycle gaps, and ownership gaps rather than only through code flaws.

Context

OpenClaw is an AI agent that was designed to operate on a user’s laptop, read email, post to social media, and run shell commands through chat interfaces. In SailPoint’s account, the risk was not just that the software could be manipulated, but that the agent had been granted identity-like access without the governance expected for privileged non-human actors.

The security gap here is familiar to identity teams: when an actor can hold API keys, OAuth tokens, and broad access on behalf of a person, the control plane becomes the identity plane. That makes ownership, lifecycle, and certification the first line of defence for agentic AI.

SailPoint frames OpenClaw as a preview of a wider shift in which agents move from chat interfaces to operational execution in critical workflows. That matters because the failure mode is already visible: unmanaged agent identities can become entry points for user impersonation, persistence, and supply-chain-assisted compromise.

Key questions

Q: What breaks when an AI agent is deployed without formal ownership?

A: When an AI agent has no formal owner, review, offboarding, and incident response all become slower and less reliable. No one is accountable for permission drift, stale credentials, or unexpected behaviour, so the identity can persist long after the original use case has ended. That is a lifecycle failure, not just an administrative oversight.

Q: Why do stolen API keys and OAuth tokens make agent incidents so hard to contain

A: Because those credentials let an attacker act through legitimate trust paths. Once stolen, the attacker can impersonate the agent or user across services, often with enough scope to persist after the initial intrusion. Containment depends on knowing every place the token is trusted and being able to revoke it quickly.

Q: What do security teams get wrong about agent extensions and plugins

A: They often treat extensions as feature add-ons instead of authority amplifiers. A compromised plugin can inherit the agent’s permissions, expand the attack surface, and provide a second path into the same identity context. Teams need to govern inherited access, not just the base agent application.

Q: Should IAM teams prioritise lifecycle controls or access reviews for AI agents?

A: Lifecycle controls should come first because access reviews cannot fix identities that were never modelled correctly. If an agent can be created, changed, or retired without sponsorship and offboarding workflows, reviews only document the gap rather than closing it.

Technical breakdown

Why prompt injection becomes identity abuse in agent environments

Prompt injection matters here because the agent is not just generating text. It is authorized to act, so a malicious instruction can steer it toward credential access, token use, or tool execution that the operator never intended. In identity terms, the prompt becomes an input to authority, not just an input to language output. When the agent already has broad delegated access, the attacker does not need to break the system itself. They only need to redirect the identity that the system is empowered to use. That is why agent compromise often looks like legitimate behaviour until the access trail is inspected closely.

Practical implication: treat prompt injection as an identity control problem and constrain what any agent can do once it has access to credentials or tools.

How stolen API keys and OAuth tokens expand the blast radius

API keys and OAuth tokens are the portable proof that an agent has been trusted. Once stolen, they let an attacker operate as the agent or as the user behind it, often across multiple services and sessions. OAuth is especially sensitive because it can encode delegated access that looks legitimate to downstream systems, even when the original actor has been compromised. In OpenClaw’s case, the article ties token theft to impersonation and persistent access, which is the classic sign that authorisation has outlived trust. The technical lesson is that token scope, revocation, and ownership need to be treated as live governance controls, not static setup tasks.

Practical implication: inventory every agent token, tighten scopes, and ensure revocation is tied to ownership and lifecycle events.

Why compromised extensions and plugins create supply-chain identity risk

Extensions and plugins turn agent ecosystems into dependency chains. If a compromised extension can inherit or manipulate an agent’s permissions, the risk is no longer limited to the base application. The attacker gains a second route into the same identity context, often with enough proximity to execute tasks, access data, or persist inside a private environment. That is a supply-chain problem, but it lands as identity abuse because the malicious component is exploiting granted access rather than discovering a new vulnerability. In practice, every added plugin increases the number of actors that can speak for the agent, which complicates attestation and trust boundaries.

Practical implication: govern extensions as part of the agent identity boundary and review what permissions they inherit before deployment.

Threat narrative

Attacker objective: The attacker objective was to turn trusted AI agents into durable access paths for impersonation, persistence, and control across connected systems.

1. Entry occurred through public exposure of more than 40,000 OpenClaw instances and simple prompt injections that steered agents toward sensitive actions.
2. Credential access followed when attackers extracted API keys and OAuth tokens, giving them legitimate-seeming access to downstream systems.
3. Escalation and lateral movement came through compromised supply-chain extensions and stolen credentials that let attackers impersonate users across platforms.
4. Impact was persistent footholds in private development environments and broader identity compromise across the workflows the agents controlled.

Breaches seen in the wild

• Taiwan autonomous AI agent cyberattack 2026: Up to eight autonomous AI agents cracked 85 Taiwanese government accounts, pivoted through SSO and exfiltrated 2,564+ personnel records.
• MemTensor MemoryOS supply chain attack 2026: Stolen CI publish tokens let attackers ship a credential-stealing worm in MemTensor's AI agent memory packages on npm and PyPI.

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

NHI Mgmt Group analysis

Agent governance fails first as an ownership problem, not a software problem: OpenClaw shows that once an agent can act on behalf of a user, the decisive control question is who owns that identity and who can revoke it. The article describes shadow deployment, weak visibility, and no clear playbook for compromised agents. That is a governance failure before it is a technical one, and practitioners should treat ownership mapping as the minimum viable control plane.

OpenClaw exposed a new class of identity blast radius: an agent with broad delegated access can convert one compromised credential into user impersonation, persistence, and multi-system reach. This is not the same as a traditional application breach because the abuse surface is the trust already granted to the identity. For identity teams, the blast radius now includes every workflow the agent was allowed to touch.

Agent identities cannot be governed as if access were static: the article’s core assumption collapse is that access reviews and incident playbooks expect a stable account with an owner, a lifecycle, and a recoverable state. That assumption fails when agents are distributed, plugin-driven, and able to accumulate permissions across tasks and integrations. The implication is that governance must move closer to issuance and delegation rather than relying on periodic review alone.

Compromised extensions turn identity governance into supply-chain governance: once an agent’s authority can be extended through plugins, the trust boundary is no longer limited to the original agent. SailPoint’s example shows how third-party components can become the path to identity abuse without ever “breaking” the core software. Practitioners should therefore treat extension approval, privilege inheritance, and revocation as one governance domain.

SIEM detection is too late if the identity model is wrong: the article explicitly asks whether a SIEM can tell legitimate agent action from compromise, which reveals the underlying issue. Detection still matters, but only after the organisation knows what a normal agent identity should look like and who is accountable for its behaviour. The real control gap is the absence of an identity model for autonomous or semi-autonomous actors.

What this signals

Agent identity governance is now an operating requirement: teams that still treat agents as tools will miss the point of the OpenClaw pattern. The identity boundary has moved to the actor that can hold credentials, execute tasks, and inherit permissions, so governance has to follow the agent rather than the application wrapper.

Identity blast radius is the right programme metric for agentic AI: the practical question is not whether an agent exists, but how far its delegated reach extends if it is compromised. That forces IAM, IGA, and PAM teams to look at ownership, token scope, plugin inheritance, and revocation as one connected control surface.

Agent certifications need to happen before the workflow becomes entrenched: once agents are embedded into support, development, or cloud operations, the organisation starts to depend on them operationally. At that point, periodic review alone is not enough unless the team can still trace who owns the identity and what it is allowed to do.

For practitioners

• Map every agent to a human owner Create a complete inventory of agent instances, the credentials they use, the systems they can reach, and the person responsible for each identity. Unowned agents should be treated as unmanaged access paths until assigned and reviewed.
• Constrain delegated permissions to task scope Limit API keys, OAuth grants, and tool permissions to the narrowest operational task an agent actually needs. Broad standing access makes prompt injection and token theft materially more dangerous because the attacker inherits the same reach.
• Review extensions and plugins as trusted identity extensions Approve agent extensions only after checking what permissions they inherit, what external services they contact, and how they can be revoked if compromise is suspected. Treat plugin access as part of the agent’s governance boundary, not as optional add-ons.
• Add certification to agent access Fold agents into access review campaigns so teams can verify whether each agent still needs its current systems, credentials, and delegated permissions. Certifications should test actual usage, not just whether the agent exists in inventory.

Key takeaways

• OpenClaw illustrates that agent compromise becomes an identity problem as soon as the agent can act with delegated credentials and no clear owner.
• The incident shows how prompt injection, token theft, and compromised extensions can turn legitimate access into user impersonation and persistence.
• Practical containment depends on ownership mapping, constrained delegation, and lifecycle controls that treat agents as governed identities rather than casual automation.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Agent Lifecycle Management: The process of provisioning, governing, updating, and retiring an AI agent or other non-human identity. It includes credential issuance, permission changes, logging, rotation, and offboarding. Without lifecycle control, agents can retain access after their business purpose ends, creating persistent risk.

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.