OpenClaw at work: security model, bridge and policy

Use the integration skill

Copy this skill link into your code agent to add OpenClaw and Contro1 to your system.

Copy skill link

Key takeaways

• The problem is not that OpenClaw is capable. It is that nobody in the company can say which assistants are running, who answers for them, and what they did. Contro1 answers all three.
• One command connects the assistants on a computer: contro1 connect openclaw. Their accountable owner approves them on one screen, and nothing works until they do. The steps are in Connect OpenClaw and NanoClaw.
• No API key is copied onto the machine. A local Contro1 service holds each assistant's key where the assistant cannot read it, and uses tokens that expire in five minutes.
• Risky actions stop for a signed, role-routed human decision that is bound to the exact command. Prompt injection can ask for an action; it cannot approve one.
• One queue and one audit trail for every OpenClaw assistant in the company, and a lost laptop is revoked in one click without deleting the agent or its history.

Connect first

This page is about running OpenClaw at work once it is connected: where the risk lives, why the approval is a gate the assistant cannot bypass, the bridge and its settings, policy, and what one connection turns on.

The setup steps, with every command and what you should see, are on one page: install the Contro1 CLI, connect the OpenClaw agents, approve them as their owner, make OpenClaw stop for approval, start the bridge, and check it with contro1 doctor openclaw.

Connect OpenClaw and NanoClaw: every step

What OpenClaw is, and where the risk lives

OpenClaw is an open-source personal AI assistant that runs on your own machine and answers you on the channels you already use: WhatsApp, Telegram, iMessage, Signal, Slack, Discord, and more. It is not a chatbot. It keeps persistent memory about you, your projects, and your people, it can browse the web, fill forms, run shell commands, manage email and calendar, and it can even write and improve its own skills. It works while you are asleep or at work.

That autonomy is the point, and it is also the risk. An assistant that can book, buy, deploy, delete, message people, and run code on your behalf will eventually reach an action you would not want it to take on its own authority. The question is not whether it is capable. It is which actions should stop for you, and how you know what it did when they did not.

The group chat problem, and what Contro1 does about it

Start with the case, because it is the one that actually happens. You run OpenClaw as your assistant. You give it access to your mailbox, because you message it privately and you want it to handle your email. That is exactly why you connected it.

OpenClaw answers on the channels you already use, and one of them is a group: a project with a client, a trip with friends, a team channel. Somebody in that group messages the assistant. It answers, and it has no way to know the person asking is not you. It performs the action with its own authority, so a request from the group and a request from your private thread look identical to it. Anyone in that group can now ask it what is in your mailbox.

No permission was changed and nothing was inherited. The assistant simply answered the channel it was on. This is the confused deputy problem, and it applies to any agent that more than one person can instruct while it holds standing access to one person's data.

Running OpenClaw on your own computer does not remove this. The bridge reaches it over a local socket as one operating system user, with no credential where the assistant could read it, and that is a real protection worth having. But it protects the credential, not the instruction surface. Who can reach the socket and who can message the assistant are different questions, and only the first is answered by running locally. An assistant on your own laptop can still be sitting in a group chat.

• Contro1 treats an OpenClaw assistant as reachable by people it cannot name. The bridge cannot enumerate which channels are wired up or who is in them, so it does not pretend to.
• If your assistant genuinely has no chat channels, say so with CONTRO1_OPENCLAW_REACH=private. That is a claim with a person behind it, worth more than an inference with nobody behind it, and it stays visible in the record.
• Contro1 does not block personal accounts for an assistant other people can message. It warns you when you connect it: anything you give it, including your own email, anyone who can message it can ask for, so check where it answers before you grant it access.
• Every request states who could have asked, beside the command. The command alone was never the whole question.

Why security teams worry about OpenClaw at work

OpenClaw is free, installs in minutes and saves hours, so employees adopt it before anyone approves it. Security teams then find the same four problems on every machine.

