The agents nobody approved

Anyone who has not settled which agents may run with which rights on which code has still made that decision, just unconsciously. Agent platforms such as OpenClaw run on a developer’s own machine, need no procurement, and appear in no inventory. Agent governance therefore has three parts: an allowlist, graded permission classes, and a form of detection that does not require suspecting anyone.

The typical trigger is a subordinate clause in a daily standup. Someone mentions that the agent did the refactoring overnight, kicked off over Telegram, from a personal MacBook. And at that point the question is no longer whether such a thing is in use, but since when.

A repository with 386,890 stars that never went through procurement

On 20 August 2026 OpenClaw stands at 386,890 GitHub stars, making it the sixth most-starred repository there is, well ahead of React at 247,443 (GitHub API, retrieved 20 August 2026). That is not a vendor claim but the platform’s own counter.

What sits behind it: an open agent platform by Peter Steinberger that runs on your own machine and is operated through ordinary chat apps — WhatsApp, Telegram, Discord, Slack, Teams. The project puts it itself as “Your assistant. Your machine. Your rules.” No SaaS, therefore no contract, no invoice, no procurement process a CTO ever sees.

For inventory purposes the naming history matters too. The weekend project “WhatsApp Relay” from November 2025 became “Clawd”, then “Moltbot”, and since 29 January 2026 it has been OpenClaw. Anyone maintaining a list of permitted tools and searching for the old name finds nothing.

What rights an agent like this actually has

OpenClaw can read files, execute commands, install plugins and open network connections, and the project itself says the decisive sentence about it: “It is not a sandbox.” The security documentation describes boundaries instead — path protection, a proxy — but concedes that a plugin with shell rights can still do anything shell rights permit.

That openness is more honest than the marketing of most commercial tools. But it describes precisely the class of software that should not run unattended on a machine holding client code.

That the permission system can break is documented. CVE-2026-33579 describes a privilege escalation with CVSS v4.0 9.4 and CVSS v3.1 9.9, rated CRITICAL by the CNA VulnCheck, CWE-863, published 31 March 2026. All versions before 2026.3.28 are affected: a caller with pairing but not admin rights could approve device requests carrying elevated rights including admin, because the scope check was missing from the approval path.

If you cannot say right now which agents run on your development machines and with which rights: taking exactly that inventory is half a day with your team, with no tool recommendation at the end. Write to us through contact.

What local operation triggers under the revised Swiss DPA

An agent that sends repository contents to a model is, in data protection terms, a disclosure — and usually one abroad. Where the code contains personal data, for instance in fixtures, logs or migration scripts, Art. 16 and Art. 9 of the revised DPA apply.

Art. 9 para. 3 is particularly awkward: a processor may transfer processing “to a third party only with the prior authorisation of the controller”. A self-installed agent that reaches an additional model provider creates exactly that unauthorised third party, and nobody in the company knows about it.

The sanction lands on people, not departments. Art. 61 of the revised DPA provides for fines up to CHF 250,000 against private persons, on application, in cases of intent. Covered are, among other things, disclosure abroad without the conditions of Art. 17, and handover to a processor without the conditions of Art. 9 paras. 1 and 2.

How that translates into architecture we set out provision by provision in A revDSG-compliant AI architecture.

Three permission classes rather than one approval

A binary approval fails, because “permitted” means something different for an autocomplete than for an agent that commits at night. So we work with three classes, and the class follows from the access rather than from the product name.

The line that matters lies between B and C. Anything falling in class C belongs on a dedicated machine with its own operating system account, not on the laptop that will open a client project tomorrow. OpenClaw’s documentation itself recommends separating trust boundaries on shared hosts, with separate OS users or separate hosts.

For class B the frame can be captured in configuration. OpenClaw has a restrictive baseline that works as a starting point: gateway on loopback only, execution denied by default.

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "<long-random-token>" },
  },
  tools: {
    deny: ["group:automation", "group:runtime", "gateway", "cron"],
    exec: { security: "deny", ask: "always" },
  },
  agents: {
    defaults: {
      sandbox: { mode: "all", scope: "agent" },
      workspaceAccess: "ro",
    },
  },
}

The file itself belongs locked down: ~/.openclaw at 700 and ~/.openclaw/openclaw.json at 600. The project ships a check that also finds configuration drift:

openclaw security audit --deep
openclaw security audit --fix

How to detect use without hunting anyone

Detection here means inventory, not surveillance: you ask the machine, not the colleague. Three signals are enough for a first pass, and all three fit into an onboarding script or an MDM check.

# 1. Globally installed agent packages
npm ls -g --depth=0 2>/dev/null | grep -Ei 'openclaw|opencode|codex|claude-code'

# 2. Configuration directories of long-running agents
ls -ld ~/.openclaw ~/.claude ~/.codex 2>/dev/null

# 3. The OpenClaw gateway listens by default on 127.0.0.1:18789
lsof -nP -iTCP:18789 -sTCP:LISTEN 2>/dev/null

