AI Agents Are a Permission Problem

An AI agent is a program that holds your credentials and follows instructions it cannot authenticate. Everything else about the category sits on that fact. When an agent turns hostile, the damage is set by what it was permitted to touch, not by how capably it writes.

OpenClaw is the clearest test case available. A weekend project whose repository was created in November 2025 now carries several hundred thousand stars (GitHub). Inside its first three months it produced a rated vulnerability, a scan that found more than thirty thousand exposed instances, a marketplace audit that found 341 malicious skills, and a demonstration in which a shared document installed a permanent backdoor. Almost none of it required breaking the software. It required the agent to do what it was told.

Most commentary treats the tool as the story. I think the tool is the evidence. The question worth answering is which control limits the damage, and my answer after a year of watching this is the permission grant: not the model, not the prompt filter, not the vendor’s safety page. The incidents below are the test of that position.

What the agent actually holds

Remove the chat interface and four things remain: a long-running process, a set of credentials, a set of tools, and an input channel that accepts text from anywhere. OpenClaw puts all four on your machine and wires them together. Its security documentation is direct about the consequence. At the time of writing, sandboxing is opt-in, and with sandbox mode off, tool execution resolves to the gateway host, so an agent that read a poisoned web page is running commands with your account’s authority (OpenClaw documentation).

For a hobby project on a spare laptop, that is a reasonable trade. For a business it means the agent inherits every permission of whoever installed it, plus every token in its configuration directory. A mailbox token is the mailbox. A repository token is the repository. There is no separate “AI permission” object in your directory to audit, which is why the first useful question about any agent is not which model it uses but what it can reach. The hardware question underneath it — whose machine, whose network, whose data — is the same one I worked through in the local inference decision framework.

The defaults improved. The deployment habit did not.

Early builds could run with no authentication at all. The release that renamed the project to OpenClaw removed that option: gateway auth mode “none” was deleted and a token or password became mandatory, as Bitsight’s researchers noted when they quoted the changelog (Bitsight). That release also fixed CVE-2026-25253, in which the control interface took a gateway address from a query string and connected to it automatically, sending its authentication token to whichever host the link named. NVD rates it 8.8 and lists every version before 2026.1.29 as affected (NVD). One link, one click, and the token belonged to someone else.

As of publication, current builds are better than their reputation. On a normal host install the gateway binds to loopback only, an unknown sender gets a pairing code instead of a conversation, and group access is allowlisted (security overview). The documentation names one deliberate exception: container images default to a bind that is reachable from outside, and the docs tell you to pair that bind with authentication. The project also ships an audit command that reports drift from those defaults.

None of that reaches the deployments already running. Bitsight scanned the default gateway port from 27 January to 8 February 2026 and counted more than thirty thousand distinct OpenClaw instances answering on the public internet (Bitsight). The same research found authentication enforced without any policy on strength: a single character was accepted as a gateway token. Their sample included instances in healthcare, finance, government, and insurance networks, which puts agents inside organizations whose controls assume no such software is present.

Thirty thousand is a floor, not a census. It counts one port on one day range, and it excludes every agent behind a VPN, on a laptop, or listening somewhere else. The number that should worry an IT manager is smaller and worse: how many of those sit behind one NAT rule on a corporate network, holding a token for a system that everyone believes is internal-only.

Prompt injection is a permission bug with a language model on top

On 4 February 2026, Zenity Labs published a demonstration that used no vulnerability at all (Zenity Labs). An employee connects OpenClaw to a Slack workspace and to Google Workspace, the second through a built-in skill that the setup flow offers early. An attacker shares a document with normal business text at the top and instructions further down. The employee asks the agent to work with that document. The agent completes the task and also creates a new Telegram integration, using a bot token the attacker registered in advance and an allowlist entry for the attacker’s account. From that point the attacker talks to the agent directly.

The researchers did not stop there. Through the backdoor they edited SOUL.md, the file that defines the agent’s behaviour and is loaded into context on every turn. They added a scheduled task that rewrote it every two minutes, so control survived removal of the original integration. Then they had the agent download and run a Sliver command-and-control implant, which moved the compromise from a misbehaving assistant to a conventional remote access tool. Every step used a supported feature with permissions the user had already granted. The attacker supplied nothing but text.

Simon Willison’s framing covers the general case: an agent that combines access to private data, exposure to untrusted content, and the ability to communicate externally can be talked into exfiltrating (Simon Willison). OpenClaw is that combination with a memory file and a shell attached.