• Shadow AI. Nobody has a list of which assistants run on which computers, or who is accountable for each one.
• Prompt injection. The assistant reads email, web pages and chat messages. Any of them can carry instructions, and an assistant that can run shell commands can be talked into running one.
• Credentials in plain text. API keys sit in .env files that the assistant itself can read and send somewhere else.
• No evidence. When something goes wrong there is no record of what the assistant was asked, what it did, and who allowed it.

Governing OpenClaw across your company · Secure your personal OpenClaw assistant

OpenClaw built-in approvals vs a company approval layer

OpenClaw already pauses before risky host commands and can ask you in chat. That is the right mechanism, and this connector builds on it rather than replacing it. What a company needs on top is who decides, on what evidence, and for how many assistants.

What Contro1 cannot secure here, stated plainly

Two things about OpenClaw cannot be enforced by this connector, and knowing which they are is worth more than a reassurance that covers them over.

FIRST: Contro1 cannot tell which conversation an instruction came from. OpenClaw answers on WhatsApp, Telegram, iMessage, Signal and Slack, any of which can be a group. The bridge sees an approval, not the channel it started in, and the fields an approval does carry (sessionKey, host, cwd) are best-effort projections that the CLI sanitizes, which is why this connector never makes a security decision from them. Nothing here can be scoped to "only when I ask in my private chat". An assistant that can use an account can be asked to use it by anyone who can reach the assistant.

SECOND: Contro1 cannot tell who is on the other end. There is no sender identity in the approval surface at all. A request from a colleague, from a client in a shared channel and from you look identical by the time they reach a reviewer.

So an OpenClaw assistant is treated as reachable by people Contro1 cannot name, and personal accounts are refused to it unless its owner allows that by name. Set CONTRO1_OPENCLAW_REACH=private when you know the assistant has no chat channels wired up. That is a claim with a person behind it, which is worth more than an inference with nobody behind it, and it stays visible in the record.

What this connector does enforce is unaffected by any of the above: a command stops before it runs, a named person decides, the decision is bound to the exact command by a hash that is recomputed before it is applied, and the whole exchange is recorded. That is a different guarantee from knowing who asked, and it is the one on offer.

What this connector does

This connector puts a governance layer around OpenClaw without slowing down the assistant. It does two jobs.

First, it turns the assistant's sensitive actions into signed, role-routed human approvals. OpenClaw already knows how to stop before a risky host command; the connector routes that decision to Contro1, waits for a signed answer, verifies it, and only then lets the action run. Second, it gives you a durable audit trail: every approved, denied, and auto-allowed action, plus - through an agent-side skill - the autonomous actions the assistant took that never needed an approval at all.

• Sensitive exec and plugin actions pause for a signed human decision.
• The decision routes by role, with quorum, SLA, and escalation, not just to whoever is watching the chat.
• Approved, denied, auto-allowed, and blocked actions are all recorded as audit evidence.
• The assistant self-logs its autonomous background work, so the trail has no blind spots.

Open the GitHub repo · Requests API · Webhooks

Why not just approve from WhatsApp?

If you already talk to your assistant in WhatsApp, routing approvals somewhere else can look like a step sideways. It is not, and the reason is the nature of the work. OpenClaw runs in the background and takes many small actions on its own. You do not want a chat ping for each one, and you should not have to babysit the thread to stay safe.

What you actually want is two different things at once: to be interrupted only for the few actions that genuinely need an accountable, signed decision, and to have a complete record of everything else it did while you were busy. A chat reply is a casual "ok". A Contro1 approval is a signed, time-stamped, role-attributed decision with evidence attached - the right instrument when the action moves money, changes access, or cannot be undone. The two are not the same tool, and high-stakes actions deserve the stronger one.

A dedicated review surface also scales in a way a chat thread cannot. If you run more than one assistant - or a team runs several - WhatsApp gives you one noisy thread per assistant. Contro1 gives you one queue for all of them, with routing so the right owner gets the right decision and coverage so nothing waits on a single person being online.

