OpenClaw shows why agentic AI security collapses at runtime

At a glance

What this is: This is an Aikido analysis arguing that securing OpenClaw fully is not realistic because the agent’s useful behaviour depends on broad access and untrusted input processing.

Why it matters: It matters because AI agent governance now has to treat prompt injection, exposed instances, and unsafe skills as identity and access problems, not just model-safety issues.

By the numbers:

• Early versions were bound to port 0.0.0.0:18789 by default, so tens of thousands of instances on cloud servers were exposed to the entire internet.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Aikido's analysis of why OpenClaw is hard to secure

Context

OpenClaw sits at the intersection of agentic AI and identity governance because it runs with the same permissions as the user while continuously reading messages, documents, and web content. That combination turns access scope, prompt trust, and credential exposure into one governance problem rather than three separate ones.

The article’s central claim is straightforward: you can harden an AI agent by stripping away enough capability to reduce risk, but you also strip away much of the value the tool is supposed to deliver. That is the familiar NHI and agentic AI tension, where usefulness depends on delegated runtime access that conventional approval workflows were never designed to supervise.

Key questions

Q: What breaks when AI agents can call tools after reading untrusted content?

A: The system stops being a text processor and becomes an execution surface. If an agent can ingest poisoned context and then invoke tools with delegated privileges, the attacker can redirect control flow without direct user approval. That is why tool execution needs a separate authorization check from the model’s reasoning step.

Q: Why do NHIs complicate zero trust and least privilege efforts?

A: NHIs complicate zero trust because they are numerous, persistent, and often tightly integrated into applications and pipelines. If teams cannot see every identity or keep permissions aligned to actual usage, they cannot consistently prove least privilege. Continuous review and revocation are essential, not optional.

Q: What do security teams get wrong about prompt injection defence?

A: They often assume better blocklists will solve the problem, but obfuscation simply changes the shape of the payload. Real defence requires examining meaning across the full interaction, including retrieved content and model responses. If the control cannot interpret intent, it will keep missing the attack class it is meant to stop.

Q: How should organisations govern AI agents that need database access?

A: Organisations should give AI agents narrow read access by default, separate write privileges from query privileges, and require human approval for any session that can modify data. That keeps agent activity inside a clearly bounded role while preserving auditability and reducing the chance of unsupervised state change.

Technical breakdown

Why agentic AI collapses the boundary between data input and action

OpenClaw’s design illustrates a common agentic AI failure mode: the system reads untrusted content and can also act on what it reads. In a normal application, input is data. In an agent, input can become instruction, and the model decides whether a message, document, or web page should trigger a tool call. That makes prompt injection structurally difficult to eliminate because the attacker only needs to place malicious instructions inside content the agent is expected to process. The result is a blended trust boundary where the agent’s reasoning, tool use, and identity all sit in the same execution path.

Practical implication: Treat any tool-enabled agent that reads external content as a control plane, not just an assistant.

Why exposed agent instances become credential and access amplifiers

The article points to instances bound to public interfaces and to skills that can carry malware. Once an agent is reachable from the internet, the attack is no longer theoretical: the entry point becomes the network service, the skill marketplace, or the documents the agent processes. Because the agent often inherits the user’s permissions, a compromise can quickly expand into email access, file access, browser control, or API invocation. In identity terms, the problem is not only authentication. It is delegated authority without tight runtime scoping, which creates a large blast radius if the agent is tricked or hijacked.

Practical implication: Force agents onto isolated endpoints with tightly scoped credentials and no default public exposure.

Why prompt injection is a governance problem, not just a model problem

Prompt injection is not a bug you can simply patch out with more rules. The article is right that agents must interpret natural language to remain useful, which means the system cannot reliably separate benign instructions from adversarial ones at the content layer alone. That shifts the control burden to governance: which tools are enabled, what data the agent can see, what network paths it can reach, and what actions require human approval. For AI security programmes, this aligns with least privilege, runtime monitoring, and strict tool allowlisting rather than faith in prompt engineering.

Practical implication: Build policy around permitted actions and data boundaries, not around perfect prompt filtering.

Threat narrative

Attacker objective: The attacker wants to convert the agent’s legitimate delegated access into unauthorized actions, credential exposure, or data exfiltration.

1. Entry occurs when the attacker places malicious instructions inside a document, skill, or web page that the agent is expected to read.
2. Escalation happens when the agent interprets the injected content as a task and uses its delegated access to call tools, fetch data, or alter integrations.
3. Impact follows when the agent leaks credentials, installs malicious functionality, or performs unintended actions with the user’s privileges.

NHI Mgmt Group analysis

