As an early adopter of LLMs, AI in general, and debugging models at the GPU/Kubernetes level, I'm late to the game with managed agents/bots such as OpenClaw that "manage things for you".
- First we had LLMs: say something, get an answer.
- Then we had LLMs with tool calling: say something, it looks it up, you get a better answer.
- Then agents - tool calling in a loop until it achieves a desired outcome.
- And now bots, such as OpenClaw and Grok Bot, that proactively do things for you on your behalf without you constantly having to prompt.
I have a homelab, and I work as a solutions engineer helping large enterprise companies in my day job. I took a look at OpenClaw a couple of times but the level of effort vs the reward was too much for me to find the time. Then came along Grok Bot. I was already a Cursor lover/subscriber so jumped on Grok Bot and started to realise the magic.
And the Grok Bot UX is lovely. Hats off to the designers. I'm a sucker for design like that.
A quick breakdown of Grok Bot as it stands today#
For those who are curious:
- It uses
cursor-grok-4.6-high-fast. This shows up in your Cursor usage but pulls from a separate weekly pool. - Bots share a computer. This is well documented by Grok Bot.
- The computer is a Docker container running on EC2. It has Chrome, a terminal, a file browser, and a desktop installed by default. You can access the desktop from both the Grok Bot desktop app and the iOS app.
- Chrome egresses via Cloudflare's network. They appear to be using Cloudflare's Secure Web Gateway for internet traffic. I assume this is to provide a better UX and avoid websites that block datacentre IPs.
Connectors, MCP, and not handing over the keys#
Grok Bot works with existing plugins/connectors (MCP) to perform its tasks. If it doesn't have a built-in connector it will build one.
It makes use of DCR (Dynamic Client Registration for MCP), meaning you can take an existing web app, put Cloudflare Access in front of it, and enable managed auth. You've instantly got a connector with human-in-the-loop approval. i.e. I only want the bot to access this resource for 1 day at a time; it must come to me for approval.
This is an alternative to, say, a Service Token, where you give a bot/script persistent access to a resource using custom HTTP headers.
And it doesn't have to be an MCP server on the other end. If it's an API, you just ask the bot to wrap the API as an MCP tool (fetch/GET is enough) and it can then use the granted token that lives inside the connector for any task. By default, the access token cannot be reused elsewhere, so the bot wouldn't be given a generic token it can just use; it has to go through a connector.
A specific example: I had the bot build a generic MCP that I can attach as a Worker route at /mcp that just does fetch/GET — jkpe/mcp-fetch-worker. (It can trigger Cursor Cloud agents, which is cool.)
Or just use Chrome?#
Of course, most bots nowadays come with a computer they can control. So you could just point Grok Bot at your web app and it will open the auth in the browser. But this just seems like an inefficient use of tokens to me, plus I then need to auth via the web browser, sign into my SSO provider, etc., unless I set up a separate user just for the bot. Anyway, seems inefficient.
All that to say, for a lot of homelab web UIs it's probably easier to just use the Bot's Chrome browser. The problem is you don't get an audit trail. Something happened in the browser. With OAuth, MCP, and a human in the loop, at least you know what it did.
Have you played with Grok Bot? OpenClaw? I'd love to hear how you're securing, or starting to secure, and give access to your applications or homelab.
Next is to work out SSH access for my Bot.
Disclaimer: they can still, and probably will, wreck everything. At least you'll know which bot did it — Cloudflare Access keeps an audit trail.
Comments