One reviewer, many assistants

OpenClaw is self-hosted, so it is normal to end up with several: one per person, one per project, one per device. Each one is autonomous, and each one occasionally needs a human.

Point every instance's bridge at the same Contro1 organization and their approvals land in one queue. A single reviewer, or a rota, can clear approvals from all of them, and role routing sends a finance action to finance and a deploy to platform no matter which assistant raised it. Evidence for every instance is searchable in one place, which is what an auditor or an incident review actually needs.

• Every assistant's approvals arrive in one Contro1 queue.
• Role routing and quorum apply across instances, not per chat.
• On-shift coverage and SLA escalation mean no approval waits on one person.
• A single, unified audit trail spans all of your assistants.

A guardrail the assistant cannot bypass

A guardrail that lives in the prompt is a suggestion: a capable, self-improving agent can reason its way around an instruction. This connector does not rely on instructions. OpenClaw enforces exec approvals out-of-process, on the execution host itself - the openclaw process on the gateway machine, or the companion app on a node. The model that decides to run a command is not the thing that runs it. It can only request; the host holds the gate.

Because enforcement is external, the way to make it truly unbypassable is to deny the assistant any authority to loosen it. Three rules do that, and they are all things you configure once:

• Policy can only tighten. OpenClaw computes the effective exec policy as the stricter of config and the host approvals file; an approval can never widen it. Keep the host approvals file owned by the host, not writable from the assistant's workspace.
• Changing the rules is itself privileged. Config mutation and reserved namespaces need operator.admin, and the assistant's session should not hold it. Route any policy or allowlist change through Contro1 approval too, so widening the gate is itself a reviewed action.
• It cannot rewrite its own instructions. Set skills.workshop.autonomous.mode to off so the assistant does not save or update its own skills on its own - it cannot grant itself a new capability without a person adding the skill.
• It cannot approve its own request. The bridge holds the operator.approvals credential, not the assistant, and it runs as a separate operator client. Keep askFallback set to deny so removing the reviewer closes the gate rather than opening it.

What connecting sets up

contro1 connect openclaw finds the OpenClaw agents on the computer, shows what it is about to change, and asks the accountable owner to approve them. The owner sees the same short code, every agent by name, and exactly what each one will be allowed to do.

Nothing works before that approval, and no key is ever copied. It installs a small Contro1 service on the computer that keeps each assistant's key and gives each assistant its own private local endpoint, and writes a mapping file of agent to endpoint. The bridge talks to those endpoints and never holds a Contro1 credential.

It also gives each agent its own Contro1 MCP server, named contro1-<agent id>, with tool rules so each agent sees only its own server, and writes the bridge settings file ~/.openclaw/contro1.env, which tells the bridge where the mapping file is.

1. 1 · On the computer

   contro1 connect openclaw

   Finds the OpenClaw agents, previews the local changes and shows a short code.

2. 2 · In Contro1

   The owner approves once

   One screen: the code, each agent by name, and what they can and cannot do.

3. 3 · On the computer

   Each agent gets its own endpoint

   The Contro1 service holds the keys; the bridge only receives a per-agent mapping.

What the owner is approving

A connection starts at Approvals only: the assistant can ask people for approval and report what it did, and nothing else. It cannot use the organization's applications until the owner deliberately enables that later, on the agent's page.

The approval is time-limited (90 days by default) and renewals are grouped: when nothing about a set of connections changed, the owner renews all of them on one screen. A connection that did change, for example one that gained application access, is reviewed on its own.

What stays on the computer, and what does not

• The key for each assistant is created on the computer and kept by the Contro1 service. On Windows it is a non-exportable system key; on Linux it belongs to a dedicated service user.
• Access tokens last five minutes and only work together with that key, so a token copied off the machine is useless.
• Each assistant gets its own local endpoint. One assistant cannot use another assistant's endpoint, and an unmapped OpenClaw agent fails closed.
• The only Contro1 setting the bridge needs is CONTRO1_PLATFORM_MAPPING_FILE, the path of the mapping file, which connect writes to ~/.openclaw/contro1.env. Put no Contro1 key in .env; the bridge refuses to start if it finds one.
• Revoking a connection in Contro1 stops that computer immediately. The agent, its owner and its history are kept.