OpenClaw exposes the core governance flaw in agentic AI: delegated runtime access is being treated like a feature, when it is really a control boundary. The article shows that utility depends on the agent seeing content, using tools, and making decisions in the same session. That means identity, authorisation, and content trust cannot be separated cleanly. For practitioners, the implication is that agent governance must start with runtime permission design, not model prompts.

Prompt injection should be understood as a standing trust assumption failure, not as a one-off abuse case. If the agent must read untrusted content to be useful, then malicious instructions will always be present somewhere in the workflow. The security question becomes whether the agent can be constrained to harmless outputs and low-risk actions when the content is hostile. That shifts the field toward policy enforcement, tool isolation, and supervision thresholds. Practitioners should stop asking whether prompt injection can be eliminated and start asking what damage it can still do.

AI agent identity is emerging as a distinct governance category, and OpenClaw is a good example of why it matters. The agent is not just software. It is a system acting with borrowed authority across email, files, browser sessions, and APIs. That borrowed authority behaves like an NHI, but with far more dynamic decision-making than a service account or static token. The named concept here is delegated authority sprawl: a state where an agent accumulates permissions across tools faster than security teams can review them. Practitioners need lifecycle controls that track what the agent can do, not just how it authenticates.

Marketplace hardening will reduce obvious abuse, but it will not remove the structural risk introduced by open-ended agent execution. The article points to malicious skills and public exposure, which are symptoms of a broader scaling problem in AI operations. Once a platform encourages community-built extensions and continuous background execution, security governance has to assume hostile content, unsafe integrations, and permission creep. That means control ownership must move from one-time deployment checks to continuous oversight. Practitioners should expect AI agent security to converge on NHI-style governance with stronger runtime limits.

The safest version of a useful agent is probably narrower than most users want. The article’s own hardening list shows the trade-off clearly: sandboxing, localhost binding, disabled tools, and manual review all reduce risk but also reduce value. That pattern is familiar in identity programmes where broad access is easy to deploy and hard to govern. The practical conclusion is not to ban agents outright, but to classify which workflows can tolerate delegated autonomy and which must remain human-controlled.

What this signals

Delegated authority sprawl: AI agent programmes will increasingly fail at the boundary between identity governance and runtime execution if ownership, permissions, and tool access are not tracked as one control problem. The practical signal for practitioners is that agent rollouts should be measured by how quickly they can be constrained, revoked, and audited, not by how much work they can automate.

The near-term risk is not that every agent is fully autonomous. It is that organisations will deploy many semi-trusted agents whose permissions are broader than their oversight. That makes credential scope, tool allowlisting, and continuous logging more important than prompt tuning. Teams that already struggle with NHI visibility will find agent governance even harder unless they can observe and govern every delegated action.

For practitioners

• Classify every agent as a governed identity Assign an owner, purpose, permitted tools, and a revocation path for each AI agent. If the agent can act on email, files, browser sessions, or APIs, treat it like a non-human identity with a lifecycle, not like a disposable integration.
• Remove public exposure from agent control planes Bind agent services to localhost or private networks, disable open interfaces by default, and force authentication for every connection. A publicly reachable agent can be probed, injected, or chained into tool abuse before defenders notice.
• Constrain tool use to pre-approved actions Disable shell execution, unrestricted web fetching, and browser control unless a workflow explicitly requires them. For higher-risk automations, require step-up approval before the agent can modify integrations or external accounts.
• Review and isolate third-party skills before deployment Do not allow community extensions or marketplace skills into production until they are manually reviewed, sandboxed, and monitored for unusual network or credential activity. Treat every extension as a potential NHI-adjacent supply-chain risk.
• Rotate and externalise secrets used by agents Keep API keys out of config files, rotate them on a fixed schedule, and store them in managed secret systems with tight access logging. If an agent is compromised, the secret should be short-lived and the blast radius should be bounded.

Key takeaways

• OpenClaw illustrates a broader agentic AI governance problem: useful agents need broad delegated access, and that same access creates a large attack surface.
• Prompt injection remains a structural risk because agents must process untrusted content to be useful, which means security has to focus on runtime controls and tool boundaries.
• Identity teams should manage AI agents as governed non-human identities with ownership, lifecycle controls, and revocation paths, not as simple automation scripts.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• 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.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

Aikido's full blog post covers the operational detail this post intentionally leaves for the source:

• Concrete hardening steps for running OpenClaw on localhost, in Docker, and with restricted network exposure
• The specific unsafe features the article says should be disabled, including shell execution, browser control, and web fetching
• The security trade-off analysis behind sandboxing, where tighter controls reduce risk but also reduce the assistant’s usefulness
• The article’s discussion of marketplace risks, including malicious skills and the limits of scanning alone

👉 Aikido's full post covers the attack paths, hardening steps, and trade-offs in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and the control patterns that matter for delegated access. It is designed for practitioners who need to connect identity discipline to operational security decisions.