The obvious countermeasure is a prompt-injection filter. OWASP’s entry for the risk says plainly that given the stochastic nature of these models, “it is unclear if there are fool-proof methods of prevention” (OWASP LLM01:2025). OpenClaw’s own documentation, at the time of writing, cites a 2026 arena of 272,000 attacks across 41 agent scenarios. Attacks were scored only when the agent both performed the harmful action and hid it, and on that scoring one frontier model failed 0.5% of the time while another listed tier failed 8.5%. The same page notes that adaptive human attackers exceed 80% success against state-of-the-art defences once they can iterate.

A control that fails once in two hundred reduces incidents. It does not decide what an incident costs. The permission grant does, which is why OWASP files the second half of this problem separately, as excessive agency: too much functionality, too many permissions, too much autonomy, and no independent approval for high-impact actions (OWASP LLM06:2025). Zenity’s attack is excessive agency with a delivery mechanism. Take away the Telegram integration permission and the document is just a document.

Skills are code from strangers, installed with one command

ClawHub, the community skill registry, is open by design: publishing needs a GitHub account at least a week old (The Hacker News). Koi Security audited all 2,857 skills it held and found 341 malicious ones, about 12%, of which 335 used fake prerequisites to deliver the Atomic macOS stealer or a Windows keylogger. Cisco’s AI Defense team ran its scanner against the top-ranked skill, a package called “What Would Elon Do?”. It found nine issues, two of them critical: a silent curl command sending data to the author’s server, and an instruction telling the assistant to bypass its own safety rules before running it (Cisco).

The ranking is the part I would underline in a procurement meeting. A skill reaching number one is evidence of popularity, and popularity can be manufactured by the people who wrote the payload. OpenClaw added a reporting feature in response, with a skill hidden automatically after three unique reports. Reporting is not review. Three reports is a threshold for hiding something, not a standard for whether it was safe.

The credentials are files, and the files are the target

An agent needs standing access to be useful, so it stores what it needs. In OpenClaw that is a state directory holding configuration with gateway and provider tokens, channel credentials, a SQLite database with MCP OAuth tokens, and per-agent auth profiles. The documentation’s protection is file permissions and disk encryption — 0600 on files, 0700 on directories — and it warns that session transcripts keep tool output and pasted secrets in their original text (Secrets, storage, and logs). That covers a stolen disk and a careless chmod. It does not cover malware running as your user, which is the threat that actually arrived.

Hudson Rock documented the first in-the-wild theft of those files in February 2026 (BleepingComputer). A Vidar infostealer variant took openclaw.json, including a gateway authentication token; device.json, including the private key used for pairing and signing; and soul.md with the memory files holding message and calendar history. The detail that matters is in the researchers’ caveat: the stealer was not built for OpenClaw. It swept for files containing “token” and “private key”, and the agent’s directory was full of both. Commodity malware now picks up agent identity as a side effect of stealing browser passwords.

Set that against your identity inventory. Every one of those tokens is a credential your identity provider did not issue, does not expire on your schedule, and will not revoke when a laptop is reported stolen.

Capability against permission

This is the table I would put on the screen in a design review. The left column is what the agent can do, the middle is what it actually reaches when it does it, and the right is the grant I would require before switching it on. The useful capabilities and the expensive ones keep turning out to be the same list.

Capability	What it reaches	Grant I would require
Read your mail	Every message, attachment, and password reset ever sent to you	Read-only scope, one mailbox, no send scope, dedicated account
Send mail as you	Your reputation, your customers, your domain’s standing with their mail filters	No standing grant; per-message human approval
Read shared documents	Content written by anyone who can share with you	Read-only, one folder, external sharing disabled
Browse the web	Any page, including one written to instruct it	Sandboxed browser with no session cookies from your accounts
Run shell commands	The host, its files, and its position on your network	Container with no host mounts and no credentials inside
Write files	Everything the agent’s OS user can write	One workspace directory, versioned, backed up
Push to repositories	Production code, CI secrets, deploy keys	Bot account, branch protection, review required
Message external channels	Anyone the agent can reach, in your name	Allowlisted recipients only, every message logged
Install a skill	Code execution as the agent, plus whatever the author wants	Pinned version, reviewed source, no marketplace installs
Hold a credential	Every system behind that credential until someone rotates it	Scoped, short-lived, owned by a named person, revocable

Ten rows, and not one of them is about which model you chose. That ratio is the argument of this piece.

What this means for operators

Three consequences follow for a small or mid-size organization, and none of them need a dedicated AI security team.