The bridge and its settings

The bridge is the small server in the connector repo, examples/typescript, and starting it is a step in the connect page. It runs on the host that runs OpenClaw, as an OpenClaw operator client outside the gateway process, and as the same operating-system user that ran contro1 connect, because the local endpoints refuse anyone else. It reaches Contro1 through the local Contro1 service.

By default the bridge polls Contro1 for each decision, so it needs no inbound HTTPS. It re-reads the decision and only then resolves the approval in OpenClaw. A signed webhook callback to PUBLIC_BASE_URL/contro1/callback remains available when a public URL is intentionally configured.

• The mapping file: nothing to set by hand. The bridge reads CONTRO1_PLATFORM_MAPPING_FILE from ~/.openclaw/contro1.env, which contro1 connect openclaw wrote.
• Give the bridge an OpenClaw operator token with operator.approvals; full pending enumeration currently also draws on operator.admin, so scope it deliberately.
• Choose where approvals go in Contro1: the dashboard, Slack or Microsoft Teams, and define routing such as required role, department, SLA and escalation.
• Optional webhook mode: set CONTRO1_DELIVERY_MODE=webhook, PUBLIC_BASE_URL and CONTRO1_WEBHOOK_SECRET.
• Point CONTRO1_POLICY_FILE at a JSON policy file to override the conservative defaults.
• For anything beyond a test, run it under your service manager (systemd, launchd or a Windows service) as that same user.

Start the bridge: the connect step

Configure OpenClaw so approvals actually stop

The bridge can only govern actions OpenClaw stops for. OpenClaw exec mode has five values: deny, allowlist, ask, auto, and full. Set it to ask, or to auto with a conservative allowlist, so misses pause instead of running.

Then keep the fallback closed. When a prompt is required but no approver is reachable, askFallback decides what happens: deny, allowlist, or full. Keep it deny so an unreachable bridge means the action is denied, never run. This single setting is what makes the approval a gate rather than a suggestion. The cautious preset sets all of this in one step: an allowlist, ask on a miss, and askFallback deny.

Commands on the allowlist run without asking anyone, so they never reach Contro1. And by default OpenClaw lets an assistant save and rewrite its own skills; turning skills.workshop.autonomous.mode off stops that. Both commands, openclaw exec-policy preset cautious and the skills setting, are steps in the connect page.

Make OpenClaw stop for approval: the connect step

Two skills: enforced and cooperative

The connector ships two skill files, and they do different jobs. The contro1-openclaw skill is the build guide for whoever sets up the bridge. The contro1-approvals skill installs into the assistant's own skills directory and teaches it the cooperative behavior: how to give a reviewer clear, factual context when an action needs approval, and to POST a short audit note to the bridge after each autonomous action.

Be clear about the split. The agent-side skill improves quality and completeness - good context, honest logging. It is not the enforcement. A well-behaved assistant follows it; an adversarial one cannot escape the approval path either way, because that path does not trust the assistant to call anything. Enforcement is the host guardrail; the skill is the good manners on top.

Audit records and cases

Extend coverage with the ClawHub plugin

The bridge governs the actions OpenClaw already stops for - host shell commands and existing plugin approvals. An optional companion plugin extends that to any sensitive tool call the assistant makes: sending an email, buying something in the browser, deleting a file, deploying. Those pause for a human too, not just shell commands.

Install it from ClawHub, OpenClaw's registry, and pair it with the bridge. It is free up to 2,500 approval requests per month.

Get the plugin on ClawHub · Plugin source

Mock mode vs a real gateway

