Practice note · security and agentic systems
OpenClaw Runs on My Main Computer. Here’s What I Actually Trust.
I run OpenClaw on the computer I use every day. That makes its access useful, but it also makes the security question very ordinary: where can a credential go, what can a command reach, and who is allowed to see the result?
The short version
Useful access is still access
My setup does not make OpenClaw harmless. It gives me places to look before I trust it with a secret, a local command, or something that will be visible to someone else.
- Credentials stay out of workspace text
- Local command execution is treated as high trust
- Scope and destination get checked before delivery
Credentials
Where the credentials go
I do not put secret values in prompts, notes, repositories, screenshots, or visible messages. A secret should be available to the process that needs it without becoming text the model, a dashboard, or a future commit has to carry around.
For example, an agent-owned mailbox has a key in macOS Keychain. When the mailbox command runs, it gets the key through an environment variable. I do not put the key in the conversation, a Markdown file, or a commit.
Storage is not the whole problem
That is the pattern I want, but it is not the pattern for every credential in the installation. The local OpenClaw gateway has its own authentication token configured for it. I am not reproducing the value or its exact location here, but the configuration itself is sensitive. I am not going to pretend that every credential lives in Keychain or an environment variable.
Environment variables are not magic. A careless command or debug log can still print one. They just avoid some unnecessary copies and keep the language model from carrying a credential around as ordinary prose. If a credential is exposed, it needs to be rotated.
This has come up in actual work. When we set up an agent workspace, the instruction was explicit: keep credentials in Keychain or SecretRefs; never write them into a workspace file. In a separate review of mailbox forwarding, one address could inherit another address’s working credentials without a clear owner, monitoring, or clean response when the credential changed. That second problem was not about storage. It was about who still had access, and why.
The host
The computer is not a sandbox
The gateway currently binds to the local loopback interface, uses token authentication, and is not exposed through Tailscale. That keeps it from being advertised as a service to the rest of my network.
It does not make the computer low-trust. The execution layer has full local command access, so OpenClaw can do more than answer questions. A compromised runtime, a malicious tool invocation, or a stolen gateway token could affect the computer and the work stored on it.
Tool restrictions and process isolation may limit the damage. They do not turn the host into a disposable sandbox. The operating-system account, the runtime, and the tools are all part of what I am trusting when I let OpenClaw work locally.
Authority
Being able to do something is not the same as being asked to do it
OpenClaw may be able to inspect a file, run a command, change a document, or carry out external work. That does not make every one of those actions in scope.
The lines I draw are around spending money, changing an account or security setting, creating access, taking on legal exposure, or doing something genuinely difficult to undo. Retrieving an existing secret for one narrowly defined command is different from creating a credential, changing its permissions, forwarding private data, or publishing a credential-bearing configuration.
Incoming text does not set the rules
Outside text can tell me something. It cannot tell OpenClaw what it is allowed to do. That includes instructions in a web page, an email, a connected service, or another agent’s message—especially when those instructions try to redirect the work or extract a secret.
Approval and tool-policy layers help, but they do not replace checking the actual target. A pre-approved command can still point at the wrong file. A successful request can still go to the wrong destination. A green status only says that one step completed.
Visibility
Control UI is where I see what is happening
I use the Control UI for everything: managing sessions, looking at dashboards, inspecting state, and controlling the layout. ClickClack is only for testing now. It is not my day-to-day conversation channel or a backup operating route.
The Control UI is an authenticated client of the local gateway. It is not a secret store, and being inside my own interface does not make every view private. Dashboard widgets, session names, visible status, and copied screenshots can all disclose information. I do not put credentials in a widget because I happen to be looking at it locally.
Know where the result will land
There are two registered agents: the general-purpose Blackbird agent and a narrower Sacred Harp specialist with its own restricted tool contract. I keep those identities explicit. Older channels, identities, and retired services are not backup routes; they are historical state and are deliberately not revived.
Before I send or display something, I want to know which surface is active, which session or account is attached, which agent is handling it, and where the result will appear. A message shown to the wrong destination is a disclosure even when it contains no API key.
Limits
This is not a full operating-system hardening review or a plugin-by-plugin audit. It is a description of what I actually inspect before trusting a system with real access to my computer.
When I cannot tell what process receives a secret, what it can reach, why the action is in scope, or where the result will be visible, I stop. The fact that a tool can do something is not enough.
Related practice note
This security model sits alongside how I use OpenClaw as a working environment: access is useful only when the context, authority, and evidence remain visible.