First, this is an inventory problem before it is a policy problem. Agents arrive the way file-sharing tools arrived: one employee, one install command, no ticket. Bitsight found instances in regulated sectors, which means they are already inside networks whose controls assume they are not. If you cannot list the hosts running an agent, everything after that is guesswork, and you are back to the position I described in the threat floor, spending on tools to cover a gap you have not measured. NIST’s AI Risk Management Framework already arranges the work this way, in four functions: govern, map, measure, manage (NIST). A register of agents and the permissions they hold is the map step, and it is the one programs skip.

Second, the blast radius is borrowed authority. An agent installed by an IT administrator reaches what that administrator reaches. An agent installed by a finance manager reads the finance share. The useful description of that incident is a privileged session that someone else is driving, using a token nobody issued through the identity system.

Third, response changes shape. With a compromised user you disable the account and reset the password. With a compromised agent you need to know which integrations were live, which tokens it held, what it read in the past week, and whether it created anything new. Zenity’s backdoor was a new integration, so a responder who removes only the original channel leaves the attacker in place. This is the same containment discipline as any intrusion, applied to a system whose logs are chat transcripts. The pattern I expect through 2027, from the work we do at Envescent, is that the agent is rarely the hardest part of the response. The missing inventory is.

Banning is the wrong answer for the reason banning cloud storage was wrong: the demand is real and the workaround is worse. What works is a permission path — a supported, reviewed way to run an agent that reaches less than the employee’s full account.

What to do

1. Inventory every host that can reach an agent gateway. Search endpoints for the process, the default port, and the state directory, and match the project’s earlier names as well, because the installs still running without authentication are the old ones.
2. Give the agent its own identity. A dedicated account and a separate OAuth grant per integration, scoped to one mailbox, one folder, one repository. Never an administrator’s session, never a shared service account, never a personal token with a calendar attached.
3. Start read-only and make it earn the rest. Run the assistant against a copy of the data for a month with write tools disabled. Add a write capability only when you can name what it writes, where the output lands, and who reviews it.
4. Put human approval in front of the four irreversible actions: sending mail as the company, moving money, deploying code, and deleting data. Enforce it in the downstream system, per OWASP’s complete-mediation advice, not in the prompt. A model that can be argued out of a rule is not a control.
5. Keep untrusted content out of the privileged context. Use a separate reader agent with no tools to summarise inbound documents and pass the summary to the agent that holds credentials — and remember the project’s own caveat that the summary is still untrusted.
6. Treat skills as vendor code. Pin versions, read the source, prefer skills your own team wrote, and never install from a popularity ranking. A skill that asks you to download a “prerequisite” is describing the attack, not the setup.
7. Test revocation once a quarter. Pick one agent, revoke every token it holds, and watch what breaks and what keeps working. The tokens you cannot revoke are the ones that will define your next incident.
8. Log the agent as a user, not an application. Tool calls, outbound requests, and newly created integrations belong in the same review you give privileged account activity, because that is what they are.

The decision for this quarter is narrower than an AI policy. Pick one workflow where an agent would save real hours, write down every system it touches, and cut that list to the smallest set that still works — the same exercise that separates the adopters from the bystanders in the workflow problem. If the list cannot be cut, the workflow is not ready for an agent, whatever the demo showed. That review takes an afternoon. It is also the difference between a tool that fails safely and a token with your name on it. More of this kind of analysis lives under AI.

Sources

1. OpenClaw: The AI Butler With Its Claws On The Keys To Your Kingdom — Bitsight, 2026-02-09.
2. OpenClaw or OpenDoor? Indirect Prompt Injection — Zenity Labs, 2026-02-04.
3. Researchers Find 341 Malicious ClawHub Skills Stealing Data from OpenClaw Users — The Hacker News, 2026-02-02.
4. Infostealer malware found stealing OpenClaw secrets for first time — BleepingComputer, 2026-02-16.
5. Personal AI Agents like OpenClaw Are a Security Nightmare — Cisco Blogs, 2026-01-28.
6. CVE-2026-25253 Detail — NIST National Vulnerability Database, 2026-02-01.
7. Security — OpenClaw documentation, accessed 2026-08-25.
8. Prompt injection — OpenClaw documentation, accessed 2026-08-25.
9. Secrets, storage, and logs — OpenClaw documentation, accessed 2026-08-25.
10. LLM01:2025 Prompt Injection — OWASP Gen AI Security Project, 2025-04-28.
11. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project, 2025-04-28.
12. AI Risk Management Framework — NIST, 2023-01-26.
13. The lethal trifecta for AI agents — Simon Willison, 2025-06-16.
14. openclaw/openclaw — GitHub, accessed 2026-08-25.