Use OPENCLAW_TRANSPORT=mock to see the Contro1 side without wiring a real gateway: you POST an approval to /mock/approvals as if OpenClaw had raised one, and watch it arrive in the Contro1 queue. The bridge still needs a connection, so run contro1 connect openclaw first; there is no mode that sends requests without an owner-approved identity.

Switch to OPENCLAW_TRANSPORT=cli against a real gateway once the operator token and exec mode are set.

Fail-closed action binding

An approval is permission for one exact action, not a standing licence. OpenClaw enforces this on its own side: it stores the canonical systemRunPlan at approval time and rejects a forwarded run whose command, cwd, agentId, or sessionKey changed after approval. It even re-binds a script to one concrete file and denies the run if that file changed after approval.

The bridge mirrors that rule on the Contro1 side. It hashes the machine-observed facts the reviewer saw, and before resolving an approved decision it re-reads the approval and re-checks the hash. Any drift, or an approval that is no longer pending, is a hard denial.

• A decision that cannot be read from Contro1, or in webhook mode an invalid signature or a timestamp older than 5 minutes: nothing runs.
• Unknown request id: nothing runs.
• Approval no longer pending in OpenClaw (expired or resolved elsewhere): nothing runs.
• Machine-observed facts no longer match what the reviewer approved: nothing runs.
• Each request id is resolved exactly once; a duplicate callback is a no-op.

Policy defaults

Policy classifies each approval from machine-observed facts only: the command OpenClaw captured, the agent id, and the session key. Text the assistant authored about its own intent is never consulted for a security decision.

Try the bridge in mock mode

contro1 connect openclaw          # once per computer, approved by the owner

git clone https://github.com/contro1-hq/contro1-openclaw-connector
cd contro1-openclaw-connector/examples/typescript
npm install
cp ../../.env.example .env        # the mapping file comes from ~/.openclaw/contro1.env
OPENCLAW_TRANSPORT=mock npm run dev

# in another terminal, inject an approval as if OpenClaw raised one
curl -sX POST http://localhost:8092/mock/approvals \
  -H 'content-type: application/json' \
  -d '{"rawCommand":"sudo systemctl restart api","agentId":"main","sessionKey":"whatsapp:+15550001111"}'

Event taxonomy

The connector emits audit-first event names so security, operations, and compliance can search the full timeline - both the approvals and the assistant's self-logged autonomous work.

openclaw.approval.requested
openclaw.approval.auto_allowed
openclaw.approval.blocked
openclaw.approval.approved
openclaw.approval.denied
openclaw.approval.expired
openclaw.approval.binding_mismatch
openclaw.approval.resolve_failed
openclaw.autonomous.*        # self-logged background actions

What one connection actually turns on

The MCP server grants nothing of its own. It is the Access page seen from wherever the call is coming from: the same grants, the same policy, the same refusals. Whoever is calling, not whoever is asking - an agent sees its own permissions, a coding assistant sees the permissions of the person who approved it.

Connecting is one thing, and it gives you two surfaces through the same credential: approval requests, and the Contro1 MCP server. They are not separate connections and there is no second key.

What the MCP server offers, though, depends on what the connection is allowed to do. An approvals-only connection carries requests:create, requests:read, requests:wait, requests:cancel_own and audit:write. The agent can identify itself, raise approval requests and write audit records. It has no invoke_action at all, so it cannot read a mailbox, and refusing to is the correct answer rather than a fault.

When the owner allows applications, the same connection gains actions:read, actions:preview, actions:execute, connections:read and skills:read. Same key, same endpoint, larger tool set. Nothing is reconnected and nothing is reissued.

That pattern is the whole design, and it holds for every caller. There is one MCP address, one tool catalog, and a gate that decides what each caller may reach: what changes between an agent on a connection and a person who has connected a coding assistant is not the endpoint or the list, it is the credential and therefore how far it may go. An agent acts as itself, with its own permissions. A coding assistant acts as the person who approved it, never with more than that person already has, and only if they approved running actions specifically. Neither can be widened by pointing at a different URL, because there is not one.