The second part concerns not the machines but the repositories. An agent sees whatever the working directory offers, and that is regularly more than assumed:

git ls-files | wc -l
git grep -nIE '(api[_-]?key|secret|BEGIN [A-Z ]*PRIVATE KEY)' -- ':!*_test*' | head

If that second query finds something, the agent question is secondary. You have a secret management problem that affects every clone of the repository.

Tool lock-in is the second, quieter risk

Thinking about governance only as a security question misses the consolidation happening in the market. Windsurf no longer exists as its own brand: on 20 August 2026 windsurf.com answers with HTTP 308 to devin.ai/desktop, checked with a simple redirect test. Cursor has been building its own code hosting with “Origin” since 17 August 2026, complete with repositories and pull requests, in open beta for all paid plans according to the changelog, with an opt-out for enterprise administrators.

Usage shares are moving at the same pace. The JetBrains Developer Ecosystem Survey 2026 with over 15,000 respondents, collected between May and July 2026, measures a redistribution within a few months. To note: JetBrains operates in the same market and is therefore not a neutral surveyor.

A tool that sheds or doubles a third of its user base within two quarters is not a platform decision but a snapshot. What binds you should therefore not be the tool but whatever survives switching it.

Three things are portable today: the Model Context Protocol in the specification version of 28 July 2026; the AGENTS.md format, which according to agents.md over 60,000 open-source projects use and which is maintained under the Linux Foundation; and A2A in version 1.0, also handed to the Linux Foundation.

Putting your project conventions there rather than in tool-specific settings means changing tools without a migration project. What building your own MCP server looks like we described in Running MCP servers in Go in production.

The MCP specification is notably clear on security: tool descriptions and annotations are to be treated as untrusted unless they come from a trusted server. At the same time it records that the protocol cannot enforce those principles. Enforcement lies with the host, which is to say with you.

What belongs in the policy, and what we advise against

An agent policy fits on two pages. It only gets read at greater length when an audit is due.

• An allowlist with versions, not only product names. OpenClaw has run an extended-stable channel since 30 July 2026, the first such release being 2026.6.33. What you approve is a channel, not “the tool”.
• A permission class per deployment, per the table above, documented with one sentence of reasoning.
• Named outbound destinations. Which model providers, which MCP servers. GitHub introduced MCP allowlists in enterprise settings on 6 August 2026; that is the right lever.
• Personal subscriptions are not corporate access. Not because the tool would not work, but because the contract is a different one: Free, Pro and Max run under consumer terms where training use hangs off a personal account setting the employer neither sees nor controls. Anthropic describes this explicitly for using Claude Code from such accounts. Which plans and purchasing routes exist instead is in Using coding agents in line with data protection law.
• A reporting route with no consequence. Someone reporting a previously unapproved agent gets a class assigned, not a reprimand.

What we advise against: a ban. A ban produces better-hidden shadow IT and costs you exactly the information you need.

We equally advise against letting the agent sign off its own work. Review, tests and the merge gate stay outside the agent, otherwise the system checks itself. Why that matters architecturally is in AI writes the code. Who writes the architecture?

When our recommendation does not fit: in a two-person team with a single repository and no personal data, the permission class matrix is overhead. There a maintained list in the README suffices, plus the rule that no agent executes commands outside a container.

Frequently asked

Is OpenClaw fundamentally unsuitable for companies?

No. OpenClaw is a technically impressive project with open security communication that names its own limits. What is unsuitable is the operating model on a work machine holding client code: local, broadly permissioned, driven through consumer chat apps. On a dedicated machine with its own OS account, loopback binding and a restrictive tool policy, sanctioned use is possible.

How do I tell whether an agent has sent personal data to a model?

From the outbound traffic and the agent session, not from the repository. The workable route is the reverse: check which directories the agent was allowed to read, and treat everything in them as disclosed. That is why class B specifies workspaceAccess: "ro" and a single repository. Less visibility is what makes the data protection assessment under Art. 16 revDSG tractable in the first place.

Is a container enough protection?

A container limits the damage, it does not prevent it. It protects the host’s file system and separates agents from one another, but changes nothing about which data the agent sees inside the container and where it sends them. Container plus a tight tool policy plus named outbound destinations work together. Individually, none of the three works.

What do we do with an agent that has been running unnoticed for months?

Inventory first, classify second, decide third. Check the version, particularly against CVE-2026-33579 and the 2026.3.28 boundary; record the rights and the scope of access; rotate the secrets that were within its reach. Only then ask whether it keeps running or gets switched off. Switching it off immediately destroys the information about what the agent actually did.

The next step

Take 30 minutes with one of our engineers, no sales pitch: we go through your tool list, assign each entry a permission class, and name the places where revised DPA obligations are engaged. Book a slot or write informally through contact; both reach the same person.

If it turns into more than a policy — an agent that should run cleanly bounded inside your environment, say — that is our day job under Artificial Intelligence & Machine Learning.