Dev.to Security ๐Ÿ” Cybersecurity ๐Ÿ‘ 0 ๐Ÿ“– 4 min read

What I Learned Setting Up OpenClaw: Four Boundaries I Had to Decide

The official site promises a setup that works right away. To run it safely, I had to define the boundaries one by one. 1. Introduction I installed OpenClaw in my home AI lab. The official site says you can ju

The official site promises a setup that works right away. To run it safely, I had to define the boundaries one by one.

1. Introduction

I installed OpenClaw in my home AI lab. The official site says you can just install it and start using it, but I couldn't operate it as-is.
Each time I expanded what it could do, I redefined the boundary, and I only recorded what worked with evidence. This post summarizes that work.
Note: in the linked records at the end, I refer to OpenClaw by my nickname for it, "Kurotchi".

2. I Drew the Line Between Isolation and Usability

At first, following a suggestion from an AI agent on the ChatGPT side, I prioritized isolation. I put OpenClaw in an isolated Docker environment, designed so it couldn't see credentials.
But from inside that isolated environment I couldn't use the dev CLI directly, and every task needed a workaround. The overhead grew and the work stopped flowing.
So on my own judgment, I switched to running the working agent directly on my Mac.

Run the runtime on the Mac
Operate the browser in a separate environment
Handle credentials separately

I separated the runtime, the browser, and authentication. If the setup isn't sustainable, it won't keep running, no matter how safe it is.

3. I Separated Authentication from Authorization

Pushing branches and creating PRs on GitHub worked. Still, normal work stopped halfway. Approval for child sessions was missing.
Being logged in and being allowed to act were two different things. So I separated authentication, operation permissions, and approval prompts, and I also split execution from collecting results.
I limited the admin UI to loopback, and I did not pass the Docker control socket to the browser container.
I verified features in small steps using public pages and dummy data. On November 9, 2026, I confirmed a push of a real work branch and a successful CI run, but that doesn't mean it can do everything.

Authentication shows who you are
Permissions show what you can touch
Approvals ask for permission each time

My policy is to operate only within the range I have verified.

4. I Bridged Scheduled Jobs and Normal Chat

I use Meta's Muse, ChatGPT, and OpenClaw together. They are three AI agents with different design philosophies.
I share scheduled task status on a message board in a GitHub repo, running a multi-AI workflow where the agents help each other.
In scheduled processing, I could read the inbox. But that didn't mean I could use that content directly in normal conversation.
So I built a traceable path from the received body back to its source, and made it routine to read it back and confirm the match. I don't treat received text as permission to execute.

Check the inbox contents
Trace body and source from the conversation
Share summaries only

State sharing is limited to non-sensitive summaries, with restricted destinations, frequency, and deduplication. Delivery is still not perfect.
Connecting things with different designs and policies on the same foundation is hard.

I treat being able to read the inbox and getting that content into a conversation as two separate things.

5. I Separated the Billing Path

At first I was running on pay-as-you-go OpenAI API usage. It cost about $15 in one day, which wasn't sustainable.
On a suggestion from an AI agent on the ChatGPT side, I changed the route to one tied to a Codex subscription. I didn't change the model or the reasoning level.
I emptied the fallback candidates for the target agent's model. If the subscription isn't available, it stops. It won't automatically fall back to the paid API.

Use the subscription route normally
Stop if it's unavailable
Never fall back to metered usage

A design that stops when it can't run seemed like the best way to prevent surprise charges.

6. Limitations

Fully autonomous operation, complete separation of auth sessions, and stability after restarts are all unverified.
Behavior when hitting subscription limits is untested. So I can't say API costs go to zero, and I haven't measured the actual savings.
This record is organized by cross-checking existing public build logs. I didn't run new live tests for this writeup.

7. Conclusion

I decided the boundaries one at a time, and recorded only what succeeded. The operation is still in progress, but the approach is becoming clear.

References

๐Ÿ“ฐ Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes โ€” full credit and traffic to the original publisher.

Share ๐• Twitter โœˆ Telegram โ†— Reddit ๐ŸŸง HN
โ† News ๐Ÿ” Cybersecurity ๐Ÿ  Home