The third thing is the one people assume comes free with connecting, and it does not: a connection does not put Contro1 in the approval path. That also needs OpenClaw to stop for the command (the cautious exec policy) and the bridge running. Until both are true the connection is live and no approval is ever routed.

• Approvals actually arrive in Contro1: connect, plus OpenClaw stopping for the command, plus the bridge running.
• The MCP server answers at all, with identity and approval tools: connect alone.
• The MCP server reaches Gmail, calendar or a tracker: connect, plus the owner allowing applications.

Company applications through Contro1 (MCP)

The bridge governs what OpenClaw stops for. To let an assistant use company applications such as mail, calendar or tickets, it uses the Contro1 MCP server. Contro1 then decides which application actions the assistant may use, asks a person where your policy says so, and records every call.

connect already gave each agent its own server, contro1-<agent id>, through OpenClaw's own configuration commands, and tool rules so each agent sees only its own. To give an agent applications, open it in Contro1, allow applications for its connection, and choose what it may use. The same server then lists those Actions: nothing is reconnected, and the assistant acts as the agent you approved rather than as you.

Let connect add the Contro1 MCP servers: the connect step

Beat the 30-minute expiry

OpenClaw expires a pending exec approval after 30 minutes by default, then denies the waiting command. The bridge sets the Contro1 request expires_at to the approval's own expiry, so a reviewer is never asked to approve something OpenClaw has already given up on. For high-value actions, use Contro1 role routing, quorum, and SLA escalation to make sure a decision lands inside that window.

Direct gateway transport is a preview

The bridge reaches OpenClaw through the documented openclaw approvals CLI by default. A direct Gateway WebSocket transport would subscribe to exec.approval.requested and resolve via approval.resolve, learning about approvals the instant they are raised.

That transport ships as a preview and is intentionally not implemented: the connect handshake requires signing the gateway challenge with the device-auth v3 payload from @openclaw/gateway-client, and that package was not published when the connector was built. It is now on npm (2026.9.4), so the transport can be built on the official client, but it is not implemented yet. The connector does not guess at an authentication payload, so the CLI transport remains the supported path.

Send full agent traceability

Beyond the approval call, attach a run trace, the tools you invoked, and the context you retrieved. Each field is optional; add what you have. Identity always comes from your credential. When a named part of a multi-agent system made the call, say which with the Contro1-Sub-Agent header (as_sub_agent in the SDKs): Contro1 registers it under this agent, and it never has more authority than this agent.

• trace_id / parent_trace_id - link one run (and sub-agent runs) into a single trace.
• tool_calls[] - what the agent tried to do, so reviewers see the actions. A hook can report every tool call for you.
• retrieved_context[] - the data the decision was based on (RAG provenance).
• Then export a signed evidence packet from GET /requests/:id/evidence.

// Same approval call you already make - now with full traceability.
const billing = client.asSubAgent("billing"); // optional: a named part of this agent
await billing.createProtocolRequest({
  request_type: "approval",
  title: "Refund $4,200 to customer 8831",
  source: { integration: "openclaw" },
  trace_id: `trc_${runId}`,          // link every step of this run
  tool_calls: [{ name: "lookup_order", outcome: "success" }],
  retrieved_context: [{ source: "policy:refunds", uri: "kb://policy/refunds" }],
  continuation: { mode: "decision" },
});

Agent identity, traceability & signed evidence

Make the approval the gate, not a suggestion

The signed webhook is cryptographic proof of a human decision. Verify it inside the system that executes the action - not inside the agent. Any tool that must never run without human sign-off (payments, deploys, data deletion) should refuse to act without a verified approval; that way no agent, including shadow agents nobody registered, can trigger it by skipping Contro1.

• Verify the signature and reject timestamps older than 5 minutes (replay protection; the timestamp marks callback delivery, not request creation, so long SLAs are unaffected).
• Bind the approval to the exact action parameters via metadata / correlation_id - never treat "an approval arrived" as permission for a different action.
• Execute each request_id exactly once (idempotency on your side).
• When in doubt, confirm state directly with GET /v1/requests/:id using a read-only API key.

Full guardrail pattern with code: Webhooks

Put this integration in the enterprise control model

The connector creates the runtime gate. The operating model around it defines which actions pause, which owner receives the decision, how a timeout escalates, and where the outcome is recorded across agent frameworks.

runtime human approval for AI agents · enterprise AI agent control plane

Frequently asked questions

Is OpenClaw safe to use in a company?

It can be, if three things are true: every assistant has a known, accountable owner, risky actions cannot run without a human decision that the assistant itself cannot give, and there is a record of what it did. OpenClaw provides the stopping point on the host. Contro1 adds the owner, the signed decision, the credential handling and the audit trail.

How do I protect OpenClaw against prompt injection?

Assume it will happen and make it harmless. An injected instruction can make the assistant ask for a risky action, but the approval is enforced on the host and decided by a person in Contro1, bound to the exact command. Keep askFallback at deny, keep policy files out of the assistant's workspace, and never put a key where the assistant can read it. Contro1 classifies risk from machine-observed facts, never from text the assistant wrote about itself.

Where is the Contro1 credential stored?

Nowhere the assistant can reach. contro1 connect openclaw creates a key on the computer that the local Contro1 service keeps, and the bridge only receives a mapping to a local endpoint. There is no API key to paste into .env, and the bridge refuses to start if one is present.

How do I see every OpenClaw assistant running in my organization?

Each connected assistant is a registered agent in Contro1 with an owner, the computer it runs on, when it was approved and when it was last used. Readiness and connections are shown per agent, and contro1 status openclaw shows the same checks on the computer.

What happens if a laptop running OpenClaw is lost or stolen?

Revoke that computer's connection in Contro1. Its tokens stop working immediately, and because they last five minutes and only work with the key on that laptop, nothing copied from it keeps working. The agent, its owner and its history are kept, so reconnecting a replacement is one command.

Why route approvals to Contro1 instead of just replying in WhatsApp?

Because the assistant works in the background and takes many actions on its own. You want to be interrupted only for the few that need an accountable, signed decision, and to have a durable audit of everything else. A chat reply is a casual ok; a Contro1 approval is signed, role-routed, and evidence-bearing. It also lets one reviewer handle approvals from many assistants in a single queue. A native WhatsApp approval surface is on the roadmap; the value of signed approvals and audit is the same either way.

How do I make a guardrail OpenClaw cannot teach itself to bypass?

Enforce it outside the model. OpenClaw runs exec approvals on the execution host, so the assistant can only request a command, not run it around the gate. Then remove its authority to loosen the rules: keep the host approvals file out of its workspace, require operator.admin for config changes (which its session should not hold), turn skills.workshop.autonomous.mode off so it cannot save or rewrite its own skills, keep askFallback at deny, and let the bridge - not the assistant - hold the OpenClaw approvals token.

Does it log what the assistant does when I am not looking?

Yes. Approved, denied, auto-allowed, and blocked actions are all recorded. The contro1-approvals skill additionally teaches the assistant to POST a short audit note after each autonomous action, so background work that never needed an approval is captured too - in a durable, exportable trail beyond OpenClaw's own 30-day metadata ledger.

Does this run as an OpenClaw plugin?

No. It runs as an external operator client outside the gateway. OpenClaw native plugins run in-process and are not sandboxed, so an approval control inside a plugin would have gateway-wide blast radius. The bridge only needs an operator token scoped to approvals.

Which OpenClaw version was this built against?

It was built against OpenClaw stable v2026.7.1, and the openclaw approvals commands the default CLI transport uses are unchanged in the v2026.9.4 documentation. Since v2026.8.1 allow-always grants are directory-bound; the bridge resolves with allow-once by default. The gateway WebSocket transport is still a preview and not implemented.

Related resources